Categories
General

Can you really refine DC elements in HTML as explained in the Metadata MOOC?

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:

  1. I cannot find anything explaining it in the current specifications
  2. 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.

Categories
Meta

Now with Dublin Core and translations!

As a fan of semantics on the web, I couldn’t let it happen that my own blog posts don’t have at least some basic metadata. Thanks to the Dublin Core for WordPress plugin, the basic metadata (title, author, publication date, language of the post, etc.) is now automatically inserted into all the blog posts. See for yourself under “View Page Info”.

I was proud to see the metadata all there. Except for language, because even for Dutch posts, it was “en-US” (American English). There didn’t appear to be any options to change that language, turn off the inclusion of language metadata, let alone setting the language per post.

But plugins exist for that too. I chose Polylang after reading its description. Per post I now set the language of the post and what other post contains the translation (if there is any). Category names and the blog’s tagline now also have translations. I’m still getting used to the new navigation around the blog (on your first visit the blog language is probably determined by your preferred language settings) and having to write posts twice. Don’t expect me to add a third language.

Categories
Meta

Nu met Dublin Core en vertalingen!

Als fan van semantiek op het web kan ik het niet laten gebeuren dat mijn eigen stukjes tekst niet op zijn minst algemene metadata bevatten. Dankzij de WordPressplugin Dublin Core for WordPress wordt de basismetadata (titel, auteur, datum van publicatie, taal van het stuk, enz.) nu in elke post gevoegd. Kijk eens bij “Page info” (Engelse Firefox) en zie de gegevens daar staan.

Trots was ik ook toen ik die gegevens vond. Behalve op de taal: bij een Nederlands stuk stond als taal “en-US”, oftewel Amerikaans Engels. Er leek geen instelling te zijn om die taal aan te passen, de taal niet te laten invoegen in de pagina’s, laat staan per artikel aan te geven in welke taal het artikel is geschreven.

Maar ook daar zijn plugins voor. Op basis van de beschrijving heb ik gekozen voor Polylang. Per artikel geef ik nu aan in welke taal het is geschreven en welk ander artikel de vertaling ervan is (mits dat artikel er is). Daarnaast zijn categorie├źn en de tagline van de blog nu ook tweetalig. Ik moet zelf ook wennen aan de navigatie tussen de talen (bij je eerste bezoek wordt waarschijnlijk uitgegaan van de taal die je hebt ingesteld als voorkeurstaal) en vooral ook aan het feit dat ik ook stukken twee keer moet schrijven. Verwacht daarom geen derde taalkeuze.