copyrightMD Schema

Version 0.9

Enhancement Proposals

• General
  • Usage of @publication.status data values and <creation> vs. <publication>: How are these structually parallel? Currently, we would like to enforce a dependency between using @publication.status="published" with <publication> or <publication> and <creation>. (Related issue: in what case would both <publication> and <creation> be used?) . Is there a dependency between @publication.status="unpublished" and <creation>? Would be good to clarify this in the application guidelines.
  • Date normalization: Consider adding MODS-based year normalization attributes to <year...> elements.
• Attributes
  • Unknown data values: Suggest adding attribute for encoding unknown data values to all elements. Currently, "unknown" is a data value available on the @year.type attribute on date elements only.
  • Representing creator roles: Suggest adding @role (and @source for role terms?) subelement and/or attribute to <creator> name subelements.
  • Indicating sources of information: Suggest adding @source attribute to elements to indicate where data was taken (e.g., use to indicate if creation dates were taken from source item or from other reference materials).
• Elements
  • Name data modeling:
    • Suggest that we normalize the data model for names so that <name> sublement is used consistently in parent-level <creator.person>, <creator.corporate>, <rights.holder>, and <services>. Related issue: normalize whether or not name data can be allowed within parent-level elements, or must be encoded within <name> subelement.
    • The <rights.holder> element provides for multiple <name>, <contact>, and <note> subelements, which can occur in any order. Suggest that the schema contrains use of <contact> and <note> within <name>.
    • The <service> element provides for multiple <contact> and <note> subelements, which can occur in any order. Yet in the examples, the <note> elements pertain specifically to the <contact> that precedes them--and in fact appear to give information about how to get in touch with a particular contact. Suggest that the schema contrains use of <contact> and <note> within <service>.
  • Contact information data modeling: Suggest that we normalize the data model for contact information so that it is consistent for <rights.holder> and <services>. Related issue: <contact> (within <services>) needs a defined type, e.g., type="xs:string".
  • Country of publication: Suggest making this element repeatable, e.g., a work published in multiple countries.