Dxwg: do we want to use skos:definition or rdfs:comment in the dcat.ttl?

[riccardoAlbertoni]

Why dct:language, dct:hasPart, dct:relation, dct:type have no skos:definition in the dcat.ttl while dct:PeriodOfTime and others have?
In the DCAT WD, we provide definitions for every term. Should we add the missing skos:definition in the dcat.ttl?

[agbeltran]

yes, I think it is an oversight and we should add the definitions

[riccardoAlbertoni]

For some terms, we provide definitions using the property skos:definition, for others, we use rdfs:comment?
I think we should choose one of the two and harmonize the dcat.ttl accordingly. Which one do we prefer?

[riccardoAlbertoni]

I suspect that rdfs:comment(s) were used in the previous version of dcat and we have mostly inherited their usage, while skos:definition(s) have been added for terms defined dcat2.

AFAIK, skos:definition is not a sub-property of rdfs:comment, so If we want to be back compatible with the systems that already exploit rdf:comments in their GUI, I see the following possibilities:
A- turning all the skos:definition in rdfs:comment
B- use both for all the terms

is there any objection if we implement the solution A? any other ideas?

[dr-shorthair]

Indeed:

skos:definition rdfs:subPropertyOf skos:note .
skos:note rdf:type owl:AnnotationProperty .

skos:definition looks like better semantics, but rdfs:comment is more widely used.

[riccardoAlbertoni]

I suspect that rdfs:comment(s) were used in the previous version of dcat and we have mostly inherited their usage, while skos:definition(s) have been added for terms defined dcat2.

AFAIK, skos:definition is not a sub-property of rdfs:comment, so If we want to be back compatible with the systems that already exploit rdf:comments in their GUI, I see the following possibilities:
A- turning all the skos:definition in rdfs:comment
B- use both for all the terms

is there any objection if we implement the solution A? any other ideas?

@akuckartz seems to dislike Solution A, we might still choose between
B- use both skos:definition and rdfs:comment for all the terms
C- replacing all the rdfs:comment in skos:definition (losing back-compatibility with systems that expect rdfs:comments as in dcat 1.0)
Any preference?

[agbeltran]

I would select solution B - so that we are backward compatible and we also provide the more specific skos:definition. We should probably try to automate the copy, considering one of those as the master one - otherwise we might start having inconsistencies.

[riccardoAlbertoni]

dct:hasPart, dct:language, dct:relation and dct:type are duplicated in the DCAT ttl.
We were adding definitions to duplications of dct:hasPart, dct:language, dct:relation and dct:type. Definitions for the aforementioned properties are already included so I deleted my PR #998

[riccardoAlbertoni]

The part of the discussion related to using both skos:definition and rdfs:comment is still relevant and to be implemented. According to issue #725, we use skos:scopeNote instead of skos:definition for definitions introduced in dcat for the external terms.

[davebrowning]

I think some of this was addressed in #1010 (now merged) but possibly not all.

[riccardoAlbertoni]

I think some of this was addressed in #1010 (now merged) but possibly not all.

No, it isn't ;) According to my understanding, we still need to make sure that both skos:definition and rdfs:comment are used.

[dr-shorthair]

For the elements from other vocabularies, I copied over the original definitions (from DCT, PROV, FOAF, ODRL) into skos:definition in our dcat.ttl.
This was partly as an aid to editing the local re-definitions/refinements.

Then where the DCAT defs vary, they are also in skos:definition props but the text is prefrixed with "In the context of DCAT 2.0 ..."

I think all of the other annotations are now skos:scopeNote and skos:changeNote

[dr-shorthair]

@agbeltran I automated copying rdfs:comment toskos:definition` for all the DCAT classes and properties.

As we've been editing the ttl manually over the last few rounds, TopBraid was likely to re-order on save. So, in order that you can trace the diffs, I did it in two steps:

1. load in TopBraid, only make tiny changes, and then save. First commit 01db5afa6bdd69e31f6c1dec72d3001ec6f7e5de
2. SPARQL to copy comments to definitions, save again. Second commit efcf654a99f87a4490454581e80264ac0e7d30ba

See https://github.com/w3c/dxwg/blob/dcat-issue-983/dcat/rdf/dcat.ttl and #1034

[nicholascar]

Profiles Vocab uses skos:definition for all its properties as it's defining the, not just offering comment about them.

[riccardoAlbertoni]

@nicholascar

Profiles Vocab uses skos:definition for all its properties as it's _defining_ the, not just offering comment about them.

In the current state, we have skos:definition for all the DCAT terms (terms from DCAT 2014 and DCAT 2). We have maintained the rdfs:comments that were present in the dcat2014 for backward compatibility.

I think we can close this issue. Any objections?

[nicholascar]

Thanks @riccardoAlbertoni, I see convergence (or is it groupthink?) around the use of definition v. comment. Either way, there is an emerging practice here that seems to work.

[davebrowning]

Closing this issue, since (as noted) we have a consistent approach here that seems to work (and more clear with the separating the RDF into dcat.ttl and dcat-eternal.ttl (see https://github.com/w3c/dxwg/tree/gh-pages/dcat/rdf). Closing this specific issue.

(Note that #725 has some associated comments but covers a much wider ground).