Re: Conflicts between Cube and DCAT in metadata properties

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.

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 13:35:16 UTC