Metadata Working Group

Working Group Projects

ISO/IEC JTC 1 / SC 32 / WG 02

Data Element Registry Content Technical Report
(BNE 024)

New Work Item - Draft for Discussion

The exchange of metadata between ISO/IEC 11179 metadata registries depends not only on registry software that conforms to the standard, but also on metadata contents that are compatible between registries. While the standard has provisions for data element specification and registration, there are pragmatic issues pertaining to populating the registries with content. Based on the experiences of organizations that are implementing the standard, a technical report to explore content issues could help current and future users.

ISO/IEC 11179, Part 3 and extensions proposed to it in a related New Work Item, have concentrated on the basic attributes of data elements. Much of the work done to date is for the "abstract" level, not "application" level data elements. Well-formed data elements and their domains can be recorded in a metadata registry as "models" for potential reuse. Additional attributes may be required to record essential facts about how a data element is used in an application. Some potential attributes include "purpose for which data is collected", "statistical methodology used in data collection" and other potential data quality attributes. What other attributes are required? There is a need to address the attributes that should be documented at the application level. This will make use of the standard's extensibility, since all application level attributes cannot be established in advance. Scientific metadata is a special case of application metadata, which seems to have additional characteristics that should be explored.

The proposed revision of ISO/IEC 11179, Part 3, models a data element (DE) and its associated data element concept (DEC). A data element consists of the data element concept plus its representation. Creation of an application data element frequently requires additional qualification of the object class and/or property. Does this creation of an application element always cause the creation of an application data element concept? Does the qualified concept inherit meaning from the standard concept to which it is related, and is there an adequate place in the current scheme to store this relationship? How are application DEC's distinguished from other DEC's or is there a need to make such a distinction?

When a standard data element is created, its value domain is specified. A number of related application elements may be created that are related to this standard element by particularizing the value domain in different ways. The resulting data element's domains might be further constrained to produce still more data elements. How are these relationships to be recorded?

Data elements at the higher levels have been called "standard", "core", "reference", "abstract", "basic", "generic", etc. In other circumstances, however, the term "generic data element" is used to refer to a pairing of property and representation without object class. This is part of the effort to manage data value domains and to make them reusable. Some registries deal with these value domains by artificially adding an object class to create a "generic data element" or an "abstract data element". These issues are not simply terminology problems but are more basic difficulties involving the need for clarification and articulation of concepts.

Reusability of data value domains for code sets has long been recognized as beneficial. There are reusable data domains that are not enumerated. How can they best be represented?

There are levels of granularity of data that must be addressed. For example: Data element, data element concept, data group, data set, data system, Agency/program, and data architecture. The current and proposed attributes may not adequately specify the relationship of the DE/DEC to any of the other levels? What additional attributes are needed to describe of these levels? E.g., Zip Code is a part of "address", a grouping of data elements.

What are the trade-offs between qualifying a property (e.g., Dunn Identifier) vs. keeping the property unqualified, with the qualification entered at the DEC level? The metamodel has a place to put the qualifier for the DEC. Another example, Conflict Of Interest Plan Review Date could be implemented as: Object Class = Vendor Firm Property = COI Plan Review Date or Object Class = Vendor Firm COI Plan Review Property = Date or Object Class = Vendor Firm Property = Date and DEC qualifier = COI Plan Review. The rules for creation of Object Class (by concatenation, qualification, modification, particularization, etc.) need to be addressed.

When the "date" data element is standardized, it produces a standard data element that may be more properly referred to as a transfer or format standard. An application might have data elements such as "effective date of regulation" and "effective date of program". Should "effective date" be considered a property or should it be a data element requiring standardization?

Conceptualization and articulation of rules and relationships in the creation of object classes, properties, data element concepts and data elements are needed. Explication of the various possible levels of data elements and data element concepts and their relationships would greatly assist in the creation of shareable, well-formed data. Relationship and inheritance from the most abstract data element to the most concrete application data element needs to be specified. Reuse of data value domains should be enabled and regularized.

A technical report to clarify use and content in data registries is proposed to address these issues.