CodeList

A structure used to associate a list of code values to specified categories. May be flat or hierarchical. This is a maintainable object. In addition to the standard name, label, and description the CodeList specifies a recommended data type, the hierarchical nature of the CodeList, level descriptions, individual code values and associated category, and whether the CodeList contents are used to represent system specific missing values. May include another CodeList by reference. If including other CodeLists make sure there are no code conflicts in the overall content. A code value must be unique within the CodeList. May also include a reference to a default CategoryScheme.

Properties

Name

Type

Description

CodeListName

NameType

0..n

A name for the CodeList. May be expressed in multiple languages. Repeat the element to express names with different content, for example different names for different systems.

Label

LabelType

0..n

A display label for the CodeList. May be expressed in multiple languages. Repeat for labels with different content, for example, labels with differing length limitations.

Description

StructuredStringType

0..1

A description of the content and purpose of the CodeList. May be expressed in multiple languages and supports the use of structured content.

RecommendedDataType

CodeValueType

0..1

This field provides the recommended treatment of the data within an application. This field is important as some codes represented as numeric should be treated as strings, i.e., many standardized codes for industry, occupation, education, etc. The value should come from a controlled vocabulary - recommended values include the set found in W3C XML Schema Part 2, but excluding string sub-types, QNAME, and NOTATION.

CodeListReference

CodeList

0..n

Allows for inclusion by reference of another CodeList. Care must be taken to ensure that all code values of the resulting CodeList are unique.

CategorySchemeReference

CategoryScheme

0..1

Reference to a default category scheme, with the assumption that all categories referenced by the subsequent codes are part of it, unless overwritten by the scheme reference in the CategoryReference field of the code.

HierarchyType

string

0..1

Identifies the type of hierarchy used in the nesting of categories. Possible values are Regular and Irregular. A regular nesting indicates that the category hierarchy is consistent at all lower levels of the hierarchy, i.e., the lowest levels of the hierarchy are at the same level for every branch on the hierarchy.

Level

LevelType

0..n

Describes the levels of the code hierarchy. The level describes the nesting structure of a hierarchical coding structure. Note that the attribute levelNumber is used for referencing specific codes to their level identifier.

Code

CodeType

0..n

Includes a code value, references the category label, and describes the code’s position in a hierarchy.

IsSystemMissingValue

boolean

0..1

If “true” contents are used to represent system specific missing values. The default value is “false”.

Properties Inherited from Maintainable

Name

Type

Description

Note

NoteType

0..n

Note allows for the attachment of a piece of additional information to any object with an ID. Note facilitates capturing temporary processing notes such as “Review and approval required”. A single note can be attached to multiple objects by reference to the objects. Note may also contain content for a needed object that has been reported for addition in a later version of the schema. Ideally this should be handled by a local extension, but Note can accommodate run-time extensions when required. The Note should be housed within the Maintainable object that contains the referenced objects. In this way the user is ensured of receiving all known Note attachments when the maintainable content is delivered. This means that if a Note references objects within multiple Maintainable objects, the Note should be repeated in each Maintainable and reference only those objects with that Maintainable.

Software

SoftwareType

0..n

Indicate the software used to create and/or manage the metadata. This is repeatable to allow for multiple softwares or multiple functions. If this information is important it is advisable to provide it in each maintainable so that it does not become separated from the internal content if the metadata is re-factored.

MetadataQuality

MetadataQualityType

0..n

An assessment of the quality of the metadata within the Maintainable object, e.g. the quality of the transcription, completeness, editing status, etc.

ExternalReferenceDefaultURI

anyURI

0..1

Use to provide a default value for the URI of external references. Use of a URI in a reference within this maintainable overrides the value entered here. Nested maintainables should redeclare the contents of this attribute for clarity.

IsPublished

boolean

0..1

Indicates that the maintainable will not be changed without versioning, and is a stable target for referencing.

Lang

language

0..1

This is used to designate the language of the metadata content of the maintainable. If a lower level xml:lang attribute conflicts with the content at the maintainable level, the object level value takes precedence.

Properties Inherited from Versionable

Name

Type

Description

URN

string

1..1

Agency

string

1..1

ID

string

1..1

Version

string

1..1

UserID

UserIDType

0..n

Allows for the specification of identifiers other than the specified DDI identification of the object. This may be a legacy ID from DDI-C, a system specific ID such as for a database or registry, or a non-DDI unique identifier. As the identifier is specific to a system the system must be identified with the UserID structure.

InheritanceAction

string

0..1

The attribute “action” is used for inheritance situations where there is an override at the local level (within a grouped StudyUnit) which is not available for further inheritance. There are three possible values for “action”: Add - A new identifiable object (an Identifiable, Versionable, or Maintainable element) is provided locally with a new identifier (one that is not inherited). All properties (elements and attributes contained in the object) of the object are as specified. If an object with an existing id is created, this is an error.; Update - An object is provided locally with the SAME id as the inherited object. For each type of property that is specified locally, a full set of those properties is specified for local use. These properties replace any properties of this type which were inherited. Unspecified properties are used as inherited.; Delete - An object is provided locally with the SAME id as the inherited object. All properties specified locally in this object will be deleted if their types and values match those inherited. Note that to completely delete an object at the local level, all properties of the inherited object must be listed.

UserAttributePair

StandardKeyValuePairType

0..n

A system specific user defined property of the object expressed as a key/value pair. As this is specific to an individual system the use of controlled vocabularies for the key is strongly recommended.

VersionResponsibility

string

0..1

Person or organization within the MaintenanceAgency responsible for the version change. If it is important to retain the affiliation between and individual responsible for the version and his/her agency, it may be included in this notation. This is primarily intended for internal use.

VersionResponsibilityReference_Organization

Organization

0..1

Reference person or organization within the MaintenanceAgency responsible for the version change, as described in an OrganizationScheme. If it is important to retain the affiliation between and individual responsible for the version and his/her agency, a Relation should be created between the individual referenced here and his/her organization. This is primarily intended for internal use.

VersionResponsibilityReference_Individual

Individual

0..1

Reference person or organization within the MaintenanceAgency responsible for the version change, as described in an OrganizationScheme. If it is important to retain the affiliation between and individual responsible for the version and his/her agency, a Relation should be created between the individual referenced here and his/her organization. This is primarily intended for internal use.

VersionRationale

VersionRationaleType

0..1

Textual description of the rationale/purpose for the version change and a coded value to provide an internal processing flag within and organization or system. Note that versioning can only take place on objects owned by the specified DDI Agency. If you are creating a local instance of an object from another agency for current or future modification use BasedOnObject. If the changes being made result in what you determine to be new object rather than a version of a previous object, i.e. the change is too extensive to consider it a version of the existing object, create a new object and use BasedOnObject to provide a link to the object or objects that were a basis for the new object.

BasedOnObject

BasedOnObjectType

0..1

Use when creating an object that is based on an existing object or objects that are managed by a different agency or when the new object is NOT simply a version change but you wish to maintain a reference to the object that served as a basis for the new object. BasedOnObject may contain references to any number of objects which serve as a basis for this object, a BasedOnRationalDescription of how the content of the referenced object was incorporated or altered, and a BasedOnRationalCode to allow for specific typing of the BasedOnReference according to an external controlled vocabulary.

VersionDate

cogsDate

0..1

Date of version using the union set BaseDateType. Duration should not be used in this field, even though allowed by the ISO format enforced by the parser.

Item Type Hierarchy