OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

codelist message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Non-material changes in CSD05 after the last public review


The following non-material changes have been incorporated in CSD05 after the last public review:

1) a new non normative "Appendix E Considerations of life cycle metadataâ was added;
2) the formed Appendix E and the following have been renumbered accordingly.

Appendix E Considerations of life cycle metadata (Non-Normative)

Data life cycle management relies on having useful life cycle metadata with which to record properties of data and histories of changes in that data. Such life-cycle concepts readily apply to code list values. A few example concepts include but are not limited to dates and times indicating when a value in a coded domain is accepted to be used by users or is considered a valid value, a signal of deprecation indicating when a value may still be valid but is recommended not to be used, and jurisdictional constraints within which a value may be used to the exclusion of other jurisdictional boundaries.

Custodians of code lists should consider all such metadata issues from the beginning of planning and creating a new list of values in a coded domain.

The flexibility of genericode to declare columns of value-level metadata supports describing life-cycle metadata in addition to any other kind of metadata or other information that may be associated with values in a coded domain.

Per the semantics of genericode, all of the information associated with an individual coded value or part thereof is captured in the <Row> element. Human-oriented information about the coded value or part in general that is not intended to be processed by a computer is put into the <Annotation> child of <Row>. Computer-processable information is put into a set of <Value> elements as metadata. Human-oriented information about a particular metadata value is put into the <Annotation> child of <Value>. Computer-processable information is put into either a <SimpleValue> child of <Value> for a monolithic string value, or into a <ComplexValue> child of <Value> for a value that, itself, is allowed to be described richly using markup.

The semantics and constraints of each metadata <Value> are described to an arbitrary extent in the <ColumnKey> element identified with the <Value> elementâs columnRef= attribute. Custodians of code lists should consider how richly described each of the metadata columns serves the reader or user of the code list when they inspect the content of <ColumnKey>. It is entirely up to the listâs custodian to establish and to document the semantics and constraints of code-level metadata values in <ColumnKey>.

Accordingly, it is not part of genericode to standardize any semantics beyond the semantics of the genericode specification itself of how genericode markup is used to represent values in a coded domain. There are no standardized value-level metadata semantics, and so, there are no standardized life-cycle metadata semantics to be leveraged by genericode users.

While some life-cycle metadata semantics are considered somewhat universal, each custodian may have a different perspective of such semantics that impacts on their decisions regarding how each semantic is to be expressed, constrained, and documented. Therefore, this specification does not attempt to define any standardized code-level metadata of any kind, including data life cycle management metadata.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]