Relationship between RDFS metadata and DC metadata (was: Re: Conflicts between Cube and DCAT in metadata properties)

Phil,

On 11 Mar 2013, at 13:34, Phil Archer wrote:
> Just to note this is really useful. I'm going to emulate the decision for ADMS as well as it currently uses rdfs:label but I've found when using it that I always feel I really ought to have used dcterms:title so I'll edit ADMS to bring it into alignment in the way Dave has done with QB.

I agree with this change. I've often felt uncertainty about this very question, so at some point came up with this little policy:

1. Every resource, whenever practical, should have rdfs:label and rdfs:comment. This is for dumb RDF display tools.

2. Once you want to specify extra metadata besides label and comment, and hence start using DC, you should probably use dc:title and dc:description instead of rdfs:label and rdfs:comment, or use both sets of properties if you don't mind the duplication.

3. dc:title/description really ought to be subproperties of rdfs:label/comment.

If #3 was actually asserted in the DC docs, then dumb display tools could infer the label and comment from DC metadata, and we wouldn't need to repeat the value.

(I'm cc'in Tom Baker and Makx, as I'm curious what they think about #3.)

Best,
Richard



> 
> Phil.
> 
> On 08/03/2013 15:10, Dave Reynolds wrote:
>> On 08/03/13 11:58, Richard Cyganiak wrote:
>> 
>>> Well, it is my view that qb:DataSet is a subset of dcat:Dataset.
>> 
>> OK, agreed.
>> 
>>> The metadata properties recommended in both documents are somewhat
>>> different:
>>> 
>>> Data Cube                | DCAT
>>> -------------------------+-------------------------
>>> rdfs:label               | dc:title
>>> rdfs:comment             | dc:description
>>> dc:date                  | dc:issued, dc:modified
>>> dc:subject->skos:Concept | dcat:theme->skos:Concept
>>> dc:publisher->foaf:Agent | dc:publisher->foaf:Agent
>>> 
>>> Data Cube is a bit self-contradictory here, it says “We recommend use
>>> of Dublin Core Terms for representing the key metadata annotations
>>> commonly needed for DataSets.” but then uses rdfs:label and
>>> rdfs:comment in preference of DC, perhaps to be consistent with the
>>> many other places in Cube where these properties are used. Since a
>>> dataset can be thought of as an abstract "document", "work" or
>>> "publication", the use of DC seems more appropriate to me here.
>>> 
>>> Cube also implies that dc:date is the creation date, which is not
>>> quite correct. dc:date could be any date in the lifecycle of the
>>> resource.
>>> 
>>> Proposed steps for aligning the two specs:
>>> 
>>> - recommend dc:title/description on qb:DataSet in addition to
>>> rdfs:label/comment
>>> - recommend dc:issued instead of dc:date for creation date in Data Cube
>>> - Add a note to beginning of Data Cube Section 9 that says that other
>>> documents such as DCAT have additional recommendations for metadata
>>> properties.
>>> - make dcat:theme a subproperty of dc:subject in DCAT
>>> 
>>> The result would be that if you follow the DCAT recommendations, you
>>> end up with something that matches the Cube recommendations, except
>>> for the use of a subproperty in the case of dcat:theme vs dc:subject.
>> 
>> Makes sense. I have made those changes. Please check and feel free to
>> improve.
>> 
>> To reference DCAT I have referenced it as Working Draft published on 12
>> March 2013. If the publication doesn't go ahead on time then this will
>> need to be changed (in ../respec/gld-bib.js). Synchronized publications
>> are fragile :)
>> 
>> I'll now hand over the edit token to you to do this and whatever else is
>> needed in the in final run up to publication.
>> 
>> The latest checked-in version has the two changes from Benedikt's
>> feedback (clarification that all measures are always required,
>> generalizing ic-19b to allow for nested skos collections) plus these
>> changes to section 9. So I believe that is everything.
>> 
>> N.B. The currently checked-in static file [1] is up to date and pubrules
>> clean. This time to make it clean I had to do one more manual
>> post-render fix in addition to the issues I listed yesterday. The respec
>> generated text for the status section is:
>> 
>>    "Publication as a Working Draft does not imply endorsement by  ..."
>> 
>> whereas pubrules requires:
>> 
>>    "Publication as a Last Call Working Draft does not imply endorsement
>> by ..."
>> 
>> This is despite that fact that respec knows this is a Last Call WD in
>> other places and that the pubrules check passed yesterday (and I've made
>> no change to respec configuration or respec). The combination of respec
>> and pubrules is not quite perfect yet.
>> 
>> Dave
>> 
>> [1] https://dvcs.w3.org/hg/gld/raw-file/default/data-cube/static.html
>> 
>> 
> 
> -- 
> 
> Phil Archer
> http://philarcher.org/
> +44 (0)7887 767755
> @philarcher1
>

Received on Monday, 11 March 2013 19:20:37 UTC