Re: Conflicts between Cube and DCAT in metadata properties

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

Received on Friday, 8 March 2013 15:11:31 UTC