DC-2014 Metadata Quality

> ***Please excuse the cross-posting***

no need to apologize, especially if sticking to a single message-ID for your posts but even if not, so long as you're not tweaking the body each time so SHA-1 has a new output - see http://ruben.verborgh.org/blog/2014/01/31/apologies-for-cross-posting/ , whose author is incidentally presenting a PRE-/POST-CONFERENCE WORKSHOP at the conference you are posting about.

> 2. From the perspective of an implementor, what do we mean by
   "validation,"

not sure. should a successful retrieval be considered a requirement ?
at the very least, one has to retrieve the info before validating it?

am interested in a session at this conference, Dublin Core Metadata for Research Data–Lessons Learned in a Real-World Scenario.. as i've been having issues with a fairly simple real-world scenario of looking up a definition on the web

 <http://purl.org/dc/terms/date> is the term i am interested in .

the server says it moved temporarily to <http://dublincore.org/2012/06/14/dcterms#date>

so a request for a requestable-URI has resulted in a redirect to a location *inside* a requestable-URI (a fragID appeared, a local identifier with MIME-specific interpretation). hopefully that pointer from the server is to the data i was looking for, so request:

<http://dublincore.org/2012/06/14/dcterms> and again redirected, depending on the MIME-type preferences stated, to at least:

<http://dublincore.org/2012/06/14/dcterms.ttl> for 'text/turtle' 
<http://dublincore.org/2012/06/14/dcterms.rdf> for 'application/rdf+xml'
<HTTP://dublincore.org/documents/2012/06/14/dcmi-terms?v=terms> for 'text/html'

and now we can get onto finding the #date reference:

starting with HTML, my trail is coming up cold. have viewed source, and see:
<tbody id="terms-date" class="term" resource="http://purl.org/dc/terms/date">

this is close, but id="date" would have been required to be correctly finish resolving the reference. what is going on here?

similarly, #date appears nowhere in the RDF results, so i'm wondering why the server pointed to it?

the RDF fared slightly better than HTML here since subsequent requests for the definition of <http://purl.org/dc/terms/date> didn't have to bubble up to the HTTP layer from a caching local graph-DB that did find some statements about that URI in the process of gleefully importing everything seen in documents requested while on the trail to the missing-fragID

Received on Friday, 22 August 2014 03:18:03 UTC