Relevant standards guidance
Introduction
During the development of DDI 4, an international standard for the description of statistical and social science data, a need was identified for guidance on implementing DDI 4 with existing data and metadata standards. The 4th version of DDI is designed to complement existing data and metadata standards and should preclude the recreation of objects, elements, and other types of information from existing standards.
Purpose
This document contains guidelines for content modellers and others interested in referencing and integrating standards with DDI 4 to support metadata and data interoperability, and add flexibility to implementations of DDI. The 4th version of DDI is model-based allowing for interoperability at the conceptual level, as well as at the element level.
Description The guidance in this document consists of general information on the use of other standards with DDI and instructions on how to develop profiles, as well as several examples of how standards can be used with DDI. The guidance is based on ISO/IEC TR 10000:1998(E) Framework and Taxonomy of International Standardized Profiles.
DDI 4 and other standards
DDI 4 can be used with existing standards to support the research data lifecycle/statistical business process. See Appendix A for descriptions of standards that can be used with DDI.
When combining standards, it is recommended that modellers create "profiles", which are specifications for the use of one or more standards. A profile can contain one or more profiles, for example a profile for data discovery can have profiles for DDI + SDMX/Data Cube and DDI + Dublin Core. The result is a master profile that can be implemented in whole or in part.
The ISO Technical Report refers to the International Standardized Profile (ISP), which is "[a]n internationally agreed-to, harmonized document which describes one or more profiles" (p. 1.) This guidance will not deal with ISPs specifically.
Approaches to combining standards
The three approaches to using other standards * with DDI 4 are:
Insert or integrate a complete standard with DDI 4.
Use a complementary set of elements from other standards.
Select specific elements from other standards.
*Including locally-defined elements.
Interoperability and DDI
Standards identified for possible use with DDI are assessed to determine the extent to which use of the standards supports interoperability.
The two levels of interoperability for DDI 4 are:
Model-level (conceptual model e.g. PROV)
Element-level (unique elements or element structures)
Interoperability is measured at the conceptual level, for model-based and element-based standards (vocabularies), and not the label level; elements from different standards can bear the same name and be conceptually different. Interoperability for element-based standards is evaluated at the element level only.
Note: Evaluation of label-level interoperability is normally not advised, unless it can be certain that the same vocabulary has been implemented in the standards being considered.
Interoperability first entails that there be intersections between standards, i.e that they have objects that are connected in one or more relationships. Across the intersections, two standards are complementary when one lends specificity to the other. For example, the addition of certain Dublin Core elements to a DDI citation lends specificity to the DDI citation.
Here, at the element-level in DDI 3.2, a citation includes DDI elements and Dublin Core elements.
Another example: the substitution of certain GSIM objects with OWL-S objects turns a model that was conceptual and human-readable into a model that is actionable and machine-readable.
A second standard may be complementary to DDI when it fills a "gap". For example, SDMX adds missing elements to the DDI ncube; the ncube characterizes aggregate data such as an OLAP cube or a statistical dataset.
Two standards are said to be non-complementary if the parts of each described in the profile are overlapping. See "Duplication" and "False Friends" below.
Model and element mapping [EH: Needs input from modellers]
The critical part of evaluating interoperability between standards is conducting model and element mappings. Modellers can use their own tools and techniques for mappings, with the following principles:
Model mapping
Go to source model and evaluate objects, definitions, and relationships for conformance. See "Conformance to DDI" for more information.
Ensure that objects with same label or definition are not duplicated within a profile.
Element mapping
Evaluate the elements in the standards to be used with DDI, in particular the element labels and definitions.
Look for element groupings and splits, where an element in one standard is expressed as two elements in the other.
Look for element hierarchy and nesting issues, as well as dependencies and constraints.
Ensure that elements with same label or definition are not duplicated within a profile.
Beware of "False friends": elements that have the same or similar labels or definitions, but are conceptually different.
If two or more standards are sufficiently interoperable, they can be defined in a profile. More information on the extent of interoperability will be discovered, and should be documented, during the development of a profile.
DDI Profiles
A profile is a specification on the use of a particular standard or group of standards to support interoperability for or within an application, function, community, or environment. DDI profiles are most likely to be created for an application, such as a statistical information system, or a function, e.g. data librarian.
A profile should also include at a minimum a DDI functional view, which is composed of DDI objects, and some part or all of an external standard, as well as locally-defined elements.
The scenarios of interoperation defined in a profile can take the form of one or more representations in which the interoperation is articulated. Representations can be included as appendices in a profile. A representation can take several forms including a UML model, an RDF specification, or an OWL specification. If the external standard has a UML model, the scenarios of interoperation are best described in a UML model. If the external standard has an RDF vocabulary, the scenarios of interoperation are best described in an RDF specification. Alternatively, OWL can be used to specify the scenarios of interoperation.
Profiles are also useful for identifying gaps between standards, which can be filled through subsequent versions of standards or new standards.
It is recommended to use existing profiles wherever possible, before creating new ones.
Developing a profile
The construction of the profile is guided by several principles:
A profile restricts the choice of base standard options to the extent necessary to maximize the probability of interworking;
However, it must not specify any requirements that would contradict or cause non-conformance to a base standard;
But it may specify requirements that are more specific than those of the base standard.
Conformance to a profile, therefore, implies conformance to the base standards referenced in the profile. Conformance to the base standards, however, does not necessarily imply conformance to the profile..
When developing a profile, consider the following: (to be developed)
A
B
C
D
In the file analysis conformance is to the combination of standards, distinct from conformance to the base standards in isolation. This combination frequently takes a form distinct from the base standards and is characterized quite often by changes in relationships:
Unconditional mandatory requirements in the base standard should remain mandatory in the profile.
Unconditional options in base standards may remain optional or may be changed within the profile to become:
mandatory:
conditional, giving rise to different statuses dependent upon some appropriate condition;
out of scope, if the option is not relevant to the scope of the profile - for example functional elements which are unused in the context of the profile;
prohibited, if the use of the option is to be regarded as non-conformant behaviour within the context of the profile - this choice should only be used when really necessary, "out of scope" may often be more appropriate.
If the conditions in the conditional requirements in the base standards can be fully evaluated in the context of the profile, then these requirements become unconditional mandatory requirements or unconditional options, or they become out of scope or prohibited. Otherwise the conditions remain conditional, with the appropriate, possibly partially, evaluated conditions.