Relating to other standards

Relating to other standards

2014-03-28 based on small group discussion at NADDI Sprint

Problem statement

How do we interact with other standards? We want to reference these things in our views. This is a modeling issue as DDI interacts with different standards in different ways. Do we need an interface to map to other standards? DISCO references four different standards. What is the mechanism for the references? This is how the Semantic Web works - the very loose structure of the Semantic Web enables this. It can be an advantage or a disadvantage. For the OWL representation there should be a configuration that could be expressed in OWL to say this DDI object is equal to an object in another standard. How is this translated to the XML schema level? The problem on the model level is that you would need to model other standards. Perhaps we could do something similar to what we do with the controlled vocabularies - we have a pointer to vocabulary and reference to an object in another standard. We have no control over the versioning of the other standards, but a way to solve this for loosely defined standards is: in DDI an equal or similar object is defined with mapping and then the external item can change but that doesn’t matter. It would be worth it to explore this and put a proposal forward this week for commenting later.            

Current practice

DDI uses three methods to provide linkages to external standards. The selection of approach is dependent upon how the information is intended to be used within DDI and as an interface with non-DDI systems/users.

1 - Informed modeling

This is the use of the external standard to inform the general content and relationships within related sections of DDI.

Example: ISO/IEC 11179-3 (Agency, ID, Version), ISO/IEC 11179-5 (Name, Label, Description), GSIM modeling of the ISO/IEC11179 Data Element

2 – Selective replication of content

This is the practice of using explicit structures that describe a set of information in a way that it is used by its community. The structure is replicated with a DDI namespace set of objects and results in a clean DDI to external mapping. These may be simplifications, such as limiting options for content. These are objects that must be handled in a consistent way within both standards and therefore clean mapping is a requirement.

Example: ISO 19115 Bounding Box, Spatial Object; OWL-S InParameter, OutParameter, Binding

3 – Inclusion of native objects from an external standard

This is an incorporation of all or part of an external standard within DDI using the external namespace. This is used where a clear and strong interface occurs between DDI and external systems.

Example: Dublin Core, XML types (xs:date, xs:string, etc.)

Issues arising from current practice

  1. In using standards as models, for replication, or for direct inclusion we need to be clear on the version of the external standard which informs our work. All use of external standards by inclusion of native objects should be version specific.
  2. The current methods of inclusion are pulled out from the content of DDI 3.2. There should be a rational decision process for determining the appropriate means of relating DDI to other external standards as the need arises.
  3. There is a value in the incorporation of native elements when the purpose of the metadata within DDI is to facilitate a tight interface between DDI and the systems using the external standard. For example, the use of XML primitives and attribute types provides consistency of understanding and processing by the systems that use these objects.
  4. DDI may wish to be able to extend these objects for internal management and/or to facilitate linking them to other DDI objects. For example, the addition of a DDI typing mechanism for a Dublin Core Identifier to differentiate between multiple identifiers uses by the systems with which the DDI user is interacting.
  5. DDI may wish to limit what is included either in terms of the number or complexity of the objects.
  6. DDI is a model which is expressed in a minimum of two languages (XML and RDF). If the external standard is expression specific there may be objects whose structure does not translate well into other expressions. For example an XML centric model not supported in RDF.
  7. Continue to use the current approaches of informed modeling and selective replication of content.
    1. Develop clear guidelines for the use of these two approaches
    2. Document the external standards used including the version and specific objects
    3. The use of external objects in their native format should be limited and conform to licensing limitations to ensure that DDI in its totality is usable.
      1. The external standard must be expressible natively as both XML and RDF.
      2. The need for direct transfer of content elements between DDI and external systems must be documented
      3. Use of native content should be filtered through a separate namespaced package
      4. We require further testing of profiles that would support the requirements noted in Issues 2 and 3 noted for including native objects from an external standard

Issues related specifically to the inclusion of native objects from an external standard

Possible Approaches

To do list

Dublin Core Example Test

Dublin Core is currently included through the use of a Dublin Core supplied element group which is intended to allow incorporation of native Dublin Core into external systems.

  1. Check to see if extensions for typing all elements can be added (these are for internal use and are not intended to convey information to external systems similar to the Dublin Core directive that the content of dcterm elements should be understandable when simplified to unqualified dc elements).

XACML Example Test

XACML is a language to support access control and is being considered for selective inclusion in the Collection Management task area of DDI.

  1. Identify need for native namespace content in this area
  2. Verify that objects can be both restricted
  3. Verify that objects can be extended
  4. Verify that version specificity can be retained