Identifiable objects: standard contents
A report to the Modeling Group from the Technical Committee – 2014-07-23
This document brings together the consensus from the Technical Committee plus other interested modelers and is based on discussions during TC meetings in June/July 2014. The agenda topics included for these meetings included: Identification (separate paper), Name/Label/Description, what objects are referenced, and Administrative metadata. Minutes from these meetings have been posted to the modeler's site.
This document contains information on the following:
Consensus was to develop a set of general guidelines at the start since we don't know how we're grouping things yet in the new model. The idea is that we will tighten up the guidelines as we go and encourage modelers to be diligent about capturing the reasoning behind the decisions they make on this as they go.
If it makes sense as an object on its own, not just as a property of its ownership
Modelers should document the reasoning behind other factors that influence decisions to make an object reference-able
Object Type |
Definition |
Example |
All objects |
All UML objects within the DDI Object Library |
Concept, StructuredString, xs:string, etc. |
Properties |
Objects whose content makes sense only in its relationship to its parent object. Properties may be simple primitives, extended primitives, or complex objects |
Simple primitive: xs:string, xs:Boolean |
Identified objects (listed in "Relationship" in Drupal) |
Objects which are managed over time or are items which must be referenced by another object |
Concept, Category, Measure, Individual, etc. |
Referenced objects |
Objects which are not managed but which another item must make reference to |
A code within a codelist has no individually managed existence, however, the individual code needs to be referenced by a category level statistic in order to relate the value of the statistic to the specific code within the code list |
Managed objects |
Objects that have meaning outside of their use and are managed over time (versioned) |
Concept, Universe, Individual, Machine, Organization |
See "Names and Labels.pptx" for background information provided by Dan Gillman
In creating DDI 3.0, we inherited the idea of Name, Label, and Description from the DDI-C "var". In DDI-C a variable had a required name attribute which generally contained a unique name used by a statistical package, a label used by the statistical package, and a text which allowed for further expansion of the label. Depending upon the software used to create the DDI-C instance and the conventions of the agency creating the document, name could be a duplication of the id and label content could end up either in the label or text depending upon its length, and text might contain a long label or a further description of the variable. Name was carried over in an Identifiable Type as a "local" form of identifier.
In DDI 3.1 a consistent set of objects was applied to objects that were intended to be managed within a registry. This included a standardized XxxName, Label, and Description where Xxx was the object being named (i.e. VariableName). The original Name in the Identifiable Type was changed to a UserID designating it specifically as a local identifier.
In DDI 3.2 this standard set of objects was applied consistently to all managed objects (maintainables and versionables within schemes).
During the usage of these terms in DDI the description of their usage has varied and there has been inconsistency in their applied usage. In addition, there have been changes in the ISO/IEC 11179 description of the use of Name, Label, and Description as they were included in DDI 3.1. For this reason, we asked Dan Gillman to provide a clear conceptual basis for further work in this area. (See "Names and Labels.pptx")
Name and Label are synonyms and the DDI usage guidelines have been imprecise and variable over time. A Label is a representation of an object by a sign which denotes it. A Label can be further specialized as an identifier, locator, or designation. A DDI Description has been used a general description of intent, usage, or anything else we want to say about the object, as well as a definition (and sometimes both at once).
Labels
Definitions
DDI requires the use of labels that serve as locators and designations as well as means of providing a definition and in some cases a description.
Locator:
Designation:
Definition:
Description:
Determine membership of sub-groups of all managed objects. Possible sub-sets include the following and indicate which standard objects should be applied to the group:
Sub-set |
Locator |
Designation |
Definition |
Description |
GSIM objects [Concept, Universe, Conceptual Variable, Represented Variable, Category, Classification] |
X |
X |
X |
|
Variable |
X |
X |
X |
X |
Representations [Value Representation, ResponseDomain] |
X |
X |
? |
X |
NCube |
X |
X |
? |
X |
Questions [Question Item, Question Grid, Question Block] |
X |
X |
|
X |
Instruments |
X |
X |
|
X |
Processing Instructions |
X |
X |
|
X |
Quality Statement |
X |
X |
|
X |
Control Constructs |
X |
X |
|
X |
Interviewer Instructions |
X |
X |
|
x |
Geographic Structure |
X |
|
X |
X |
Geographic Location |
X |
|
X |
X |
Processing Events |
X |
|
|
X |
Physical Structure |
X |
|
|
X |
Record Layout |
X |
|
|
X |
Agents |
X |
|
|
|
Variable is a special case because of its interaction with statistical packages. However, it is defined by its component parts (concept, universe, representation, represented variable, derivation command, etc.) Consider its special need for:
See AdministrativeObjects_3_2.xslx
This spreadsheet contains the set of Administrative metadata currently found in a DDI 3.2 maintainable and reference. The maintainable in 3.2 is an extension of versionable which itself extends identifiable. Therefore a maintainable contains all of the administrative metadata objects with the exception of the self-describing attributes "isIdentifiable" and "isVersionable".
We made the following assumptions:
The columns include the following information: