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. Metadata regarding the methodology of the data collection process including, determining repetition patterns, sampling, collection modes, etc. 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.The module is described by a name, label, and description, provides spatial, temporal, and topical coverage information on the activities covered by the module, and references to external material related to objects in the module using OtherMaterial. The content of the module is organized within the following sections; Methodology, DataCaptureDevelopment, Collection Event, QuestionScheme (in-line or by reference), ControlConstructScheme (in-line or by references) containing the flow of a questionnaire or data capture process, InterviewerInstructionScheme (in-line or by reference), InstrumentScheme (in-line or by reference), ProcessingEventScheme (in-line or by reference), SamplingScheme (in-line or by reference) and DevelopmentActivityScheme.
Properties¶
Name |
Type |
Description |
|
---|---|---|---|
DataCollectionModuleName |
0..n |
A name for the DataCollection module. May be expressed in multiple languages. Repeat the element to express names with different content, for example different names for different systems. |
|
Label |
0..n |
A display label for the DataCollection module. Supports multiple language versions of the same content as well as optional formatting of the content. Repeat for labels with different content, for example, labels with differing length limitations. |
|
Description |
0..1 |
A description of the content and purpose of the DataCollection module. Supports multiple language versions of the same content as well as optional formatting of the content. |
|
Coverage |
0..1 |
Documents the spatial, temporal, and/or topical coverage of the data collection module. |
|
MethodologyReference |
0..1 |
Methodology covers approaches used for selecting samples, administering surveys or data collection approaches, timing repeated data collection activities, weighting, and quality control. |
|
DataCaptureDevelopmentReference |
0..1 |
Data capture development covers the development planning, process, and outcome for a partial or full data capture object (question, measurement, instrument, or control construct). Development normally included the development of the question wording, possible response domains and their presentation, translation for language or cultural variance in the population, question/measurement order and mode of delivery (instrument). Extensive work is often done for individual questions/measures that may be reused by different data capture instruments with the organization or for topical areas or populations that are difficult to measure. |
|
CollectionEvent |
0..n |
A specific event in the collection or capture process. |
|
QuestionSchemeReference |
0..n |
Describes a set of questions used for data collection. |
|
MeasurementSchemeReference |
0..n |
Describes a set of measurements used for data collection. |
|
ControlConstructSchemeReference |
0..n |
Describes a set of control constructs used to order and define processes such as data capture flow, instrument flow, sampling, data capture development activities, etc. Assumes the flow of the object along the prescribed routing (i.e. respondent through a questionnaire, data source through a measurement process, development object through a development process, or data set of a population through a sample sampling plan)Uses InParameters and OutParameters to describe the specific flow of datum captured by, used within, or processed by to create a stored datum in a variable. |
|
InterviewerInstructionSchemeReference |
0..n |
Describes a set of instructions used by the interviewer (respondent in the case of a self administered questionnaire) or instrument to support the accurate collection or capture of data. |
|
InstrumentSchemeReference |
0..n |
Describes a set of instruments used to collect or capture data. |
|
InstrumentReference |
0..n |
Describes an instrument within this Data Collection. |
|
ProcessingEventSchemeReference |
0..n |
Describes a set of processing events used to collect or capture data and process it during or post collection. May include the processes used to capture data in non-questionnaire data capture. |
|
ProcessingInstructionSchemeReference |
0..n |
Describes a set of processing instructions used to collect or capture data and process it during or post collection. May include the processing instructions used to capture data in non-questionnaire data capture. |
|
SamplingInformationSchemeReference |
0..n |
A set of sampling information maintained by an agency including sampling plans, sample frames, and samples. |
|
DevelopmentActivitySchemeReference |
0..n |
A set of development activities maintained by an agency, and used in the development, review, or creation of a question, measurement, data capture flow (control construct), or instrument. |
Properties Inherited from Maintainable¶
Name |
Type |
Description |
|
---|---|---|---|
Note |
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 |
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 |
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. |
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 |
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. |
|
UserAttributePair |
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 |
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 |
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 |
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. |
|
RelatedOtherMaterialReference |
0..n |
The inclusion of an existing OtherMaterial by reference. Use for any type of OtherMaterial not specifically addressed by an inline description for such as ExternalAid in QuestionItem. |
|
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. |
IsPublished |
boolean |
0..1 |
Indicates that the maintainable will not be changed without versioning, and is a stable target for referencing. |
Item Type Hierarchy¶
- Versionable
- Maintainable
DataCollection