-
Notifications
You must be signed in to change notification settings - Fork 6
Schema Change Requests 1.10
Home / METS Schema Revision Requests / Schema Change Requests 1.10
Would it also be possible to include RDF as a recognised MDTYPE attribute value? At present we are placing this as follows MDTYPE="OTHER" OTHERMDTYPE="RDF" but as we use RDF in all our METS documents it would be nice to have this as a recognized value so that we could place it as follows...
<METS:mdWrap MDTYPE="RDF">
<METS:xmlData>
<rdf:RDF>
<rdf:Description>
<!--RDF Metadata-->
</rdf:Description>
</rdf:RDF>
</METS:xmlData>
</METS:mdWrap>Just hit a situation in a research project that suggests a slight deficiency in the allowable values for the METS transformFile TRANSFORMTYPE attribute. Currently it allows for decryption or decompression. What if the overarching file is an ISO disk image (or other disk image file)? It doesn't need decompressing or decryption, it needs to be mounted as a disk subsystem to access the subsidiary files. If we want to keep the initial letter 'd' theme running, how about decryption, decompression and diskmount?
This request was withdrawn. MIME Type of disk image file can also be used affect same functionality.
Original Request from NDL Finland
- LIDO (Lightweight Information Describing Objects, see http://lido-schema.org/)
- EN15744 (CEN TC 372 Metadata standard EN 15744:2009 : Film identification - Minimum set of metadata for cinematographic works, see http://filmstandards.org/)
- EN15907 (CEN TC 372 Metadata standard EN 15907:2010 : Film identification - Enhancing interoperability of metadata: Element sets and structures, see http://filmstandards.org/)
Discussion We will add LIDO.
Discussion While having a VERSION attribute might be useful, there are at least a couple alternatives that could be used to indicate to which version of METS a specific document conforms. One is to use the optional and standard xsi:schemaLocation attribute to reference a specific version of the METS schema. Currently the latest METS schema is always avaialble at http://www.loc.gov/standards/mets/mets.xsd. However, all previous versions of the schema are also available at specific URLs, such as http://www.loc.gov/standards/mets/version18/mets.xsd. Thus, to indicate that a METS document conforms to a specific version you could add this attribute to the root mets element:
xsi:schemaLocation="http://www.loc.gov/METS/ http://www.loc.gov/standards/mets/version18/mets.xsd"
Another method used to specify a specific version of METS is via a profile. A METS profile may require a specific version of METS, by specifying a specific profile the METS document is in essence declaring that it conforms to a specific version of METS.
One other factor to consider is that since all 1.x schema are backward-compatible with documents that conform with earlier 1.x schema, a sophisticated parser could query for certain elements or attributes in a document to determine which version of the METS schema it complies with. NOTE: This might make for an interesting Schematron project: a Schematron which identifies the lowest METS Schema that can be used to validate a given METS document.
TGH: My inclination is to reject this request.
Rejected.
Discussion Exploring the option of adding anyAttribute to address this and future request to add similar attributes.
Discussion We should investigate importing the 'xml:' namespace, http://www.w3.org/XML/1998/namespace, to the METS schema and allowing the addition of an xml:lang attribute to any of the METS elements.
<xs:import namespace="http://www.w3.org/XML/1998/namespace" schemaLocation="http://www.loc.gov/mods/xml.xsd"/>
The other thing to consider is the XML document that is being wrapped. In an ideal world the XML document being wrapped would be able to declare its language independent of METS, meaning that METS would not need to declare the language. Here is a quick review of how the METS endorsed schema handle language:
- DC -- most XML schema for DC use the xml:lang attribute
- DDI -- uses the xml:lang attribute
- EAC-CPF -- uses the xml:lang attribute
- EAD -- uses a custom langcode attribute
- FGDC --
- ...
If it looks as if most endorsed external schema already have support for expressing the language of encoding in some fashion, I would be inclined to recommend that the external schema's mechanism be used for this instead of adding an attribute to METS. Although there may still be aspects of METS that could benefit from a language indicator for example any of the human-readable portions of the METS data itself such as div labels, for example.
There example may be invalid.
More flexible to have language expressed at individual field or element level instead of at a global level for all wrapped content.
Modify the CREATED attribute wherever it occurs to accept partial and inaccurate dates in the EDTF format
Discussion This would be a non-backward-compatible change because the EDTF format is not compatible with the xsd:dateTime data type that is currently used for this attribute. I suspect that all parsers which currently consume METS and care about the CREATED attribute expect it to be a valid dateTime value and would have real problems when encountering any other value. For this reason we should probably reject this request as it stands. However, there might be alternatives which are backward compatible. For example, the addition of an EDTF-CREATED attribute which accepts EDTF formatted dates. Another better possibility is a FREEFORM-CREATED attribute with the same semantics as CREATED but which accepts any string, and to go along with it FREEFORM-CREATED-TYPE which could have some enumerated values to indicate what type of date the FREEFORM-CREATED attribute contains, such as ISO-8601, EDTF, W3CDTF, xsd:dateTime, etc. I'm not thrilled with any of these suggestions, and maybe this kind of change should be deferred to the METS 2 schema overhaul.
The anyAttribute would fulfill this request.
Questions Is this really the first time this request has come up?