Re: Anyone able to help improve Dublin Core namespace XSLT to support RDFS RDFa?

The latest pull request [1] addresses the issues I'm aware of.

Gregg

[1] https://github.com/dublincore/website/pull/2

On May 11, 2012, at 11:57 AM, Thomas Baker wrote:

> On Fri, May 11, 2012 at 02:26:32PM -0400, Gregg Kellogg wrote:
>>> I'm not sure what you mean by "reduced".  The Web document says:
>>> 
>>>   Term Name:    Agent
>>>   URI:          http://purl.org/dc/terms/Agent
>>>   Label:        Agent
>>>   Definition:   A resource that acts or has the power to act.
>>>   Comment:      Examples of Agent include person, organization, and software agent.
>>>   Type of Term: Class
>>>   Instance Of:  http://purl.org/dc/terms/AgentClass
>>>   Version:      http://dublincore.org/usage/terms/history/#Agent-001
>>> 
>>> This matches the RDF/XML output except for the addition, in the RDF/XML, of
>>> rdfs:isDefinedBy and of the date issued (of the individual property or class).
>> 
>> Sorry, I ment _reversed_. It looks like the <dcterms:description> is the
>> comment and the <rdfs:comment> is the description in the RDF/XML output.
> 
> DCMI's use of rdfs:comment for the "Definition" goes back to the very first
> experimental RDF schema of October 1997 [1].  The use of dcterms:description
> for the "Comment" dates back to August 2002 [2].  What would you suggest as
> best practice today?
> 
> [1] http://dublincore.org/1997/10/02-dces
> [2] http://dublincore.org/2002/08/13/dces
> 
>>>> The HTML output ends up pulling in several definitions for
>>>> http://purl.org/dc/dcam/VocabularyEncodingScheme. Perhaps this needs some
>>>> additional filter to not define anything not in dcterms?
>>> 
>>> In the dcmi-terms/index.shtml output (RDFa-to-Turtle) I'm looking at, I only
>>> see one entry for VocabularyEncodingScheme, as in [1]:
>>> 
>>>   <http://purl.org/dc/dcam/VocabularyEncodingScheme>
>>>      dc:issued "2008-01-14";
>>>      rdfs:identifier <http://purl.org/dc/dcam/VocabularyEncodingScheme>;
>>>      rdfs:seeAlso <http://dublincore.org/documents/2007/06/04/abstract-model/>;
>>>      rdf:type rdfs:Class;
>>>      dc:hasVersion <http://dublincore.org/usage/terms/history/#VocabularyEncodingScheme-001> .
>>> 
>>> The rdfs:identifier is wrong, if only because rdfs:identifier does not exist...
>>> 
>>> Compared to the Web document [1], what is systematically missing in this
>>> RDFa-to-Turtle output (and in the RDFa-to-Turtle output for all other
>>> properties and classes) is:
>>> 
>>>   rdfs:label for the "Term Name"
>>>   rdfs:comment for the "Definition"
>>>   dcterms:description for the "Comment" (though not for "VocabularyEncodingScheme", which does not have one)
>>> What is systematically missing compared to the RDF/XM
>> 
>> Corrected in my REPO. as is adding Date Issued and Date Modified to the
>> tabluar definitions; it was explicitly removed before. If you'd like to keep
>> it out of the term tables as hidden elements, I can go back to that.
> 
> Including the issued and modified dates for each property and class makes the
> printout longer without adding information that will be of use to most readers
> of the HTML.  Including the more fine-grained information such as dates, per
> term, was always the function of the "history" document [3].  My impulse would
> therefore be to keep those dates out of the term tables in the main DCMI
> Metadata Terms document.  What do others think?
> 
> [3] http://dublincore.org/usage/terms/history/
> 
>>> Do I correctly understand that if the HTML/RDFa document completely expresses the 
>>> contents of the current HTML and RDF/XML documents, and we direct the PURLs to that 
>>> document, we could delete (or rather archive) the XSL scripts used to generate the
>>> RDF/XML?  The other simplifications I would like to make are:
>>> 
>>> -- Delete (or archive) the XSL script for generating the (redundant) stand-alone
>>>  DCMI Type Vocabulary document.
>>> 
>>> -- Revert to the pre-RDFa XSL script for generating the "history" document [2].
>>> 
>>> This means that only one XSL script for generating RDFa would need to be
>>> maintained.
>> 
>> That's true, but there is value in providing alternate representations
>> (perhaps using content negotiation), which should probably include Turtle.
>> You could certainly go to auto-generating this from the HTML+RDFa, though.
> 
> Auto-generating the Turtle from HTML+RDFa seems like it would be less risky
> because they would come from the same RDF source -- not from XML-markup source
> via multiple scripts, all of which would have to be maintained and kept in
> sync, as now...
> 
> Tom
> 
> -- 
> Tom Baker <tom@tombaker.org>

Received on Friday, 11 May 2012 20:51:03 UTC