DDI3.2 Documentation¶
About¶
Copyright & Licence¶
DDI-Views Specification (Development Draft Q2) Copyright @ 2016 DDI Alliance. All Rights Reserved
Licence¶
The DDI-Views Specification (Development Draft) us free software you can distribute it and/or modify it under the terms of the Creative Commons Attribution 4.0 International (CC BY 4.0) licence,
This is a human-readable summary of (and not a substitute for) the license
You are free to:
Share - copy and redistribute the material in any medium or format Adapt - remix, transform, and build upon the material for any purpose, even commercially.
The licensor cannot revoke these freedoms as long as you follow the license terms.
Attribution¶
You must give appropriate credit, provide a link to the license, and indicate if changes were made. You may do so in any reasonable manner, but not in any way that suggests the licensor endorses you or your use. No additional restrictions � You may not apply legal terms or technological measures that legally restrict others from doing anything the license permits.
Notices¶
You do not have to comply with the license for elements of the material in the public domain or where your use is permitted by an applicable exception or limitation. No warranties are given. The license may not give you all of the permissions necessary for your intended use. For example, other rights such as publicity, privacy, or moral rights may limit how you use the material.
Contacting Us¶
General information on the review can be found on the Review pages at https://ddi-alliance.atlassian.net/wiki/display/DDI4/How+to+Review+the+2016+Q2+Development+Draft
Comments and questions on the content of this document and the review process more generally should be directed to the Technical Committee list <mailto:ddi-srg@icpsr.umich.edu> or the Technical Committee Chair, Wendy Thomas wlt@umn.edu.
Relationship to other Standards¶
In constructing DDI special care was taken to review related standards as well as previous versions of DDI in order to provide clear mapping to the contents of outside standards or to incorporate content where appropriate. Over 25 standards were evaluated. DDI 3 currently has mapped relationships to the following standards:
DDI Codebook (DDI-C) and earlier versions¶
After conceptualizing the lifecycle model and the design rules for reuse, DDI-C content was distributed to the schemas comprising DDI-L. Specific mapping of objects from DDI-C to DDI-L brought to light a number of specific issues which were then addressed during DDI –L revisions. While specific objects may not always have a specific 1:1 correlation in 3.0, the content of all 2.1 objects has been captured, often in greater detail or a more consistent manner than in earlier DDI versions. During the development of DDI 3.2 changes were made in DDI-C to incorporate more content from the Generic Statistical Business Process Model (GSBPM) and to add objects that would ease the translation of DDI-C into DD-L. These objects were also added to DDI-L if not already present.
Dublin Core and MARC¶
All citations in DDI-L provide the option of entering a supplemental citation in native qualified Dublin Core (DCTerms). In addition, the contents of both qualified Dublin Core and the more extensive MARC record can be mapped to objects in DDI-L. DDI-L has divided the contents of these records to a number of complex element groups within DDI to facilitate reuse of specific sub-structures. The major divisions include:
- Citation – This structure is used for both DDI content citations and citations for external materials.
- Coverage – Temporal, Topical, and Spatial coverage map to content coverage dates, subject and keyword topics, and geographic coverage elements. They are held separately in DDI-L in order to allow coverage constraint for modules within a single StudyUnit or Group.
- Location Specific Information – Some information such as acquisition date, call number, local identifiers, etc. are related to a specific holding and are therefore located in the ArchiveSpecific section of the ArchiveModule. This facilitates packaging for transfer and incorporation into a different archive.
GSIM (Generic Statistical Information Model)¶
GSIM provides a standardized set of information objects that flow through the process model in the creation of official statistics as represented by the Generic Statistical Business Process Model (GSBPM). GSBPM has been of interest to DDI since in conception. The DDI Generic Longitudinal Business Process Model (GLBPM) is modeled on the GSBPM which itself was informed by the DDI Lifecycle Model. DDI has worked with the UNECE in the development of GSIM to ensure that these two standards are compatible. In general, GSIM is a conceptual model whereas DDI is an implementation model. There is a shared interest in ensuring that DDI-L can be used as a means of implementing the GSIM conceptual model.
Mapping work and the development of DDI profiles to support GSIM are taking place within that community. A primary area for close mapping to the GSIM structure lies in that areas that relate to their reflection of the ISO/IEC 11179 Data Element Classification Structure. The terminology for the objects as well as the documentation for the objects reflects the GSIM model.
This standard describes the structure and content of a data element as the basic building block of information. DDI -L is particularly concerned with providing the information needed to populate an ISO/IEC 11179 data element and support a registry structure. The following diagram provides the Data Element Structure.
Figure 1. ISO11179 Data Element Structure
International Standard ISO/IEC 11179-1: Information technology – Specification and standardization of data elements – Part 1: Framework for the specification and standardization of data elements Technologies de l’informatin – Spécifiction et normalization des elements de données – Partie 1: Cadre pout la specification et la normalization des elements de données. First edition 1999-12-01 (p26) https://www.oasis-open.org/committees/download.php/6233/c002349_ISO_IEC_11179-1_1999%28E%29.pdf
In DDI terminology, the Object Class is defined by the universe, its Property is the concept, and the Representation is the Representation content used by the Variable that measures it.
ConceptualComponent contains Universe and Concept definitions while Representation is described within the Variable. In most DDI instances it is the Variable that ties the three sections of this definition together. Note that if the Variable does not include a concept reference the instance is not compliant with ISO/IEC 11179.
DDI 3.2 has added the ability to create the more abstract (or reusable) descriptions of an ISO/IEC 11179 Data Element and Data Element Concept. These have been structured to align with the GSIM description (see GSIM in this section). The 3.1 element DataElementConcept has been replaced by a ConceptualVariable located within ConceptualComponent. This object links a Concept with a Universe creating the equivalent of the ISO/IEC 11179 Data Element Concept. A RepresentedVariable located in Logical Product, adds the expression of the representation to the concept and universe. This is the reusable set of information for a Variable which is the implementation of a RepresentedVariable within a specific usage. The underlying RepresentedVariable may be referenced from the Variable
ISO/IEC 11179¶
DDI-L reflects ISO/IEC 11179 structure in several respects. First, it maps the core structures Concept, Universe, ConceptualVariable, and RepresentedVariable to the ISO/IEC 11179 Data Element Classification Structure. The structure presented in DDI 3.2 aligns with the representation of this ISO standard through the GSIM structure. (See GSIM discussion within this section).
Secondly, DDI-L has adopted the combination of the Agency, ID, and Version as the full unique identification of an object. This is reflected in the identification model and content of the DDI URN. Finally, DDI-L has incorporated the ISO/IEC 11179-5 structure of providing a Name, Label, and Description for all primary objects (maintainable and versionable) that are not considered publication structures. Publication structures have complete citation information plus an abstract. The objects with this common descriptive set are those that are commonly managed with registries over time.
ISO 19118 - Geography¶
The construction of geographic objects within DDI was done using the US FGDC which is ISO 19118 compliant. The content of the following objects map to these geographic standards:
In SpatialCoverage:
- Bounding Box
- Spatial Object (SpatialPrimative)
- TopLevelReference
- LowestLevelReference
- BoundingPolygon
- Point
In GeographicResponseDomain:
- Datum
- CoordianteSystem
- CoordinateZone
- ErrorCorrection
- Offset
- GeoreferencedObject
- CoordinatePairs
- SpatialPrimitive
The use of these fields provides search information for coordinate based search systems and detailed information needed by the geographer to determine the usefulness of a specific data set for geographic analysis.
SDMX¶
Careful comparison was made between DDI-C nCubes and SDMX structures. In evaluating the structure and application of these two specifications it was concluded that while basic SDMX structures could be described as nCubes, not all nCubes could be described in SDMX. SDMX deals with well structured, well defined data which contains a time dimension. Not all legacy data contains well structured and well defined aggregate data and nCubes provide support for these structures. SDMX contained a more flexible approach to attaching information to regions of cells within the matrix and used a standard attribute structure to define all aspects of the matrix from the label to the cell content.
SDMX requires the data cell content to be within the structure while DDI nCubes allow for the separation of metadata description and data content. In DDI-L the NCube structure retains the specified objects for Label, Universe, Dimensions, and Measure but adds the Attribute object and the ability to define regions of the matrix and to attach attributes to these regions. DDI-L NCubes were designed to map to both earlier nCube structures and to SDMX providing support for using SDMX as a data transfer or storage structure.
METS¶
METS is a standard developed as an initiative of the Digital Library Federation and provides a consistent outer wrapper for digital objects described by a variety of METS profiles. The METS structure was consulted in developing the structure for the Collection and Item objects in Archive and the intent is to write and register a METS Profile for DDI.
PREMIS¶
PREMIS is a common implementation of Open Archive Information System (OAIS). There is a preliminary mapping of DDI-L to PREMIS objects. The focus of PREMIS is preservation and there are several elements where DDI-L does not provide controlled content. However, with the ability to publish controlled vocabularies external to the DDI specification, we should be able to address all but a few of the PREMIS objects. Further alignment with OAIS requirements as expressed in PREMIS and other preservation will take place as DDI-L expands into process models, provenance, and archive management content.
General Structures¶
Identification, Versioning, Maintenance and Reference¶
The identification structure of DDI objects is core to the functioning of the standard. The purpose of the DDI identification structure is to:
- Uniquely identify major objects in a persistent manner to ensure accurate reference and retrieval of the object content
- Provide context for objects where an understanding of related object types within a packaging structure is essential to the understanding of the object (i.e., a specific classification within a classification scheme)
- Manage metadata object change over time
- Support the range of object management used by different organizations
- Support early and late binding of references
- Support interaction with closely related standards, in particular ISO/IEC 11179 and SDMX
The identification structure is based on the ISO/IEC 11179 structure that requires a three-part means of unique identification.
| OBJECT | ISO/IEC 11179 | DDI |
|---|---|---|
| Agency Identifier | A unique identifier for the agency managing the object | A unique identifier for an agency registered with the DDI Alliance. The agency may have multiple sub-agency extensions managed within the DDI Registry or within the primary agency. An agency and sub-agency are separated by an “.”. |
| Unique ID | A unique identifier of the object within the context of the agency | An identification which is unique within
|
| Version Number | A version number of the object to track change over time | A version number with any number of extensions separated by a “.”. |
This three part structure is the equivalent of a unique persistent identifier for an object, such as described by DOIs and other similar structures. Note that while use of a version number with a DOI is optional, based on local practice, the Version Number in DDI is required due to the need to manage metadata within a dynamic workflow over time.
Identifiable, Versionable, and Maintainable¶
DDI differentiates between a set of element types. Not all objects are individually identifiable, i.e. some objects only have meaning within the context of an identifiable object such as a Label or Description. The remaining objects are Identifiable, Versionable or Maintainable in order to support different levels of metadata management.
Identifiable objects are those that can be referenced directly either for inclusion in another object or for the purpose of attaching Other Material or a Note to the object. Identifiable objects have a unique ID within the context of their specified scope of uniqueness (see Scope of Uniqueness discussion within this section). Their Agency Identification and Version Number match those of the object’s immediate parent Versionable (or Maintainable if there is not a parent Versionable) at the point of creation. This means that if an Identifiable object is created within a version 1 of a parent Versionable and does NOT change its content over time it will retain its Version Number of 1 until the identifiable object itself is altered. It will then change its Version Number to that of its parent Versionable at the time of the alteration. In other words an Identifiable could go from a Version 1 to a Version 4 without ever having a Version 2 or 3 if the cause for versioning did not involve any change in the Identifiable object within Version 2 and 3 of the parent Versionable.
A Versionable object has the characteristics of an Identifiable object but may be managed over time. DDI has determined that being able to track change within the object over time is a requirement, either to understand the relationship to earlier objects of a similar type or to track provenance. Note that it is up to the individual content provider to determine whether an object is essentially new or is a modification (version) of an earlier object. Versionable objects have a unique ID within the context of their specified scope of uniqueness (see Scope of Uniqueness discussion within this section). Their Agency identification matches that of the object’s immediate parent Maintainable at the point of creation. In other words the Agency of an object does not change simply because it is included by reference in a Maintainable managed by a different agency. The Version number of the object changes each time its content changes. See Versioning for a discussion of when and how this may be implanted within different organizations or projects.
A Maintainable object is a type of packaging and generally takes the form of either a module or scheme. Modules package metadata focused on specified segments of the Lifecycle for which context is important for understanding. Schemes are similar to data base tables, containing a stack of similar type objects that many have important contextual relevance to each other, i.e. a classification scheme captured in a DDI Category Scheme. There is one unique form of a Maintainable which is the CodeList. A CodeList is a Maintainable in its own right for the purpose of supporting the statistical production process. However it can only be published within the context of a parent Maintainable Scheme. All Schemes and Modules may be published within the context of a Study Unit or Group (a collection of Study Units) or as a separate Resource Package item primarily for the purpose of reuse.
Versioning¶
In general, once metadata is published (i.e. flagged as being stable for referencing purposes) any change to the content should result in a version change to the Versionable object containing the change. Note that as Versionable objects are contained by Maintainable objects and that Maintainable object may be contained in another Maintainable object, a single change will generally trigger Versioning up the containing tree of the metadata. The purpose of versioning is to ensure that someone referencing a specific version of an object will always get back the same information.
Versioning rules and Version Number structures differ between different organizations and between different projects or products of the same organization. DDI does not dictate this structure EXCEPT to specify that it must be expressed as one or more integers separated by a “.” (dot). The DDI Lifecycle specification uses a three part structure of a Major.Minor.Sub-Minor version number. The Organization should describe its versioning system or systems so that it is clear to the user when and how versioning occurs. Versioning is “required” once a Maintainable object is flagged isPublished=”true”. During production processes, tracking version changes may be managed by other means such as Version Date or an external subversion system.
Some organizations are stricter in their versioning rules than others. For example, a typographical correction within a Description text which is considered to have no impact on the intellectual content may trigger a Minor or Sub-minor version change in one system while only result in Version Date change in another. Because the impact of a change cannot be easily predicted (it is dependent upon the use of the metadata) the important thing is to capture that a change was made and to provide the end user with a clear set of versioning rules that supports their ability to evaluate the impact of the change for their particular use. In addition, some metadata is considered local in nature, specific to interaction with an identified system. This metadata is considered to be Administrative in nature and is viewed by DDI as a set of metadata that does not alter the intellection content (Payload) of the metadata and does not need to drive a version change.
Administrative and Payload Metadata¶
The differentiation between Administrative metadata and Payload metadata lies primarily in how changes to the metadata content drive version changes.
Administrative metadata is content that is related to the interaction or use of the metadata within a specific system. Changes in administrative metadata do not change the meaning of the metadata content of the object in terms of its DDI identification or intellectual meaning. For example, the addition of a local User Identification to facilitate interaction between the metadata object and local access software, or creating a URN entry from existing identification sequence content are considered to be changes to the Administrative metadata. A change in Administrative metadata does not trigger a change in the version number of a published object.
Payload metadata is all metadata NOT defined as Administrative. Payload metadata contains intellectual content that has an impact on the meaning or application of the object. A change in Payload metadata generally triggers a change in the version number of a published object.
Identifiable, Versionable, Maintainable¶
Figure 2. The relationship between identifiable, versionable and maintainable type objects
N.B.Those names starting with @ are XML attributes, all others are XML elements.
The following objects which consist of the extension bases used for identification and referencing purposes are considered to be Administrative metadata for the purposes of versioning:
Identifiable¶
| Identifiable Object | Extension base is AbstractIdentifiable |
|---|---|
| URN | See URN Structure below |
| @typeOfIdentifier | URN used by Agency [Canonical | Deprecated] |
| Agency | Base sequence of identification. If sequence is used, all are required. |
| ID | |
| Version | |
| UserID | |
| @typeOfUserID | A user specified identification for a specific system such as a DOI or internal search engine. Both the ID and @typeOfUserID must be specified. Version information is optional. |
| @userIDVersion | |
| @typeOfUserVersion | |
| MaintainableObject | |
| TypeOfObject | The Maintainable object containing the Identifiable object. TypeOfObject is required to create Deprecated URN. ID is required for any URN if ScopeOfUniqueness = ”Maintainable”. Version number provides context base. |
| MaintainableID | |
| MaintainableVersion | |
| @inheritanceAction | See Grouping: Inheritance |
| @objectSource | The object source of a resolved reference |
| @scopeOfUniqueness | Scope used by Agency [Agency | Maintainable |
| @IsUniversallyUnique | States the scope of uniqueness for the ID |
| @isIdentifiable | Fixed value = “true” [specifies object base] |
Versionable¶
| Versionable Object | Extension base is AbstractIdentifiable |
|---|---|
| URN | See URN Structure below |
| @typeOfIdentifier | URN used by Agency [Canonical | Deprecated] |
| Agency | Base sequence of identification. If sequence is used, all are required. |
| ID | |
| Version | |
| UserID | |
| @typeOfUserID | A user specified identification for a specific system such as a DOI or internal search engine. Both the ID and @typeOfUserID must be specified. Version information is optional. |
| @userIDVersion | |
| @typeOfUserVersion | |
| UserAttributePair | |
| AttributeKey | User defined Key/Value pair used to support interaction of the metadata within the user’s system. |
| AttributeValue | |
| VersionResponsibility | Who within the Agency versioned the object |
| VesionResponsibilityReference | Alternate reference to who versioned the object |
| VersionRationale | Reason for version change (to inform user) |
| BasedOnReference | |
| MaintainableObject | |
| TypeOfObject | The Maintainable object containing the Identifiable object. TypeOfObject is required to create Deprecated URN. ID is required for any URN if ScopeOfUniqueness = ”Maintainable”. Version number provides context base. |
| MaintainableID | |
| MaintainableVersion | |
| @inheritanceAction | See Grouping: Inheritance |
| @objectSource | The object source of a resolved reference |
| @scopeOfUniqueness | Scope used by Agency [Agency | Maintainable |
| @IsUniversallyUnique | States the scope of uniqueness for the ID |
| @isVersionable | Fixed value = “true” [specifies object base] |
| @versionDate | Date/Time of version change |
Maintainable¶
| Maintainable Object | Extension base is AbstractMaintainable |
|---|---|
| URN | See URN Structure below |
| @typeOfIdentifier | URN used by Agency [Canonical | Deprecated] |
| Agency | Base sequence of identification. If sequence is used, all are required |
| ID | |
| Version | |
| UserID | |
| @typeOfUserID | A user specified identification for a specific system such as a DOI or internal search engine. Version information is optional. Both the ID and @typeOfUserID must be specified. |
| @userIDVersion | |
| @typeOfUserVersion | |
| UserAttributePair | |
| AttributeKey | User defined Key/Value pair used to support interaction of the metadata within the user’s system. |
| AttributeValue | |
| VersionResponsibility | Who within the Agency versioned the object |
| VesionResponsibilityReference | Alternate reference to who versioned the object |
| VersionRationale | Reason for version change (to inform user) |
| BasedOnReference | |
| Note | Notes related to objects with the maintainable (Payload) |
| Software | Software used to create the Maintainable object (Payload) |
| MetadataQuality | Quality of the metadata in the Maintainable object (Payload) |
| MaintainableObject | Same as Identifiable Object |
| @inheritanceAction | See Grouping: Inheritance |
| @objectSource | The object source of a resolved reference |
| @scopeOfUniqueness | Scope used by Agency [Agency | Maintainable |
| @IsUniversallyUnique | States the scope of uniqueness for the ID |
| @isMaintainable | Fixed value = “true” [specifies object base] |
| @versionDate | Date/Time of version change |
| @externalReferenceDefaultURI | Indicates that the content is available for reuse by reference |
| @isPublished | Indicates that the contents are persistent and can be referenced by external documents |
| @xml:lang | The language of the metadata in the Maintainable object (Payload) |
Figure 3. The relationship between ReferenceType and SchemeReferenceType
Reference Type¶
| Reference Type | |
|---|---|
| URN | The URN of the object being referenced using the specified URN structure |
| @typeOfIdentifier | URN used by Agency [Canonical | Deprecated] |
| Agency | Base sequence of identification. If sequence is used, all are required. |
| ID | The ID of the object being referenced. |
| Version | The Version of the object being referenced. This is the full Version number at the time the reference is created. |
| TypeOfObject | Type of object being referenced. This is a controlled list. |
| MaintainableObject | The Maintainable object containing of the Identifiable or Versionable object being referenced. |
| TypeOfObject | TypeOfObject is required to create Deprecated URN |
| MaintainableID | Required for any URN if ScopeOfUniqueness=”Maintainable”. |
| MaintainableVersion | Provides context base |
| @isExternal | Boolean attribute. If “true” you must supply the URN |
| @externalReferenceDefaultURI | A local store for the referenced object expressed as a URI |
| @isReference | Fixed value = “true” [specifies object base] |
| @lateBound | Boolean attribute. Set to “true” if you wish to late-bind the reference (i.e., want to reference the most recent version) |
| @lateBoundRestriction | If @lateBound=”true” and this attribute is not provided you will get the most recent version. Use this attribute to restrict the value of the late-bind, for example to restrict to the most recent minor version of major version |
| @objectLanguage | Specify the desired language content (if available) for the referenced item using a valid xml:lang value. |
| @sourceContext | The URN of the parent maintainable at the time of reference (this is not necessarily the same version number as the version of the parent maintainable at point of origin) |
Scheme Reference Type¶
| Scheme Reference Type | |
|---|---|
| URN | The URN of the object being referenced using the specified URN structure |
| @typeOfIdentifier | URN used by Agency [Canonical | Deprecated] |
| Agency | Base sequence of identification. If sequence is used, all are required. |
| ID | The ID of the object being referenced. |
| Version | The Version of the object being referenced. This is the full Version number at the time the reference is created. |
| TypeOfObject | Type of object being referenced. This is a controlled list. |
| MaintainableObject | The Maintainable object containing of the Identifiable or Versionable object being referenced. |
| TypeOfObject | TypeOfObject is required to create a Deprecated URN |
| MaintainableID | Required for any URN if ScopeOfUniqueness=”Maintainable”. |
| MaintainableVersion | Provides context base |
| Exclude | Allows the identification of objects within the Scheme which are to be excluded for the purpose of this reference. |
| ID | The ID of the excluded object. |
| Version | The Version of the excluded object. |
| @isExternal | Boolean attribute. If “true” you must supply the URN |
| @externalReferenceDefaultURI | A local store for the referenced object expressed as a URI |
| @isReference | Fixed value = “true” [specifies object base] |
| @lateBound | Boolean attribute. Set to “true” if you wish to late-bind the reference (i.e., want to reference the most recent version) |
| @lateBoundRestriction | If @lateBound=”true” and this attribute is not provided you will get the most recent version. Use this attribute to restrict the value of the late-bind, for example to restrict to the most recent minor version of major version |
| @objectLanguage | Specify the desired language content (if available) for the referenced item using a valid xml:lang value. |
| @sourceContext | The URN of the parent maintainable at the time of reference (this is not necessarily the same version number as the version of the parent maintainable at point of origin) |
Scope of Uniqueness¶
DDI 3.2 supports scoping the uniqueness of identifier to the parent Maintainable or to the Agency (subagency). This choice affects the structure of the ID as it appears within the Canonical URN (see Type of Identifier in this section). Essentially, when the ID is scoped to the Agency the unique identification of an object requires the Agency, ID of the object, and Version Number of the object. When the ID is scoped to the Maintainable the unique identification of a non-Maintainable object requires the Agency, ID of the parent Maintainable, the ID of the object, and the Version Number of the object. The attribute scopeOfUniqueness is required and must contain either “Agency” or “Maintainable”. This attribute defines how the ID will be expressed in the Canonical URN and what is required for a complete reference to the object within the Maintaining Agency.
Type of Identifier¶
DDI 3.2 supports two formats for expressing the Identification Sequence as a URN. The Canonical URN is recommended. The Deprecated URN is a modification of the DDI 3.1 URN. Whether the identification information is expressed as a URN or using the Identification Sequence the attribute “typeOfIdentifier” on the URN dictates the format of the URN supported internally by the agency and the format of the URN used by an external reference to that object. Note that regardless of the type of identifier used it is good practice to provide the full content of the Identification Sequence and details of the MaintainableObject for non-Maintainable objects in order to support the creation of any format of a DDI URN.
Structure of the URN¶
Canonical URN¶
Each section of the Canonical URN is separated by a “:” (colon). Within the ID section the Maintainable ID and Object ID are separated by a “.” (dot).
urn:ddi:agency[.sub-agency]:ID:Version
If the scopeOfUniqueness equals “Agency” the ID is the ID of the object.
Example: Canonical URN with uniqueness scoped to the Agency.¶
Object V321 version 2 within the Minnesota Population Center (us.mpc)
Object V321 version 2 within the Minnesota Population Center, Project IPUMS (listed as a sub-agency within us.mpc)
If the scopeOfUniqueness equals “Maintainable” the ID of a non-Maintainable object is structured as follows:
Example: Canonical URN with uniqueness scoped to the Maintainable.¶
Variable V321 version 2 within VariableScheme VS1 at the Minnesota Population Center (us.mpc)
Variable V321 version 2 within VariableScheme VS1 at the Minnesota Population Center, Project IPUMS (listed as a sub-agency within us.mpc)
Deprecated URN¶
Each section of the Deprecated URN is separated by a “:” (colon).
If the object itself is Maintainable the information on the parent maintainable is not included:
urn:ddi:agency[.sub-agency]: ObjectType:ObjectID:ObjectVersion
If the scopeOfUniqueness equals “Agency” the ID is the ID of the object.
Example: Deprecated URN with uniqueness scoped to the Agency.¶
Object V321 version 2 within the Minnesota Population Center (us.mpc)
urn:ddi:us.mpc:Variable:V321:2
Object V321 version 2 within the Minnesota Population Center, Project IPUMS (listed as a sub-agency within us.mpc)
urn:ddi:us.mpc.ipums:Variable:V321:2
If the scopeOfUniqueness equals “Maintainable” the ID of a non-Maintainable object is structured as follows:
urn:ddi:agency[.subagency]:MaintainableObjectType:MaintainableID:ObjectType:ObjectID:ObjectVersion
Example: Deprecated URN with uniqueness scoped to the Maintainable.¶
Variable V321 version 2 within VariableScheme VS1 at the Minnesota Population Center (us.mpc)
urn:ddi:us.mpc:VariableScheme:VS1:Variable:V321:2
Variable V321 version 2 within VariableScheme VS1 at the Minnesota Population Center, Project IPUMS (listed as a sub-agency within us.mpc)
Examples¶
Note that by including the information for the MaintainableObject in an Identifiable or Versionable the user has provided sufficient information to build either a Canonical or Deprecated URN scoped to either the agency or the maintainable. While the information may not be part of the URN as expressed by the maintaining agency, the information contained in the MaintainableObject provides contextual information that may be important to the user and may need to be passed to them for purposes other than strict identification. The inclusion of Versioning information in Versionable and Maintainable may be used internally to track quality control and processing activities and may also be valuable to the user in determining whether the change caused by versioning will affect their analysis work.
Identifiable¶
<l:Code isIdentifiable="true" scopeOfUniqueness="Maintainable">
<r:URN typeOfIdentifier="Canonical">
urn:ddi:us.mpc:CL\_1.Code\_1:1
</r:URN>
<r:Agency>us.mpc</r:Agency>
<r:ID>Code\_1</r:ID>
<r:Version>1</r:Version>
<r:UserID typeOfUserID="NHGIS">Gender\_1</r:UserID>
<r:MaintainableObject>
<r:TypeOfObject>CodeList</r:TypeOfObject>
<r:MaintainableID>CL\_1</r:MaintainableID>
<r:MaintainableVersion>1</r:MaintainableVersion>
</r:MaintainableObject>
...
</l:Code>
Minimum required content of the above:
<l:Code isIdentifiable="true" scopeOfUniqueness="Maintainable">
<r:URN typeOfIdentifier="Canonical">
urn:ddi:us.mpc:CL\_1.Code\_1:1
</r:URN>
...
</l:Code>
Versionable¶
<l:Variable isVersionable="true" scopeOfUniqueness="Agency" versionDate="2012-10-31">
<r:URN typeOfIdentifier="Canonical">
urn:ddi:us.mpc:Var\_1234:2
</r:URN>
<r:Agency>us.mpc</r:Agency>
<r:ID>Var\_1234</r:ID>
<r:Version>2</r:Version>
<r:UserID typeOfUserID="IPUMS">MOMLOC</r:UserID>
<r:VersionResponsibility>John Doe</r:VersionResponsibility>
<r:VersionRationale>
<r:RationaleDescription><r:String xml:lang="en">Expanded description to more clearly define the process of determining the MOCLOC value in households with multiple mothers.</r:String></r:RationaleDescription>
<r:RationaleCode>Update</r:RationaleCode>
</r:VersionRationale>
<r:MaintainableObject>
<r:TypeOfObject>VariableScheme</r:TypeOfObject>
<r:MaintainableID>VS\_IPUMS</r:MaintainableID>
<r:MaintainableVersion>6</r:MaintainableVersion>
</r:MaintainableObject>
...
</l:Variable>
Minimum required content of the above:
<l:Variable isVersionable="true" scopeOfUniqueness="Agency" versionDate="2012-10-31">
<r:URN typeOfIdentifier="Canonical">
urn:ddi:us.mpc:Var\_1234:2
</r:URN>
...
</l:Variable>
Maintainable¶
<l:VariableScheme isVersionable="true" scopeOfUniqueness="Agency" versionDate="2012-10-31" isPublished="true" xml:lang="en"> <r:URN typeOfIdentifier="Canonical"> urn:ddi:us.mpc:VS\_IPUMS:6 </r:URN> <r:Agency>us.mpc</r:Agency> <r:ID>VS\_IPUMS</r:ID> <r:Version>6</r:Version> <r:UserID typeOfUserID="IPUMS">IPUMS\_VARS</r:UserID> <r:VersionResponsibility>John Doe</r:VersionResponsibility> <r:VersionRationale> <r:RationaleDescription> <r:String xml:lang="en">Versioned MOMLOC</r:String> </r:RationaleDescription> <r:RationaleCode>Update</r:RationaleCode> </r:VersionRationale> <r:Software></r:Software> <r:MetadataQuality> <r:QualityMeature>InternalReview</r:QualityMeasure> <r:MeasurePurpose><r:Content xml:lang="en">Content has be reviewed and confirmed for use on Public site.</r:Content></r:MeasurePurpose> <r:MeasureValue>Public</r:MeasureValue> </r:MetadataQuality> ... </l:VariableScheme>
Minimum required content of the above:
<l:VariableScheme isVersionable="true" scopeOfUniqueness="Agency" versionDate="2012-10-31" isPublished="true" xml:lang="en">
<r:URN typeOfIdentifier="Canonical">
urn:ddi:us.mpc:VS\_IPUMS:6
</r:URN>
...
</l:VariableScheme>
Reference¶
Note that in this case Version 1 of Var_1234 originally appeared in Version 1 of VS_IPUMS. However, the sourceContext indicates that VS_IPUMS:4 is the context at the point of reference.
<l:VariableReference isReference="true" isExternal="false" lateBound="false" objectLanguage="en" sourceContext="urn:ddi:us.mpc:VS\_IPUMS:4.0">
<r:URN typeOfIdentifier="Canonical">
urn:ddi:us.mpc:Var\_1234:1.0
</r:URN>
<r:Agency>us.mpc</r:Agency>
<r:ID>Var\_1234</r:ID>
<r:Version>1.0</r:Version>
<r:TypeOfObject>Variable</r:TypeOfObject>
<r:MaintainableObject>
<r:TypeOfObject>VariableScheme</r:TypeOfObject>
<r:MaintainableID>VS\_IPUMS</r:MaintainableID>
<r:MaintainableVersion>1.0</r:MaintainableVersion>
</r:MaintainableObject>
</l:VariableReference>
Minimum required content of the above:
<l:VariableReference isReference="true" isExternal="false" lateBound="false">
<r:URN typeOfIdentifier="Canonical">
urn:ddi:us.mpc:Var\_1234:1.0
</r:URN>
<r:TypeOfObject>Variable</r:TypeOfObject>
</l:VariableReference>
Above reference as a lateBound reference where the most recent minor version of major version 1 of the variable is being requested.:
<l:VariableReference isReference="true" isExternal="false" lateBound="true" objectLanguage="en" sourceContext="urn:ddi:us.mpc:VS\_IPUMS:4.0" lateBoundRestriction="1">
<r:URN typeOfIdentifier="Canonical">
urn:ddi:us.mpc:Var\_1234:1.0
</r:URN>
<r:Agency>us.mpc</r:Agency>
<r:ID>Var\_1234</r:ID>
<r:Version>1.0</r:Version>
<r:TypeOfObject>Variable</r:TypeOfObject>
<r:MaintainableObject>
<r:TypeOfObject>VariableScheme</r:TypeOfObject>
<r:MaintainableID>VS\_IPUMS</r:MaintainableID>
<r:MaintainableVersion>1.0</r:MaintainableVersion>
</r:MaintainableObject>
</l:VariableReference>
SchemeReference¶
<l:VariableSchemeReference isReference="true" isExternal="false" lateBound="false" objectLanguage="en">
<r:URN typeOfIdentifier="Canonical">
urn:ddi:us.mpc:VS\_IPUMS:1.0
</r:URN>
<r:Agency>us.mpc</r:Agency>
<r:ID>VS\_IPUMS</r:ID>
<r:Version>1.0</r:Version>
<r:TypeOfObject>VariableScheme</r:TypeOfObject>
<r:Exclude isReference="true" isExternal="false" lateBound="false" typeOfIdentifier="Canonical">
<r:URN>urn:ddi:us.mpc:Var\_1234:1.0</r:URN>
<r:TypeOfObject>Variable</r:TypeOfObject>
</l:Exclude>
</l:VariableSchemeReference>
Minimum required content of the above:
<l:VariableSchemeReference isReference="true" isExternal="false" lateBound="false" objectLanguage="en">
<r:URN typeOfIdentifier="Canonical">
urn:ddi:us.mpc:VS\_IPUMS:1.0
</r:URN>
<r:TypeOfObject>VariableScheme</r:TypeOfObject>
<r:Exclude isReference="true" isExternal="false" lateBound="false" typeOfIdentifier="Canonical">
<r:URN>urn:ddi:us.mpc:Var\_1234:1.0</r:URN>
<r:TypeOfObject>Variable</r:TypeOfObject>
</l:Exclude>
</l:VariableSchemeReference>
Maintainable Objects: Modules and Schemes¶
Maintainable objects are of two basic types, Modules and Schemes.
Modules roughly relate to stages in the life cycle or publishing packages. Publishing packages pull together related material regarding a study, a series or group of studies, reusable resources, or deposited objects. Modules like DataCollection, LogicalProduct, PhysicalDataProduct, and ConceptualComponents bring together sets of information related to specific activities, the results of a study, or conceptual background. They may include other modules, schemes, or non-scheme based objects.
Schemes are designed to bring together sets of similar objects (i.e. Variables, Concepts, RecordLayouts, etc.) which are managed as a unit for either conceptual or administrative purposes. Schemes have a common structure providing descriptive information about the scheme, a set of similar objects, and the ability to group those objects for administrative purposes.
Name, Label, and Description¶
DDI modules designed to contain published objects (DDIInstance, StudyUnit, Group, ResourcePackage, LocalHoldingPackage, and PhysicalInstance) all contain full citation information which provides detailed information on the name of the object, as well as means of labeling and describing it. DDI has identified a number of objects, primarily non-publication structure modules, schemes, and versionable objects within schemes as items that have the potential to be managed in an ISO/IEC 11179 type repository. In line with ISO/IEC 11179-5, DDI has provided this set of objects with a sequence of a name, label, and description. Label and Description are standard structures.
Name¶
Name is used as a type specification for a specific object name, i.e. VariableName type=”r:NameType”. A complete listing of objects of NameType will be found in Appendix: X.
A name is what an object is called within a registry. All elements of type NameType may be repeated to supply different names for different contexts, such as different sections within a registry system. Do not repeat the use of the NameType object to capture multilingual content. This is handled by the base type, InternationalString [see pt2:2.5.1]. Each String within the NameType represents the same content in a different language. Each language string can be identified by its language designation (with optional country specification, i.e. en-UK), with information on whether the content was translated, can be translated (i.e. is not machine code), the source langauges for the translation, and the translation date. The two attributes specific to NameType identify the preferred name if multiple name sets are available and capture the context within which the specified name is used. If the element of type NameType is repeated, it is the attribute context which is used to disambiguate between the options. The attribute isPreferred allows the content creator to designate the preferred or default name for the object.
NameType¶
------------------------------------------------------------
Namespace: r
Parent Maintainable: varies by usage
Type: InternationalStringType
------------------------------------------------------------
NameType
String (0..n)
@xml:lang (optional)
@isTranslated (default=”false”)
@isTranslatable (default=”true”)
@translationSourceLangauge (optional)
@translationDate (optional)
@isPreferred (optional)
@context (optional)
Label¶
A Label is intended to provide content for use in a display (a table layout, printed content, web site, etc.). In all locations where Label is used it may be repeated to reflect different types of label (i.e. a short label, or a full label, etc.). The Label uses an extension base of StructuredStringType which managed both multilingual content and allows for the use of a set of xhtml structure tags (see pt2:2.5.1). Differences in the intended use of each Label are expressed by the element TypeOfLabel and a set of attributes that apply to all language versions of the Label. The TypeOfLabel uses the extension base CodeValueType which supports the use of an external controlled vocabulary (see pt2:2.5.1). The attribute locationVariant is an xs:string to allow for either a common geographic specification such as a country code or a descriptive term (i.e. urban, northwest region, etc.). For Labels with a limited period of use the pair of attributes validForStartDate and validForEndDate allow clear specification for when a Label is valid. Finally the attribute maxLength is useful for identifying labels that must meet a specific length limitation, for example in publishing content within a specific format or software system.
Label¶
------------------------------------------------------------
Namespace: r
Parent Maintainable: varies by usage
Type: StructuredStringType
------------------------------------------------------------
Label
Content (0..n)
xhtml:BlkNoForm.mix (0..n)
@xml:lang (optional)
@isTranslated (default=”false”)
@isTranslatable (default=”true”)
@translationSourceLangauge (optional)
@translationDate (optional)
TypeOfLabel (0..n)
@locationVariant (optional)
@validForStartDate (optional)
@validForEndDate (optional)
@maxLength (optional)
Description¶
Description is of type StructuredStringType with no additional extensions. It generally appears with a cardinality of 0..1. If it is important to differentiate be original and added content it is possible to do this by using the content structure features of the StructuredString (see pt2:2.5.1). Note that if the object containing the Name, Label, Description sequence may be used in a comparison process, providing content for Description is critical as comparison is based upon the comparison of the Description of the object, not its Name or Label.
Description¶
------------------------------------------------------------
Namespace: r
Parent Maintainable: varies by usage
Type: StructuredStringType
------------------------------------------------------------
Description
Content (0..n)
xhtml:BlkNoForm.mix (0..n)
@xml:lang (optional)
@isTranslated (default=”false”)
@isTranslatable (default=”true”)
@translationSourceLangauge (optional)
@translationDate (optional)
Controlled Vocabularies¶
There are many points in the DDI where a controlled vocabulary is desired, but no single classification can be (or has been) identified which would be acceptable to all user communities. DDI-L provides a CodeValueType that allows for use of a simple descriptive term while also supporting the use of an externally described controlled vocabulary. A set of fields has been made available for identifying the following information about the controlled vocabulary including; the name or identifier, maintenance agency, version, and URL of the controlled vocabulary. DDI is supporting the option of developing and publishing controlled vocabularies expressed in a DDI profile of Genericode. These may be used directly or incorporated into local publications of controlled vocabularies that reflect those elements that are common with the DDI community and adding those that are specific to the the maintenance agency.
This approach supports sharing of common coding structures as well as the publication of code schemes in formats that can be mapped for comparability. DDI publishes a set of controlled vocabularies commonly used in social science research (http://www.ddialliance.org/controlled-vocabularies). These are presented in a variety of formats including Genericode XML.
User Attribute Pairs¶
UserAttributePair is a structure that supports the use of a user specified standard key value pair, this can be attached to any VersionableType, (these are listed in the documentation for UserAttributePair).
The intent of this structure is that it allows the addition of business specific metadata for primarily internal processes that is not likely to be widely shared between different organisations.
Examples of usage would be:
- Holding adhoc information about individuals such as place and date of birth,
- Adding additional functionality to an existing element such as a controlled vocabulary to copyright to support internal systems.
Representations¶
Representations describe the structure and content of data as it is captured from the population and held within a data file. They share common category schemes and code list as well as the means of defining numeric ranges and text content. DDI begins by defining the core descriptive content for a wide range of representations and then adds a set of common objects used by all Value Representations (Variables) or Response Domains (Questions) in their applied use.
A number of these representations also have a Managed version which allows a single description of a Representation to be reused within and between studies. Some Representations reference reusable structures (Category Schemes, Code Lists, etc.) and are already reusable. Others such as Numeric Representations have a Managed Representation contained in a ManagedRepresentationScheme located in Logical Product. This Scheme contains all forms of Managed Representations and supports the standard Scheme organizational objects that allow for grouping and classification according to Subjects, Keywords, Concept, and Universe
Whether you provide representations inline or manage them within a scheme, they contain the same information. High level descriptions are shown below, detailed explanations are described in the Specific Structures section.
Variables use the representation substitutions found in reusable directly as substitution types for VariableRepresentation with the exception of CodeRepresentation where it allows additional specifications of the use of the CodeScheme contents. Further explanation of this can be found in the Value Representation section.
QuestionItem uses local substitution types for ResponseDomain which use their respective representation types with the addition of an optional Label and Description. Questions that require a mixture of response domain types may do so by using the StructuredMixedResponseDomain as an alternative to ResponseDomain. Further explanation of this can be found in the Response Domain section.
Each representation type described below notes the related ResponseDomain and VariableRepresentation including any details of specialized use.
All representation types provide the following optional content that help to define the classification and use of the representation content. When used as question response domains these may not be relevant, however, depending on the type of response domain the user may wish to define this content.
| RecommendedDataType | This element is a CodeValueType which allows for input of a simple term or reference to an established controlled vocabulary list. Preferably the user should select from the W3C XML Schema Part 2 list of data types with the exception of sub-string types QNAME and NOTATION. See: http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#built-in-datatypes |
| GenericOutputFormat | This element is a CodeValueType which allows for input of a simple term or reference to an established controlled vocabulary list. This element provides specification for the preferred output format expressed in a generic way. |
| @missingValue | Provides a listing as a space delimited array of values that should be treated as missing values. |
| @blankIsMissingValue | A Boolean attribute that when set to ‘true’, indicates that a blank (no content) should be treated as a missing value. |
| @classificationLevel | Indicates the classification of the content as: Nominal, Ordinal, Interval, Ratio, or Continuous |
Representation (inline)¶
Figure 4. Overview of Representation (inline)
Available Inline Representation members¶
| Variable Representation | Question Representation |
|---|---|
| TextRepresentation | TextDomainType |
| DateTimeRepresentation | DateTimeDomainType |
| NumericRepresentation | NumericDomainType |
| ExternalCategoryRepresentation | ExternalCategoryDomainType |
| CodeRepresentation | CodeDomainType |
| ScaleRepresentation | ScaleDomainType |
| GeographicLocationCodeRepresenation | GeographicLocationCodeRepresenation |
| GeographicStructureCodeRepresentation | GeographicStructureCodeDomainType |
| CategoryDomainType | |
| GeographicDomainType | |
| NominalDomainType | |
| LocationDomainType | |
| RankingDomainType | |
| DistributionDomainType |
Comparison of Inline Value Representation and Response Domains¶
| Variable representation | Question representation |
|---|---|
| TextRepresentation | TextDomain |
RecommendedDataType GenericOutputFormat @missingValues @blankIsMissingValue @classificationLevel @maxLength @minLength @regExp |
RecommendedDataType GenericOutputFormat @missingValues @blankIsMissingValue @classificationLevel @maxLength @minLength @regExp Label Description OutParameter ResponseCardinality ContentDateOffset |
| CodeRepresentation | CodeDomain |
RecommendedDataType GenericOutputFormat @missingValues @blankIsMissingValue @classificationLevel CodeListReference CodeSubsetInformation |
RecommendedDataType GenericOutputFormat @missingValues @blankIsMissingValue @classificationLevel CodeListReference CodeSubsetInformation Label Description OutParameter ResponseCardinality ContentDateOffset |
Representation (by Reference)¶
Figure 5. Overview of Representation (by reference)
Available Managed Representation members¶
| Variable Representation | Question Representation |
|---|---|
| TextRepresentationReference | TextDomainReference |
| DateTimeRepresentationReference | DateTimeDomainReference |
| NumericRepresentationReference | NumericDomainReference |
| ScaleRepresentationReference | ScaleDomainReference |
| MissingValuesDomainReference |
Comparison of Managed Value Representation and Response Domains¶
In / Out Parameter, Binding and Command Code¶
The set of classes, InParameter, OutParameter, Binding and CommandCode allow for specific tracking of a set of information (data) through processing.
For example the response captured by a question is expressed as the OutParameter of the Question.
A GenerationInstruction specifies that it has an InParameter which goes through a mathematical process resulting in an OutParameter content. A variable has an InParameter.
Binding is used to link the OutParameter of the Question to the InParamter of the GenerationInstruction.
The InParameter of the GenerationInstruction to a specific usage in a Command Code and the OutParameter of the GenerationInstruction to the InParamter of a Variable.
Example¶
<g:ResourcePackage xmlns:ddi="ddi:instance:3_2" xmlns:a="ddi:archive:3_2" xmlns:c="ddi:conceptualcomponent:3_2" xmlns:cm="ddi:comparative:3_2" xmlns:d="ddi:datacollection:3_2" xmlns:g="ddi:group:3_2" xmlns:l="ddi:logicalproduct:3_2"
xmlns:p="ddi:physicaldataproduct:3_2" xmlns:pi="ddi:physicalinstance:3_2" xmlns:pr="ddi:ddiprofile:3_2" xmlns:r="ddi:reusable:3_2" xmlns:s="ddi:studyunit:3_2" xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="ddi:instance:3_2 http://www.ddialliance.org/Specification/DDI-Lifecycle/3.2/XMLSchema/instance.xsd">
<r:URN>urn:ddi:us.mpc:ParamerterBindingRP:1</r:URN>
<d:ControlConstructScheme scopeOfUniqueness="Agency" isMaintainable="true">
<r:URN>urn:ddi:us.mpc:CCScheme:1</r:URN>
<d:Sequence isVersionable="true" scopeOfUniqueness="Agency">
<r:URN>urn:ddi:us.mpc:SEQ:1</r:URN>
<r:Binding>
<r:SourceParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:QC_OUT_1:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:SourceParameterReference>
<r:TargetParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:QC_IN_2:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:TargetParameterReference>
</r:Binding>
<d:ControlConstructReference isReference="true">
<r:URN>urn:ddi:us.mpc:QC_1:1</r:URN>
<r:TypeOfObject>QuestionConstruct</r:TypeOfObject>
</d:ControlConstructReference>
<d:ControlConstructReference isReference="true">
<r:URN>urn:ddi:us.mpc:QC_2:1</r:URN>
<r:TypeOfObject>QuestionConstruct</r:TypeOfObject>
</d:ControlConstructReference>
</d:Sequence>
<d:QuestionConstruct isVersionable="true" scopeOfUniqueness="Agency">
<r:URN>urn:ddi:us.mpc:QC_1:1</r:URN>
<r:OutParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:QC_OUT_1:1</r:URN>
</r:OutParameter>
<r:Binding>
<r:SourceParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:Q1_Name:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:SourceParameterReference>
<r:TargetParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:QC_OUT_1:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:TargetParameterReference>
</r:Binding>
<r:QuestionReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:Q1:1</r:URN>
<r:TypeOfObject>QuestionItem</r:TypeOfObject>
</r:QuestionReference>
</d:QuestionConstruct>
<d:QuestionConstruct isVersionable="true" scopeOfUniqueness="Agency">
<r:URN>urn:ddi:us.mpc:QC_2:1</r:URN>
<r:InParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:QC_IN_2:1 </r:URN>
</r:InParameter>
<r:OutParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:QC_OUT_2:1</r:URN>
</r:OutParameter>
<r:Binding>
<r:SourceParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:QC_IN_2:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:SourceParameterReference>
<r:TargetParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:Q2_Name:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:TargetParameterReference>
</r:Binding>
<r:Binding>
<r:SourceParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:Q2_Age:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:SourceParameterReference>
<r:TargetParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:QC_OUT_2:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:TargetParameterReference>
</r:Binding>
<r:QuestionReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:Q2:1</r:URN>
<r:TypeOfObject>QuestionItem</r:TypeOfObject>
</r:QuestionReference>
</d:QuestionConstruct>
</d:ControlConstructScheme>
<d:QuestionScheme scopeOfUniqueness="Agency" isMaintainable="true">
<r:URN>urn:ddi:us.mpc:QScheme:1</r:URN>
<d:QuestionItem isVersionable="true" scopeOfUniqueness="Agency">
<r:URN>urn:ddi:us.mpc:Q1:1</r:URN>
<r:OutParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:Q1_Name:1</r:URN>
</r:OutParameter>
<r:Binding>
<r:SourceParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:RD_Name:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:SourceParameterReference>
<r:TargetParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:Q1_Name:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:TargetParameterReference>
</r:Binding>
<d:QuestionText>
<d:LiteralText>
<d:Text xml:lang="en" xml:space="default">What is the name of your oldest child? </d:Text>
</d:LiteralText>
</d:QuestionText>
<d:TextDomainReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:TD_1:1</r:URN>
<r:TypeOfObject>ManagedTextRepresentation</r:TypeOfObject>
<r:OutParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:RD_Name:1</r:URN>
</r:OutParameter>
</d:TextDomainReference>
</d:QuestionItem>
<d:QuestionItem isVersionable="true" scopeOfUniqueness="Agency">
<r:URN>urn:ddi:us.mpc:Q2:1</r:URN>
<r:InParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:Q2_Name:1</r:URN>
</r:InParameter>
<r:OutParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:Q2_Age:1</r:URN>
</r:OutParameter>
<r:Binding>
<r:SourceParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:RD_Age:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:SourceParameterReference>
<r:TargetParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:Q2_Age:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:TargetParameterReference>
</r:Binding>
<d:QuestionText>
<d:LiteralText>
<d:Text xml:lang="en" xml:space="preserve">How old is</d:Text>
</d:LiteralText>
<d:ConditionalText>
<r:SourceParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:Q2_Name:1</r:URN>
<r:TypeOfObject>InParameter</r:TypeOfObject>
</r:SourceParameterReference>
</d:ConditionalText>
<d:LiteralText>
<d:Text xml:lang="en" xml:space="preserve"> ? </d:Text>
</d:LiteralText>
</d:QuestionText>
<d:NumericDomainReference>
<r:URN>urn:ddi:us.mpc:ND_1:1</r:URN>
<r:TypeOfObject>ManagedNumericRepresentation</r:TypeOfObject>
<r:OutParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:RD_Age:1</r:URN>
</r:OutParameter>
</d:NumericDomainReference>
</d:QuestionItem>
</d:QuestionScheme>
<l:VariableScheme scopeOfUniqueness="Agency" isMaintainable="true">
<r:URN>urn:ddi:us.mpc:VarScheme:1</r:URN>
<l:Variable isVersionable="true" scopeOfUniqueness="Agency">
<r:URN>urn:ddi:us.mpc:V1:1</r:URN>
<l:VariableName>
<r:String xml:lang="en">Age 5 year cohorts</r:String>
</l:VariableName>
<r:SourceParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:GI_Age_Cohort:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:SourceParameterReference>
</l:Variable>
</l:VariableScheme>
<d:ProcessingInstructionScheme scopeOfUniqueness="Agency" isMaintainable="true">
<r:URN>urn:ddi:us.mpc:ProcInstScheme:1</r:URN>
<d:GenerationInstruction isVersionable="true" scopeOfUniqueness="Agency">
<r:URN>urn:ddi:us.mpc:GI:1</r:URN>
<r:CommandCode>
<r:Command>
<r:ProgramLanguage>SPSS</r:ProgramLanguage>
<r:InParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:GI_Age:1 </r:URN>
<r:Alias>AGE </r:Alias>
</r:InParameter>
<r:OutParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:GI_Age_Cohort:1</r:URN>
<r:Alias>AGE_5</r:Alias>
</r:OutParameter>
<r:Binding>
<r:SourceParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:QC_OUT_2:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:SourceParameterReference>
<r:TargetParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:GI_Age:1</r:URN>
<r:TypeOfObject>InParameter</r:TypeOfObject>
</r:TargetParameterReference>
</r:Binding>
<r:CommandContent>If (AGE &lt; 5) AGE_5=1; If (AGE &gt;=5) & (AGE &lt; 10) AGE_5=2; If (AGE &gt;=10 & (AGE &lt; 15) AGE_5=3; If (AGE &gt;=15 & (AGE &lt; 20) AGE_5=4; If (AGE &gt;=20 AGE_5=5</r:CommandContent>
</r:Command>
</r:CommandCode>
</d:GenerationInstruction>
</d:ProcessingInstructionScheme>
</g:ResourcePackage>
Specific Structures¶
Archive¶
A maintainable module containing information related to the archiving (longer term access and/or preservation) of the data and metadata. Note that in DDI Archive refers to a set of processes rather than a location. Archive contents are split into archive specific information (information that is related to the organization or individual performing archival activities) and information that reflects the processes that the metadata or data have undergone which should be maintained along with other content if the metadata changes locations. Two key pieces of information held within the Archive are the Organization Scheme (containing records of Organizations, Individuals, and the Relationships between them) and the Lifecycle. The Lifecycle can be used to document any significant event in the life of the data and metadata. It is a series of Lifecycle Events which note the date of the event, what took place, and who was involved.
------------------------------------------------------------
Namespace: a (abstract)
Parent Maintainable: ArchiveScheme
Type: Maintainable
------------------------------------------------------------
Archive
Extension base: Maintainable
ArchiveModuleName (0..n)
r:Label (0..n)
r:Description (0..1)
ArchiveSpecific (0..n)
CHOICE (0..n)
OrganizationScheme
r:OrganizationSchemeReference
END CHOICE
r:LifecycleInformation (0..1)
r:OtherMaterial (0..n)
Example¶
<a:Archive xmlns:ddi="ddi:instance:3_2" xmlns:a="ddi:archive:3_2" xmlns:c="ddi:conceptualcomponent:3_2" xmlns:cm="ddi:comparative:3_2" xmlns:d="ddi:datacollection:3_2" xmlns:g="ddi:group:3_2" xmlns:l="ddi:logicalproduct:3_2" xmlns:p="ddi:physicaldataproduct:3_2" xmlns:pi="ddi:physicalinstance:3_2" xmlns:pr="ddi:ddiprofile:3_2" xmlns:r="ddi:reusable:3_2" xmlns:s="ddi:studyunit:3_2" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:xhtml="http://www.w3.org/1999/xhtml" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="ddi:instance:3_2 http://www.ddialliance.org/Specification/DDI-Lifecycle/3.2/XMLSchema/instance.xsd" isMaintainable="true" scopeOfUniqueness="Agency">
<r:URN typeOfIdentifier="Canonical">urn:ddi:us.mpc:Arch_1:1</r:URN>
<a:ArchiveModuleName context="IPEDS"><r:String xml:lang="en-US">MPC_NHGIS_HIST1900</r:String></a:ArchiveModuleName>
<r:Label><r:Content xml:lang="en-US">MPC NHGIS Archive Record for HIST1900</r:Content></r:Label>
<r:Description><r:Content xml:lang="en-US">Information specific to the HIST1900 data files and documentation in the NHGIS project</r:Content></r:Description>
<a:ArchiveSpecific>
<a:ArchiveOrganizationReference isReference="true" isExternal="true" lateBound="false">
<r:URN>urn:ddi:us.mpc:OrgS_MPCwide:1.0</r:URN>
<r:TypeOfObject>OrganizationScheme</r:TypeOfObject>
</a:ArchiveOrganizationReference>
<a:Collection>
<r:Citation>
<r:Title><r:String>NHGIS Historical 1900</r:String></r:Title>
</r:Citation>
<a:ItemQuantity>2</a:ItemQuantity>
<a:AvailabilityStatus><r:Content>On-Line</r:Content></a:AvailabilityStatus>
<a:DataFileQuantity>4</a:DataFileQuantity>
<a:CollectionCompleteness><r:Content>Original data dictionary, DDI documentation, US level data file, State level data file, and County level data file.</r:Content></a:CollectionCompleteness>
<a:Item>
<r:Citation>
<r:Title><r:String>us1990cnty</r:String></r:Title>
</r:Citation>
<a:LocationInArchive><r:String>aggdata/Translation/HIST/us1990cnty.sps</r:String></a:LocationInArchive>
<a:ItemFormat>ASCII text</a:ItemFormat>
<a:AvailabilityStatus><r:Content>archive</r:Content></a:AvailabilityStatus>
<a:DataFileQuantity>1</a:DataFileQuantity>
<a:CollectionCompleteness><r:Content>SPSS setup file and related data file.</r:Content></a:CollectionCompleteness>
</a:Item>
<a:Item>
<r:Citation>
<r:Title><r:String>Census of Population for National, State, and County Levels - 1900: NHGIS documentation</r:String></r:Title>
</r:Citation>
<a:LocationInArchive><r:String>NHGIS/metadata/DDI/HIST1900-cnty.xml</r:String></a:LocationInArchive>
<a:ItemFormat>xml</a:ItemFormat>
<a:AvailabilityStatus><r:Content>NHGISsubversion</r:Content></a:AvailabilityStatus>
<a:DataFileQuantity>3</a:DataFileQuantity>
<a:CollectionCompleteness><r:Content>DDI documentation, US level data file, State level data file, and County level data file.</r:Content></a:CollectionCompleteness>
</a:Item>
</a:Collection>
<a:DefaultAccess isIdentifiable="true" scopeOfUniqueness="Agency">
<r:URN>urn:ddi:us.mpc:NHGIS_ACCESS_1:1</r:URN>
<a:AccessTypeName context="IPEDS"><r:String xml:lang="en-US">MPC_NHGIS_ACCESS</r:String></a:AccessTypeName>
<r:Label><r:Content xml:lang="en-US">NHGIS Access Requirements</r:Content></r:Label>
<r:Description><r:Content xml:lang="en-US">Describes access and usage requirements for NHGIS</r:Content></r:Description>
<a:ConfidentialityStatement><r:Content xml:lang="en-US">NHGIS contains public data obtained through the U.S. Census Bureau.</r:Content></a:ConfidentialityStatement>
<a:AccessPermission isRequired="true">
<r:URI>https://data2.nhgis.org/users/login</r:URI>
</a:AccessPermission>
<a:Restrictions><r:Content xml:lang="en-US">The National Historical Geographic Information System (NHGIS) provides, free of charge, aggregate census data and GIS-compatible boundary files for the United States between 1790 and 2010.</r:Content></a:Restrictions>
<a:CitationRequirement><r:Content xml:lang="en-US"><xhtml:div>All persons are granted a limited license to use this documentation and the accompanying data, subject to the following condition:<xhtml:ul><xhtml:li>Publications and research reports based on the database must cite it appropriately. The citation should include the following: Minnesota Population Center. National Historical Geographic Information System: Version 2.0. Minneapolis, MN: University of Minnesota 2011.</xhtml:li><xhtml:li>If possible, citations should also include the URL for the NHGIS site: http://www.nhgis.org</xhtml:li></xhtml:ul><xhtml:br/>In addition, we request that users send us a copy of any publications, research reports, or educational material making use of the data or documentation. Printed material should be sent to:<xhtml:br/>NHGIS<xhtml:br/> Minnesota Population Center<xhtml:br/> University of Minnesota<xhtml:br/>50 Willey Hall<xhtml:br/>225 19th Ave S<xhtml:br/>Minneapolis, MN 55455</xhtml:div></r:Content></a:CitationRequirement>
<a:AccessConditions><r:Content xml:lang="en-US">Preregistration</r:Content></a:AccessConditions>
<a:AccessRestrictionDate><r:StartDate>2001-05-01</r:StartDate></a:AccessRestrictionDate>
<a:ContactOrganizationReference isReference="true" isExternal="true" lateBound="false">
<r:URN>urn:ddi:us.mpc:OrgS_MPCwide:1.0</r:URN>
<r:TypeOfObject>OrganizationScheme</r:TypeOfObject>
</a:ContactOrganizationReference>
</a:DefaultAccess>
</a:ArchiveSpecific>
<r:OrganizationSchemeReference isReference="true" isExternal="true" lateBound="false">
<r:URN>urn:ddi:us.mpc:OrgS_MPCwide:1.0</r:URN>
<r:TypeOfObject>OrganizationScheme</r:TypeOfObject>
</r:OrganizationSchemeReference>
<r:LifecycleInformation>
<r:LifecycleEvent isIdentifiable="true" scopeOfUniqueness="Agency">
<r:URN>urn:ddi:us.mpc:NHGIS_Event_1:1</r:URN>
<r:Label><r:Content xml:lang="en-US">HIST1900-cnty aquisition</r:Content></r:Label>
<r:EventType>Aquisition</r:EventType>
<r:Date><r:SimpleDate>2001-03-10</r:SimpleDate></r:Date>
<r:AgencyOrganizationReference isReference="true" isExternal="true" lateBound="false">
<r:URN>urn:ddi:us.mpc:OrgS_MPC_NHGIS:1.0</r:URN>
<r:TypeOfObject>Organization</r:TypeOfObject>
</r:AgencyOrganizationReference>
<r:Description><r:Content xml:lang="en-US">The 1900 History file was aquired as part of a collection of 1900-1950 data entered from printed documents through NGHIS subcontract.</r:Content></r:Description>
<r:Relationship>
<r:RelatedToReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:NHGIS_HIST1900-cnty:1</r:URN>
<r:TypeOfObject>StudyUnit</r:TypeOfObject>
</r:RelatedToReference>
<r:RelationshipDescription><r:Content xml:lang="en">DDI Documentation</r:Content></r:RelationshipDescription>
</r:Relationship>
</r:LifecycleEvent>
<r:LifecycleEvent isIdentifiable="true" scopeOfUniqueness="Agency">
<r:URN>urn:ddi:us.mpc:NHGIS_Event_2:1</r:URN>
<r:Label><r:Content xml:lang="en-US">HIST1900-cnty creation of DDI metadata document</r:Content></r:Label>
<r:EventType>DDICreation</r:EventType>
<r:Date><r:SimpleDate>2001-04-01</r:SimpleDate></r:Date>
<r:AgencyOrganizationReference isReference="true" isExternal="true" lateBound="false">
<r:URN>urn:ddi:us.mpc:OrgS_MPC_NHGIS:1.0</r:URN>
<r:TypeOfObject>Organization</r:TypeOfObject>
</r:AgencyOrganizationReference>
<r:Description><r:Content xml:lang="en-US">Data dictionary information plus additional content from original print documents and materials regarding the 1990 U.S. Census in IPUMS were complied in DDI and verified.</r:Content></r:Description>
<r:Relationship>
<r:RelatedToReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:NHGIS_HIST1900-cnty:1</r:URN>
<r:TypeOfObject>StudyUnit</r:TypeOfObject>
</r:RelatedToReference>
<r:RelationshipDescription><r:Content xml:lang="en">DDI Documentation</r:Content></r:RelationshipDescription>
</r:Relationship>
<r:Relationship>
<r:RelatedToReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:NHGIS_OtherMat_1:1</r:URN>
<r:TypeOfObject>OtherMaterial</r:TypeOfObject>
</r:RelatedToReference>
<r:RelationshipDescription><r:Content xml:lang="en">Data Source</r:Content></r:RelationshipDescription>
</r:Relationship>
</r:LifecycleEvent>
<r:LifecycleEvent isIdentifiable="true" scopeOfUniqueness="Agency">
<r:URN>urn:ddi:us.mpc:NHGIS_Event_3:1</r:URN>
<r:Label><r:Content xml:lang="en-US">HIST1900-cnty integration into 2001 NHGIS release</r:Content></r:Label>
<r:EventType>NHGISIntegration</r:EventType>
<r:Date><r:SimpleDate>2001-05-01</r:SimpleDate></r:Date>
<r:AgencyOrganizationReference isReference="true" isExternal="true" lateBound="false">
<r:URN>urn:ddi:us.mpc:OrgS_MPC_NHGIS:1.0</r:URN>
<r:TypeOfObject>Organization</r:TypeOfObject>
</r:AgencyOrganizationReference>
<r:Description><r:Content xml:lang="en-US">The HIST1990-cnty metadata and data files were successfully integrated into the NHGIS system for the May 2001 release.</r:Content></r:Description>
<r:Relationship>
<r:RelatedToReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:NHGIS_HIST1900-cnty:1</r:URN>
<r:TypeOfObject>StudyUnit</r:TypeOfObject>
</r:RelatedToReference>
<r:RelationshipDescription><r:Content xml:lang="en">DDI Documentation</r:Content></r:RelationshipDescription>
</r:Relationship>
</r:LifecycleEvent>
</r:LifecycleInformation>
<r:OtherMaterial isIdentifiable="true" scopeOfUniqueness="Agency" xml:lang="en">
<r:URN>urn:ddi:us.mpc:NHGIS_OtherMat_1:1</r:URN>
<r:TypeOfMaterial>Print.Book</r:TypeOfMaterial>
<r:Description><r:Content xml:lang="en-US">Data source</r:Content></r:Description>
<r:Citation>
<r:Title><r:String>Twelfth Census of the United States Taken in the Year 1990, Census Reports Volume I - Population Part I</r:String></r:Title>
<r:Creator>
<r:CreatorName affiliation="Interior Department"><r:String>United States Census Office</r:String></r:CreatorName>
</r:Creator>
<r:Publisher>
<r:PublisherName><r:String>Washington: United States Census Office</r:String></r:PublisherName>
</r:Publisher>
<r:PublicationDate>
<r:SimpleDate>1901</r:SimpleDate>
</r:PublicationDate>
</r:Citation>
</r:OtherMaterial>
</a:Archive>
Binding¶
A structure used to bind the content of a parameter declared as the source to a parameter declared as the target. For isntance, linking an InParameter to an OutParameter, binding a question to a variable.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: varies by usage
Type: BindingType
------------------------------------------------------------
Example¶
The use of Binding in a more complex example is shown in :ref: inout
<r:Binding>
<r:SourceParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:QC_OUT_2:1</r:URN>
<r:TypeOfObject>OutParameter</r:TypeOfObject>
</r:SourceParameterReference>
<r:TargetParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:GI_Age:1</r:URN>
<r:TypeOfObject>InParameter</r:TypeOfObject>
</r:TargetParameterReference>
</r:Binding>
Budget¶
A description of the budget that can contain a reference to an external budget document.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: ArchiveSpecific
Type: BudgetType
------------------------------------------------------------
Budget
Extension base: None
Description (0..1)
BudgetDocument (0..n)
Category¶
A description of a particular category or response.
------------------------------------------------------------
Namespace: l (logicalproduct)
Parent Maintainable: CategoryScheme
Type: CategoryType
------------------------------------------------------------
Category
Extension base: Versionable
@isMissing
CategoryName (0..n)
r:Label (0..n)
r:Description (0..1)
r:ConceptReference (0..1)
Generation (0..1)
SubCategoryReference (0..n)
Example¶
<l:Category>
<r:URN>urn:ddi:uk.cls.mcs:mcs5_sc-ca-000102:1.0.0</r:URN>
<l:CategoryName>
<r:String xml:lang="en-GB">102</r:String>
</l:CategoryName>
<r:Label>
<r:Content xml:lang="en-GB">I wish my family could afford to buy me
more of what I want</r:Content>
</r:Label>
</l:Category>
Citation¶
Provides a bibliographic citation using a DDI structure that maps to Dublin Core objects. No object is required in order to support production processes. It is strongly recommended that at minimum a Title be provided. A full set of Qualified Dublin Core descriptor may be provided following the DDI Citation elements. Dublin Core elements should supplement rather than substitute for the DDI Citation elements.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: varies by usage
Type: CitationType
------------------------------------------------------------
Citation
Extension base: Versionable
Title (0..1)
SubTitle (0..n)
AlternateTitle (0..n)
Creator (0..n)
Publisher (0..n)
Contributor (0..n)
PublicationDate (0..1)
Language (0..n)
InternationalIdentifier (0..n)
Copyright (0..n)
dc:any (0..n)
Example¶
<r:Citation>
<r:Title>Twelfth Census of the United States Taken in the Year 1990, Census Reports Volume I - Population Part I</r:Title>
<r:Creator>
<r:CreatorName affiliation="Interior Department">United States Census Office</r:CreatorName>
</r:Creator>
<r:Publisher>
<r:PublisherName>Washington: United States Census Office</r:PublisherName>
</r:Publisher>
<r:PublicationDate>
<r:SimpleDate>1901</r:SimpleDate>
</r:PublicationDate>
</r:Citation>
Code List¶
A structure used to associate a list of code values to specified categories. May be flat or hierarchical.
------------------------------------------------------------
CodeList
Namespace: l (logicalproduct)
Parent Maintainable: CodeListScheme
Type: CodeListType
------------------------------------------------------------
Code
Extension base: Maintainable
CodeListName (0..n)
r:Label (0..n)
r:Description (0..1)
r:RecommendedDataType (0..1)
r:CodeListReference (0..n)
r:CategorySchemeReference (0..1)
HierarchyType (0..1)
Level (0..n)
Code (0..n)
Example¶
<l:CodeList>
<r:URN>urn:ddi:uk.cls.mcs:mcs5_sc-cl-000035:1.0.0</r:URN>
<r:Label>
<r:Content xml:lang="en-GB">cs_q22_Y</r:Content>
</r:Label>
<l:Code>
<r:URN>urn:ddi:uk.cls.mcs:mcs5_sc-co-000160:1.0.0</r:URN>
<r:CategoryReference>
<r:URN>urn:ddi:uk.cls.mcs:mcs5_sc-ca-000102:1.0.0</r:URN>
<r:TypeOfObject>Category</r:TypeOfObject>
</r:CategoryReference>
<r:Value>1</r:Value>
</l:Code>
<l:Code>
<r:URN>urn:ddi:uk.cls.mcs:mcs5_sc-co-000161:1.0.0</r:URN>
<r:CategoryReference>
<r:URN>urn:ddi:uk.cls.mcs:mcs5_sc-ca-000103:1.0.0</r:URN>
<r:TypeOfObject>Category</r:TypeOfObject>
</r:CategoryReference>
<r:Value>2</r:Value>
</l:Code>
<l:Code>
<r:URN>urn:ddi:uk.cls.mcs:mcs5_sc-co-000162:1.0.0</r:URN>
<r:CategoryReference>
<r:URN>urn:ddi:uk.cls.mcs:mcs5_sc-ca-000104:1.0.0</r:URN>
<r:TypeOfObject>Category</r:TypeOfObject>
</r:CategoryReference>
<r:Value>3</r:Value>
</l:Code>
</l:CodeList>
Code Value¶
Allows for string content which may be taken from an externally maintained controlled vocabulary (code value). If the content is from a controlled vocabulary provide the code value, as well as a reference to the code list from which the value is taken. Provide as many of the identifying attributes as needed to adequately identify the controlled vocabulary. Note that DDI has published a number of controlled vocabularies applicable to several locations using the CodeValue structure. Use of shared controlled vocabularies helps support interoperability and machine actionability.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: Not applicable
Type:CodeValueType
------------------------------------------------------------
CodeValueType
Extension base: None
@codelistID (optional)
@codelistName (optional)
@codeListAgencyName (optional)
@codeListVersionID (optional)
@otherValue (optional)
@codeListURN (optional)
@codeListSchemeURN (optional)
Example¶
Collection Event¶
Information on a specific data collection event
------------------------------------------------------------
Namespace: d (datacollection)
Parent Maintainable: DataCollection
Type: DataCollectionType
------------------------------------------------------------
CollectionEvent
Extension base: Identifiable
DataCollectorOrganizationReference (0..n)
DataSource (0..n)
DataCollectionDate (0..1)
DataCollectionFrequency (0..n)
ModeOfCollection (0..n)
InstrumentReference (0..n)
CollectionSituation (0..n)
ActionToMinimizeLosses (0..n)
r:QualityStatementReference (0..n)
Example¶
<d:CollectionEvent isIdentifiable="true" typeOfIdentifier="Canonical" scopeOfUniqueness="Maintainable">
<r:URN>urn:ddi:us.archive:DataColl_1.CE_1:1</r:URN>
<r:QualityStatementReference isReference="true" isExternal="true" lateBound="false" typeOfIdentifier="Canonical">
<r:URN>urn:ddi:us.archive:QScheme_1.QS_2:1</r:URN>
<r:TypeOfObject>QualityStatement</r:TypeOfObject>
</r:QualityStatementReference>
</d:CollectionEvent>
CommandCode¶
Content of the command itself expressed in the language specified in the parent object.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: varies by usage
Type: CommandTypeCode
------------------------------------------------------------
CommandCode
Extension base: None
Description (0..1)
Command (0..n)
CommandFile (0..n)
StructuredCommand (0..1)
Example¶
The use of CommandCode within a more complex example is shown in :ref: inout
<r:CommandCode>
<r:Command>
<r:ProgramLanguage>SPSS </r:ProgramLanguage>
<r:InParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:GI_Age:1 </r:URN>
<r:Alias>AGE </r:Alias>
</r:InParameter>
<r:OutParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:GI_Age_Cohort:1 </r:URN>
<r:Alias>AGE_5 </r:Alias>
</r:OutParameter>
<r:Binding>
<r:SourceParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:QC_OUT_2:1 </r:URN>
<r:TypeOfObject>OutParameter </r:TypeOfObject>
</r:SourceParameterReference>
<r:TargetParameterReference isReference="true" isExternal="false" lateBound="false">
<r:URN>urn:ddi:us.mpc:GI_Age:1 </r:URN>
<r:TypeOfObject>InParameter </r:TypeOfObject>
</r:TargetParameterReference>
</r:Binding>
<r:CommandContent>If (AGE &lt; 5) AGE_5=1; If (AGE &gt;=5) & (AGE &lt; 10) AGE_5=2; If (AGE &gt;=10 & (AGE &lt; 15) AGE_5=3; If (AGE &gt;=15 & (AGE &lt; 20) AGE_5=4; If (AGE &gt;=20 AGE_5=5 </r:CommandContent>
</r:Command>
<r:CommandCode>
Comparison¶
A maintainable module containing maps between objects of the same or similar type. Maps allow for pair-wise mapping of two objects by describing their similarities and differences in order to make assertions regarding their comparability. Currently maps allow for the comparison of concepts, variables, questions, categories, universes, and representations that have managed content (code, category, numeric, text, datetime and scale).
------------------------------------------------------------
Namespace: c (Comparative)
Parent Maintainable: StudyUnit, Group, or ResourcePackage
Type: ComparisonType
------------------------------------------------------------
Comparison
Extension base: Maintainable
ComparisonName (0..n)
r:Label (0..n)
r:Description (0..1)
CHOICE (0..n)
ConceptMap
ConceptMapReference
END CHOICE
CHOICE
VariableMap
VariableMapReference
END CHOICE
CHOICE (0..n)
QuestionMap
QuestionMapReference
END CHOICE
CHOICE (0..n)
CategoryMap
CategoryMapReference
END CHOICE
CHOICE (0..n)
RepresentationMap
RepresentationMapReference
END CHOICE
CHOICE (0..n)
UniverseMap
UniverseMapReference
END CHOICE
Example¶
Concept¶
The element Concept is designed to hold a concept than can be represented independently of any particular representation as per the definition is ISO/IEC 11179. A concept may be organized into hierarchical sub-concepts and provides a structure for comparison (using SimilarConcept) to disambiguate concepts.
------------------------------------------------------------
Namespace: cc (ConceptualComponent)
Parent Maintainable: ConceptScheme
Type: ConceptType
------------------------------------------------------------
Concept
Extension base: Identifiable
ConceptName (0..n)
r:Label (0..n)
r:Description (0..1)
SimilarConcept (0..n)
SubclassOfReference (0..n)
Example¶
ConceptualComponent¶
A maintainable module for the conceptual components of the study or group of studies. Conceptual components include the objects used to describe the concepts the study is examining, the universe (population) and sub-universes those concepts to which they are related, and the geographic structures and locations wherein those populations reside. Concepts, and ConceptualVariables (containing a concept linked to a universe) provide an abstract view of what is being measured by questions or other forms of data capture, and the variables which are used to describe the data that will be collected. Universe describes the populations (objects) about whom information is sought. GeographicStructure and GeographicLocation specify the geographical locations of those objects and the structural relationships between locations of different types, e.g. the relationship of a city to the state that contains it. In addition to the standard name, label, and description, ConceptualComponent contains ConceptSchemes, ConceptualVariableSchemes, UniverseSchemes, GeographicStructureSchemes, and GeographicLocationSchemes both in-line and by reference.
------------------------------------------------------------
Namespace: cc (ConceptualComponent)
Parent Maintainable: varies by usage
Type: ConceptualComponentType
------------------------------------------------------------
ConceptualComponent
Extension base: Maintainable
ConceptualComponentModuleName (0..n)
r:Label (0..n)
r:Description (0..1)
r:Coverage (0..1)
r:OtherMaterial (0..n)
CHOICE (0..n)
ConceptScheme
r:ConceptSchemeReference
END CHOICE
CHOICE (0..n)
UniverseScheme
r:UniverseSchemeReference
END CHOICE
CHOICE (0..n)
ConceptualVariableScheme
r:ConceptualVariableSchemeReference
END CHOICE
CHOICE (0..n)
GeographicStructureScheme
r:GeographicStructureSchemeReference
END CHOICE
CHOICE (0..n)
GeographicLocationScheme
r:GeographicLocationSchemeReference
END CHOICE
Example¶
ConceptualVariable¶
Describes a ConceptualVariable which provides the link between a concept and a specific universe (object) that defines this as a ConceptualVariable. In addition to the standard name, label, and description, it provides the two primary components of a ConceptualVariable by referencing a concept and its related universe. Note that the concept referenced may itself contain sub-concepts and/or references to similar concepts.
------------------------------------------------------------
Namespace: cc (ConceptualComponent)
Parent Maintainable: ConceptualVariableScheme
Type: ConceptualVariableType
------------------------------------------------------------
ConceptualVariable
Extension base: Versionable
ConceptualVariableName (0..n)
r:Label (0..n)
r:Description (0..1)
r:ConceptReference (0..1)
r:UniverseReference (0..1)
Example¶
ControlConstruct¶
Provides the basic, extensible structure for control elements used in describing flow logic within the instrument. Control constructs are the elements that make up the flow logic of a data collection instrument. The various types include Sequence, StatementItem, QuestionConstruct, IfThenElse, RepeatUntil, RepeatWhile and Loop. As a scheme, the individual control constructs as well as master sequences can be held separately and used by a variety of instruments such as Blaise, CPSPro, CASES, and paper products. May also be used to describe Generation Instructions
------------------------------------------------------------
Namespace: d (datacollection)
Parent Maintainable: ControlConstructScheme
Type: ControlConstructType
------------------------------------------------------------
ControlConstruct
Extension base: Versionable
ConstructName (0..n)
r:Label (0..n)
r:Description (0..1)
r:InParameter (0..n)
r:OutParameter (0..n)
r:Binding (0..n)
ExternalAid (0..n)
CHOICE (0..n)
ExternalInterviewerInstruction
InterviewerInstructionReference
END CHOICE
Example¶
Coverage¶
Describes the temporal, spatial and topical coverage.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: varies by usage
Type: CoverageType
------------------------------------------------------------
Coverage
@isRestrictionOfParentCoverage
CHOICE (0..1)
TopicalCoverageReference
TopicalCoverage
END CHOICE
CHOICE (0..1)
SpatialCoverageReference
SpatialCoverage
END CHOICE
CHOICE (0..1)
TemporalCoverageReference
TemporalCoverage
END CHOICE
RestrictionProcess (0..1)
Example¶
<r:Coverage>
<r:SpatialCoverage isUniversallyUnique="true">
<r:URN>urn:ddi:uk.iser:e600fee4-a5ad-4c9e-a912-67c5540e4701:10</r:URN>
<r:Country>GB-ENG</r:Country>
<r:Country>GB-WLS</r:Country>
<r:Country>GB-SCT</r:Country>
<r:Country>GB-NIR</r:Country>
<r:TopLevelReference>
<r:LevelName>Country</r:LevelName>
</r:TopLevelReference>
<r:LowestLevelReference>
<r:LevelName>EUL: Government Office Region, Special License: Lower Layer Super Output Areas, Secure Access: National Grid Reference </r:LevelName>
</r:LowestLevelReference>
</r:SpatialCoverage>
<r:TemporalCoverage isUniversallyUnique="true">
<r:URN>urn:ddi:uk.iser:49fb8416-5a84-4b7f-95cf-6dcad96b23a8:10</r:URN>
<r:ReferenceDate>
<r:StartDate>2009-01-08T00:00:00Z</r:StartDate>
<r:EndDate>2011-03-07T00:00:00Z</r:EndDate>
</r:ReferenceDate>
</r:TemporalCoverage>
</r:Coverage>
DataCollection¶
A maintainable module containing information on activities related to data collection/capture and the processing required for the creation a data product. This section covers the methodologies, events, data sources, collection instruments and processes which comprise the collection/capture and processing of data. Methodology covers approaches used for selecting samples, administering surveys, timing repeated data collection activities. Collection Event specifies data sources, collection instruments, questions and question flow, and data processing activities. This module houses Processing Instructions (General Instructions and Generation Instructions) which may be referenced by variables or comparison maps. It houses the following schemes: Question Scheme, Control Construct Scheme (questionnaire flow), Interviewer Instruction Scheme, Instrument Scheme, Processing Event Scheme, and Processing Instruction Scheme.
------------------------------------------------------------
Namespace: d (DataCollection)
Parent Maintainable: varies according to usage
Type: DataCollectionType
------------------------------------------------------------
DataCollection
Extension base: Maintainable
DataCollectionModuleName (0..n)
r:Label (0..n)
r:Description (0..1)
r:Coverage (0..1)
r:OtherMaterial (0..n)
CHOICE (0..1)
Methodology
MethodologyReference
END CHOICE
CollectionEvent (0..n)
CHOICE (0..n)
QuestionScheme
r:QuestionSchemeReference
END CHOICE
CHOICE (0..n)
ControlConstructScheme
r:ControlConstructSchemeReference
END CHOICE
CHOICE (0..n)
InterviewerInstructionScheme
r:InterviewerInstructionSchemeReference
END CHOICE
CHOICE (0..n)
InstrumentScheme
r:InstrumentSchemeReference
END CHOICE
CHOICE (0..n)
ProcessingEventScheme
ProcessingEventSchemeReference
END CHOICE
CHOICE (0..n)
ProcessingInstructionScheme
ProcessingInstructionSchemeReference
END CHOICE
Example
^^^^^^^^
::
- <DataCollection isUniversallyUnique=”true” versionDate=”2016-06-09T10:32:52.7829559Z”>
<r:URN>urn:ddi:uk.iser:56acc464-6368-4405-ac28-0195a21c1f19:6</r:URN> <DataCollectionModuleName>
<r:String xml:lang=”en-GB”>us1_ysc</r:String> </DataCollectionModuleName>
- <r:Label>
- <r:Content xml:lang=”en-GB”>Youth self-completion questionnaire</r:Content>
</r:Label>
- <CollectionEvent isUniversallyUnique=”true”>
<r:URN>urn:ddi:uk.iser:094e05f4-c29b-4c11-ba6c-2e055ea712f0:6</r:URN> <DataCollectorOrganizationReference>
<r:Agency>uk.iser</r:Agency> <r:ID>fdd368a5-7095-4f65-bfb4-27c2833c91dd</r:ID> <r:Version>1</r:Version> <r:TypeOfObject>Organization</r:TypeOfObject></DataCollectorOrganizationReference> <DataCollectorOrganizationReference>
<r:Agency>uk.iser</r:Agency> <r:ID>0735accf-16ec-4381-aa0c-e69d53af51da</r:ID> <r:Version>1</r:Version> <r:TypeOfObject>Organization</r:TypeOfObject></DataCollectorOrganizationReference> <DataCollectionDate>
<r:StartDate>2009-01</r:StartDate> <r:EndDate>2010-12</r:EndDate></DataCollectionDate> <ModeOfCollection isUniversallyUnique=”true”>
<r:URN>urn:ddi:uk.iser:a1679258-18fb-43dd-85b0-e45656910094:6</r:URN> <TypeOfModeOfCollection codeListVersionID=”1.0”>SelfAdministeredQuestionnaire.Paper</TypeOfModeOfCollection> <r:Description>
<r:Content xml:lang=”en-GB”>Self-administered questionnaire using a traditional paper questionnaire.</r:Content></r:Description>
</ModeOfCollection>
</CollectionEvent>
</DataCollection>
<d:DataCollection isMaintainable="true" typeOfIdentifier="Canonical" scopeOfUniqueness="Maintainable">
<r:URN>urn:ddi:us.archive:DataColl_1:1</r:URN> <d:CollectionEvent isIdentifiable=”true” typeOfIdentifier=”Canonical” scopeOfUniqueness=”Maintainable”>
<r:URN>urn:ddi:us.archive:DataColl_1.CE_1:1</r:URN> <r:QualityStatementReference isReference=”true” isExternal=”true” lateBound=”false” typeOfIdentifier=”Canonical”>
<r:URN>urn:ddi:us.archive:QScheme_1.QS_2:1</r:URN> <r:TypeOfObject>QualityStatement</r:TypeOfObject></r:QualityStatementReference>
</d:CollectionEvent>
</d:DataCollection>
Data Relationship¶
Describes the relationships among logical records in the dataset. Date Relationship is needed to create the appropriate link between the logical record and the physical storage description.
------------------------------------------------------------
Namespace: l (logicalproduct)
Parent Maintainable: LogicalProduct
Type: DataRelationshipType
------------------------------------------------------------
DataRelationship
Extension base: Versionable
DataRelationshipName (0..n)
r:Label (0..n)
r:Description (0..1)
LogicalRecord (0..n)
RecordRelationship (0..n)
Example
^^^^^^^^
::
<DataRelationship>
<Agency xmlns="ddi:reusable:3_2">us.atg</Agency>
<ID xmlns="ddi:reusable:3_2">DR_1</ID>
<Version xmlns="ddi:reusable:3_2">1.0</Version>
<LogicalRecord hasLocator="false">
<Agency xmlns="ddi:reusable:3_2">us.atg</Agency>
<ID xmlns="ddi:reusable:3_2">LR_1</ID>
<Version xmlns="ddi:reusable:3_2">1.0</Version>
<VariablesInRecord allVariablesInLogicalProduct="true"/>
</LogicalRecord>
</DataRelationship>
Date¶
A single point in time, a duration, or a time range with start and/or end dates.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: Not applicable
Type: DateType
------------------------------------------------------------
Date
Extension base: None
CHOICE
SimpleDate
HistoricalDate (0..1)
END CHOICE
CHOICE
StartDate
HistoricalStartDate (0..1)
EndDate (0..1)
HistoricalEndDate (0..1)
Cycle (0..1)
END CHOICE
CHOICE
EndDate
HistoricalEndDate (0..1)
END CHOICE
Example (SimpleDate)¶
<r:PublicationDate>
<r:SimpleDate>2013-02-26</r:SimpleDate>
<r:HistoricalDate>
<r:NonISODate>26 February 2013</r:NonISODate>
<r:HistoricalDateFormat>dd Month yyyy</r:HistoricalDateFormat>
<r:Calendar>Gregorian</r:Calendar>
</r:HistoricalDate>
</r:PublicationDate>
Example (Complete Date Range)¶
<d:DataCollectionDate>
<r:StartDate>2010-06-05T20:20:00</r:StartDate>
<r:HistoricalStartDate>
<r:NonISODate>24 Sivan 2770</r:NonISODate>
<r:HistoricalDateFormat>dd Month yyyy</r:HistoricalDateFormat>
<r:Calendar>Jewish</r:Calendar>
</r:HistoricalStartDate>
<r:EndDate>2010-08-05T20:20:00</r:EndDate>
<r:HistoricalEndDate>
<r:NonISODate>28 Sivan 5770</r:NonISODate>
<r:HistoricalDateFormat>dd Month yyyy</r:HistoricalDateFormat>
<r:Calendar>Jewish</r:Calendar>
</r:HistoricalEndDate>
</d:DataCollectionDate>
Example (Range with unknown end date)¶
<r:GeographicTime>
<r:StartDate>2013-02-26</r:StartDate>
<r:HistoricalStartDate>
<r:NonISODate>26 February 2013</r:NonISODate>
<r:HistoricalDateFormat>dd Month yyyy</r:HistoricalDateFormat>
<r:Calendar>Gregorian</r:Calendar>
</r:HistoricalStartDate>
</r:GeographicTime >
Example (Range with unknown start date)¶
<d:ValidPeriod>
<r:EndDate>2013-02-26</r:SimpleDate>
<r:HistoricalEndDate>
<r:NonISODate>February 26, 2013</r:NonISODate>
<r:HistoricalDateFormat>Month dd, yyyy</r:HistoricalDateFormat>
<r:Calendar>Gregorian</r:Calendar>
</r:HistoricalEndDate>
</d:ValidPeriod >
DDI Instance¶
DDIInstance is the top-level publication wrapper for any DDI document. All DDI content published as XML (with the exception of a Fragment intended for transmission) has DDIInstance as its top level structure. In addition to a citation and coverage statement for the instance, the DDIInstance can contain a Group, ResourcePackage, LocalHoldingPackage or StudyUnit.
------------------------------------------------------------
Namespace: I (Instance)
Parent Maintainable: varies by usage
Type: DDIInstanceType
------------------------------------------------------------
DDIInstance
Extension base: Maintainable
r:Citation (0..1)
r:Coverage (0..1)
CHOICE (0..n)
g:Group
r:GroupReference
END CHOICE
CHOICE (0..n)
g:ResourcePackage
r:ResourcePackageReference
END CHOICE
CHOICE (0..n)
g:LocalHoldingPackage
r:LocalHoldingPackageReference
END CHOICE
CHOICE (0..n)
s:StudyUnit
r:StudyUnitReference
END CHOICE
r:OtherMaterial (0..n)
CHOICE (0..n)
pr:DDIProfile
r:DDIProfileReference
END CHOICE
TranslationInformation (0..1)
Example¶
DDI Profile¶
Describes the subset of valid DDI objects used by an agency for a specified purpose. DDI Profile is a simple collection of XPaths that describe the object within DDI that are either used or not use for particular purposes. For example CESSDA can provide a DDI profile denoting which fields it used for its online catalog and can change fields that are ÔoptionalÕ in DDI to ÔrequiredÕ for CESSDA. Objects can be included or excluded as long as the DDI requirements are not violated. Included items can be set to a fixed or default value where appropriate or be provided with an alternate name. This structure facilitates sharing by clearly stating what is expected in the DDI metadata received or sent by an organization and defines what parts of DDI an organization or system can handle. For example software that can handle microdata structures but not NCubes.
------------------------------------------------------------
Namespace: pr (ddiprofile)
Parent Maintainable: varies by usage
Type: DDIProfileType
------------------------------------------------------------
DDIProfile
Extension base: Maintainable
DDIProfileName (0..n)
r:Label (0..n)
r:Description (0..1)
ApplicationOfProfile (0..n)
r:Purpose (0..1)
XPathVersion
DDINamespace (0..1)
XMLPrefixMap (0..n)
Instructions (0..1)
CHOICE (0..n)
Used
NotUsed
END CHOICE
Example¶
Embargo¶
Provides information about data that are not currently available because of policies established by the principal investigators and/or data producers.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: varies by usage
Type: EmbargoType
------------------------------------------------------------
Embargo
Extension base: Identifiable
EmbargoName (0..n)
Label (0..n)
Description (0..1)
Date (0..1)
Rationale (0..1)
AgencyOrganizationReference (0..1)
EnforcementAgencyOrganizationReference (0..n)
Example¶
Ex-Post Evaluation¶
Evaluation for the purpose of reviewing the study, data collection, data processing, or management processes.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: varies by usage
Type: ExPostEvaluationType
------------------------------------------------------------
ExPostEvaluation
Extension base: None
TypeOfEvaluation (0..n)
Evaluator (0..n)
EvaluationProcess (0..n)
Outcomes (0..n)
Example¶
FragmentInstance¶
A Fragment Instance is used to transfer maintainable or versionable objects plus any associated notes and other material in response to a query. TopLevelReference provides a record of the reference(s) (from the query) to which the FragmentInstance is responding. The contents of the maintainable and versionable objects are transported as ddi:Fragment entries.
------------------------------------------------------------
Namespace: i (Instance)
Parent Maintainable: Fragment
Type: FragmentInstanceType
FragmentInstance
Extension base: None
TopLevelReference (0..n)
Fragment (0..n)
Example¶
Funding Information¶
Provides information about the agency and grant(s) which funded the described entity.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: varies by usage
Type: FundingInformationType
------------------------------------------------------------
FundingInformation
Extension base: None
AgencyOrganizationReference (0..n)
FunderRole (0..1)
GrantNumber (0..n)
Description (0..1)
Example¶
<r:FundingInformation>
<r:AgencyOrganizationReference>
<r:Agency>uk.cls.bcs70</r:Agency>
<r:ID>78a563d7-dbe1-4f13-93a9-69844a3bee88</r:ID>
<r:Version>1</r:Version>
<r:TypeOfObject>Organization</r:TypeOfObject>
</r:AgencyOrganizationReference>
<r:GrantNumber>RES-579-47-0001</r:GrantNumber>
</r:FundingInformation>
Geographic Location¶
Describes specific instances of GeographicLocations associated with a specified GeographicLevel in a GeographicStructure.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: varies by usage
Type: GeographicLocationType
------------------------------------------------------------
GeographicLocation
Extension base: Versionable
GeographicLocationName (0..n)
Label (0..n)
Description (0..1)
CHOICE (0..1)
GeographicLevelReference
GeographicLevelDescription
END CHOICE
AuthorizedSource (0..n)
LocationValue (0..n)
Example¶
Group¶
A primary packaging and publication module within DDI containing a Group of StudyUnits. The Group structure allows metadata regarding multiple study units to be published as a structured entity. Studies may be grouped “by design” such as a repeated study with intended areas of commonality between each study, or “ad hoc” where studies are grouped for applied or administrative reasons.
One aspect of DDI Version 3.1 onwards which follows from the support of the whole life cycle is the introduction of groups of studies as the subject for metadata documentation. Longitudinal studies are a good example of this. A longitudinal study is a study that is repeated at specific points in time, and thus represents a group of related studies. These need to be documented as a group in order to clearly document the repurposing of aspects of the initial study and the relationship that exists between each of the component studies in the group.
The ability to document these complex cases or groups is a major advance of DDI 3. The ÔcomplexÕ case involves a series or collection of studies which are related in some way or a group of studies which are being compared. It is important to recognize which cases are ÔcomplexÕ because they use features of the DDI which are potentially more difficult to understand and implement, such as group inheritance and comparison
A Group can be comprised of StudyUnits and SubGroups. A standard set of attributes describes the following dimensions for grouping:
- Time
- Instrument
- Panel
- Geography
- Datasets
- Language
A table providing the specified values and a set of decision trees for determining their value is provided in Appendix 3. Note that in all cases these attributes are providing general information on the relationships between the StudyUnits and SubGroups which comprise the Group (or SubGroup) that are intended to assist the programmer in anticipating the types of comparison or repletion patterns they will need to address. For example, if an individual StudyUnit within a group has content in three languages (labels provided in English, German, and French) this does not make Language a grouping factor. The Language attribute would be set to ÔL0Õ ÔNot a reason for grouping. If the Group consisted of two StudyUnits say the English version of a Health Canada Survey and the French version of that survey, the Language attribute would be L2.
All original languages with full language equivalence as Health Canada considers both versions to be original and each contains the equivalent intellectual content.
In interpreting the descriptions please note that the term rolling for panel or geography means that panel waves or geographic waves were used. For example there are four panels of respondents each starting at a different point in time and having their own repetition cycle. In panel studies this usually means a new panel wave is started each year and each panel is surveyed yearly for a limited number of years. For geography this means that there are geographic panels each consisting of say one quarter of the total Metropolitan Areas in the United States.
A survey takes place yearly but the first year they survey only one geographic panel and each geographic panel is surveyed every four years. In this way the entire set of Metropolitan Areas is surveyed every four years.
------------------------------------------------------------
Namespace: g (Group)
Parent Maintainable: varies by usage
Type: GroupType
------------------------------------------------------------
Group
Extension base: Maintainable
@time
@captureinstrument
@panel
@geography
@dataProduct
@languageRelationship
@userDefinedGroupProperty
@userDefinedGroupPropertyValue
r:Citation (0..1)
r:Abstract (0..1)
r:AuthorizationSource (0..n)
r:UniverseReference (0..1)
r:SeriesStatement (0..n)
r:QualityStatementReference (0..n)
CHOICE (0..n)
r:QualityStatementScheme (0..n)
r:QualityStatementSchemeReference (0..n)
END CHOICE
r:ExPostEvaluation (0..n)
r:FundingInformation (0..n)
ProjectBudget (0..n)
r:Purpose (0..1)
r:Coverage (0..1)
r:AnalysisUnit (0..n)
r:AnalysisUnitsCovered (0..1)
r:KindOfData (0..n)
r:OtherMaterial (0..n)
r:RequiredResourcePackages (0..1)
r:Embargo (0..n)
CHOICE (0..n)
c:ConceptualComponent
r:ConceptualComponentReference
END CHOICE
CHOICE (0..n)
d:DataCollection
r:DataCollectionReference
END CHOICE
CHOICE (0..n)
l:BaseLogicalProduct
r:LogicalProductReference
END CHOICE
CHOICE (0..n)
p:PhysicalDataProduct
r:PhysicalDataProductReference
END CHOICE
CHOICE (0..n)
pi:PhysicalInstance
r:PhysicalInstanceReference
END CHOICE
CHOICE (0..n)
a:Archive
r:ArchiveReference
END CHOICE
CHOICE (0..n)
pr:DDIProfile
r:DDIProfileReference
END CHOICE
CHOICE
cm:Comparison
r:ComparisonReference
END CHOICE (0..n)
CHOICE (0..n)
s:StudyUnit
r:StudyUnitReference
END CHOICE
CHOICE (0..n)
SubGroup
SubGroupReference
END CHOICE
Example¶
Image¶
A reference to an image, with a description of its properties and type.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable:
Type: ImageType
------------------------------------------------------------
Image
Extension base: None
ImageLocation
TypeOfImage (0..1)
Example¶
InParameter¶
A parameter that may accept content from outside its parent element. For instance a variable has in InParameter from a question, binding is used to link the OutParameter of a Question to the InParameter of a GenerationInstruction.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: varies by usage
Type: InParameterType
InParameter
Extension base: Identifiable
@isArray
@limitArrayIndex
ParameterName (0..n)
Alias (0..1)
Description (0..1)
CHOICE (0..1)
ValueRepresentation
ValueRepresentationReference
END CHOICE
DefaultValue (0..1)
Example¶
The use of an inParameter in a more complex example is shown in inout
<r:InParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:GI_Age:1 </r:URN>
<r:Alias>AGE </r:Alias>
</r:InParameter>
OutParameter¶
Outparameter does not contain a limitArrayIndex attribute. Because while the OutParameter may be an array, only the InParameter needs to limit the input to a specific item in the array. For example, a question on the age of a person which is repeated for each person in a household would result in an array of ages as output. The variable noting the age of person 3 would only use the 3rd item in the array A parameter that contains output from its parent object, such as the specific response value of a question.
------------------------------------------------------------
Namespace: r (reusable)
Parent Maintainable: varies by usage
Type: ParameterType
------------------------------------------------------------
OutParameter
Extension base: Identifiable
@isArray
ParameterName (0..n)
Alias (0..1)
Description (0..1)
CHOICE (0..1)
ValueRepresentation
ValueRepresentationReference
END CHOICE
DefaultValue (0..1)
Example¶
The use of an OutParameter in a more complex example is shown in :ref: inout
<r:OutParameter isIdentifiable="true" scopeOfUniqueness="Agency" isArray="false">
<r:URN>urn:ddi:us.mpc:GI_Age_Cohort:1</r:URN>
<r:Alias>AGE_5</r:Alias>
</r:OutParameter>
Universe¶
Describes a universe which may also be known as a population. A Universe describes the “object” of a Data Element Concept or Data Element as defined by ISO/IEC 11179. A universe may be organized into hierarchical sub-universes. In addition to the standard name, label, and description, the universe may provide a generation code (how the universe is differentiated or split out from another universe), a definition of hierarchical sub-settings for the universe, and an attribute that indicates if the description of the universe is stated in terms of what the universe includes.
------------------------------------------------------------------
Namespace: cc (ConceptualComponent)
Parent Maintainable: UniverseSchemeType
Type: UniverseType
------------------------------------------------------------------
Universe
Extension base: Versionable
@isInclusive
UniverseName (0..n)
r:Label (0..n)
r:Description (0..1)
DefiningConceptReference (0..1)
UniverseGenerationCode (0..n)
CHOICE (0..n)
SubUniverseClass
SubUniverseClassReference
END CHOICE