Hi all,
My initial impression is this is a very literal and overly-thorough way to represent Description Sets, but is quite cumbersome so would not be my first choice for encoding DC in XML. It appears to faithfully encode Description Set metadata.
A handful of small points:
* 4.4.1 - in the sentence "Note that a literal value surrogate can not contain a value URI or a vocabulary encoding scheme URI" you might consider adding to the end ", but it may contain a URI as a string if that is the value of the literal.", just to clarify that situation.
* 4.5.2.2 XML data as Typed Value String - is this a new feature? I don't recall the support of XML fragments in the DCAM in the past, is this the return of "rich representation"? Does this mean binary formats (eg. JPEG) could also be encoded directly in the XML?
* 4.6, example 20, last sentence - "Note that this is a syntactic mechanism for linking references to values in statements to the descriptions of those values: the local identifier itself does not appear in the description set." - it would be nice to include a reason for this.
* Personally I think I'd prefer the labels 'vocabularyURI' and 'syntaxURI' to 'vesURI' and 'sesURI', but can see they fit better into the level of thoroughness being applied (eg. URI in several of the names seems redundant, eg. a property MUST be a URI, so naming it 'propertyURI' seems like overkill).
* The table of contents include 'notes' and 'acknowledgements' - but these links go nowhere.
I am assuming (hoping) the subsequent (simpler) DC XML encodings will move in a different direction to this encoding. For example, using simpler structures such as <dc:title> or even something XSLT-like (eg. <dcds:property name="title"/>) rather than the un-intuitive <dcds:propertyURI="http://purl.org/dc/terms/title"/> - is it done like this so you don't have to declare namespaces for property URIs?
Thanx,
Douglas
|