DiGIR Conceptual Domains

Author: Dave Vieglais
Revision: 1.2
Date: 2003-04-28



Conceptual domains circumscribe a group of resources made up from objects that conform to a common schema.

The conceptual domain is defined primarily by a conceptual schema, which is an XML Schema document that described the attributes of objects contained within the resource.

An additional component of the conceptual domain is a definition of the record structure(s). The record structure document(s) describe the arrangement of elements defined by the conceptual schema.

Providing the association, or glue between a conceptual schema and its record structure document is an information domain document, or "infodoc".

The DiGIR test information domain provides the example used throughout this document. The test information domain does not define any meaningful content, but instead provides examples of all the core metatypes that are used by the DiGIR protocol.

The Information Domain Document

The schema describing the Infodoc is located at the URL:


The Infodoc for the DiGIR test domain is located at the URL:

The contents of the Infodoc is repeated here for convenience and reference:

<?xml version="1.0" encoding="UTF-8"?>
  <name>DiGIR Test Domain</name>
      <resultSchema default="true">
        <handle>Normal Result Set</handle>
 A container for the elements of an Information Domain. The name space of the DiGIR protocol and of XML-Schema should be declared here. Although technically not necessary, it is generally convenient to set the default namespace of the document to that of the DiGIR protocol, http://digir.net/schema/protocol/2003/1.0.
name:The name of the information domain.
attribution:Who to blame for the creation of this domain.
 The namespace, location, and handle of the conceptual schema for the information domain.
resultSchemas:Contains at least one resultSchema that describes a representation of the information.

The Federation Schema Document


The Record Structure Documents

Record structure documents are XML-Schema documents that describe the structure of records.


Derived Schemas

Given federation schema FS1 = {c1,c2,c3}, where "cx" denotes a concept,


federation schema FS2 = {cA,cB,cC} U FS1

A resource that supports FS2 would support the concepts {c1,c2,c3,cA,cB,cC}, that is, it would support searches that were targeted to only FS1 as well as FS2.

Deriving a new federation schema from existing federation schema(s) reduces the proliferation of concept definitions (simply import existing concept defintions rather than defining new ones) and provides a convenient mechanism for server and client (provider and portal) software to indicate their support for different federation schemas.

An real world example of this might be the relationship between Darwin Core versions 1 and 2. DarwinCoreV2 can be thought of conceptually as deriving from DarwinCoreV1, with all of the concepts in V1 appearing in V2. As of this writing there are many resources that support V1 but very few (if any) that support V2. Providers can advertise that they support V1, and the portal will understand that only a subset of concepts are available from those providers. As providers are updated to support V2, the portal software will automatically recognize the altered set of available concepts, and adjust the range of possible queries appropriately.