I originally posted this as a question in the Coursera MOOC on Metadata’s discussion forums on 2014-07-30. So far I have received no written responses at all, but I did get 5 points (upvotes) for posting. I hope someone outside the MOOC may be able to answer and please correct me if I’m wrong. If my concerns are justified, perhaps this may trigger a bit of a change in the course materials — I’m wary that in the coming video lecture series on Linked Data dr. Pomerantz will still confuse subject and object, but I’ll wait to see if anything has changed since last year’s session.
I’m having trouble understanding why using DC.date.modified as name in a <meta> element is the correct way of refining the date element in HTML, for two reasons:
- I cannot find anything explaining it in the current specifications
- I use elements in someone else’s namespace that have not been defined in that namespace (or anywhere else), don’t I?
Longer version:
It appears that the document Element Refinement in Dublin Core Metadata (linked next to the 2-7 lecture about Qualified Dublin Core) only describes element refinement using the RDF model. I know the semantics of rdfs:subPropertyOf and it makes sense to me to express refinements this way.
For learning to express Dublin Core elements in HTML, the document refers to the obsolete http://dublincore.org/documents/dcq-html/, which has one reference to refining DC elements by appending . + the refinement, namely in the section that describes how the spec is (in)compatible with previous and other versions.
Note that previous versions of this document (and other DCMI HTML-encoding documents) made some different recommendations to those found in this document, as follows:
(…)
Previous recommendations specified prefixing element refinements by the element being refined, for example ‘DC.Date.modified’ rather than ‘DCTERMS.modified’.
(…)
These forms of encoding are acceptable but are no longer considered the preferred form.
The document that replaces it, Expressing Dublin Core metadata using HTML/XHTML meta and link elements, has no references or examples of refined elements at all. It does make clear how to interpret the properties as URIs:
In a DC-HTML Prefixed Name, the prefix is the part of the name preceding the first period character; the remainder of the string following the period is treated as the "local name" and appended to the "namespace URI". If a DC-HTML Prefixed Name contains more than one period character, the prefix is the part preceding the first period, and the local name is the remainder of the name following the first period, and any subsequent period characters simply form part of the local name.
In the following example the DC-HTML Prefixed Name "XX.date.removed" corresponds to the URI
http://example.org/terms/date.removed
<link rel="schema.XX" href="http://example.org/terms/" >
<meta name="XX.date.removed" content="2007-05-05" >If I were to apply this to a property whose namespace is the DC Elements Set namespace, I’d get a URI that is in the DC namespace, but that is not defined in that namespace.
<link rel="schema.DC" href="http://purl.org/dc/elements/1.1/" >
<meta name="DC.title.serial" content="Services to Government" >I say that the value of the property http://purl.org/dc/elements/1.1/title.serial of a described resource is "Services to Government". This property is not defined. The same goes for the examples in the lectures and homework: by just appending some string that may or may not make sense to other humans, you can’t really expect to refine the property, can you?
So I’m puzzled. What document(s) explain this way of refining (well-)defined elements?
After continuing my search: Is it RFC 2731 from 1999 by Kunze, Encoding Dublin Core Metadata in HTML? Section 6 indeed explains the use of
<meta name = "PREFIX.ELEMENT_NAME.SUBELEMENT_NAME" ... >for "qualifying" elements, but a few lines below, it says:
Note that the qualifier syntax and label suffixes (which follow an element name and a period) used in examples in this document merely reflect current trends in the HTML encoding of qualifiers. Use of this syntax and these suffixes is neither a standard nor a recommendation.