DCAT is a W3C Recommendation, and RDF vocabulary describing mainly collections (of datasets, catalog records, distributions, etc.)
There should be a clear alignment including examples with the Linked Data Platform 1.0 W3C Recommendation describing modeling of generic containers and their members.
For instance, dcat:Dataset could also be (could also have) a ldp:DirectContainer with ldp:hasMemberRelation dcat:distribution and similarly for dcat:Catalog, dcat:CatalogRecord and maybe others.
Clearing this alignment up would improve interoperability e.g. among potential Solid based data catalogs, etc.
Hey @jakubklimek - I admire your ambition to grandly unify W3C's thinking here.
Mind you, to get this into the normative content there will have to be a stronger use-case than mere (!) consistency ...
My current expectation is that DCAT will mostly be stand-alone (with a lot of DC and some references to ODRL, and possibly ADMS). The alignments (many!) will probably be 'informative' annexes and graphs.
I started a couple here: https://github.com/w3c/dxwg/tree/gh-pages/dcat/rdf
Perhaps you could formulate DCAT-LDP as an RDF graph to be dropped in there?
@dr-shorthair The use case is any Solid based data catalog application (admittedly non-existent at the moment).
I am not sure yet that there will be an RDF alignment graph. Maybe a set of examples illustrating the alignment could be enough. That is up for discussion.
Now I think that there should even be examples of interoperability with the recent Social Web Protocols so that it is clear
They include:
A sample of such an example for Linked Data Platform could be (note the explicit links to LDP containers in DCAT namespace):
@prefix dcat: <http://www.w3.org/ns/dcat#> .
@prefix ldp: <http://www.w3.org/ns/ldp#> .
@prefix dct: <http://purl.org/dc/terms/> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@base <https://example.org/resource/catalog> .
<> a dcat:Catalog ;
dcat:records </records/> ;
dcat:datasets </datasets/> ;
dcat:services </services/> ;
dcat:dataset </datasets/001> , </datasets/002> .
</records/> a ldp:Container, ldp:DirectContainer ;
ldp:membershipResource <> ;
ldp:hasMemberRelation dcat:record ;
ldp:contains </records/001> , </records/002> .
</datasets/> a ldp:Container, ldp:DirectContainer ;
ldp:membershipResource <> ;
ldp:hasMemberRelation dcat:dataset ;
ldp:contains </datasets/001> , </datasets/002> .
</services/> a ldp:Container, ldp:DirectContainer ;
ldp:membershipResource <> ;
ldp:hasMemberRelation dcat:service ;
ldp:contains </services/001> , </services/002> .
</records/001> a dcat:CatalogRecord ;
foaf:primaryTopic </datasets/001> .
</datasets/001> a dcat:Dataset ;
dcat:distributions </datasets/001/distributions/> ;
dcat:distribution </datasets/001/distributions/001>, </datasets/001/distributions/002> .
</datasets/001/distributions/> a ldp:Container, ldp:DirectContainer ;
ldp:membershipResource </datasets/001> ;
ldp:hasMemberRelation dcat:distribution ;
ldp:contains </datasets/001/distributions/001>, </datasets/001/distributions/002> .
</services/001> a dcat:DataService .
I can develop examples for the other Recommendations, feedback welcome.
Ah - so you are proposing to complement the current property dcat:dataset etc with new properties dcat:datasets etc that would link to a LDP resource that lists all the datasets?
Note that dcat:catalog, dcat:dataset and dcat:service are all sub-properties of dct:hasPart. Is there a similar super-property for the proposed properties?
I propose these properties as means of discovery of the LDP containers from the respective DCAT entities, if they are used.
Similarly to dct:hasPart there could be dcat:hasContainer as a super-property with ldp:DirectContainer as rdfs:range. The LDP specification itself leaves it up to implementation how the containers should be discovered.
This all looks reasonable and unobtrusive for current users. Though not motivated by one of our accepted Use Cases.
I suggest writing it up as a discrete chapter for the rec, to guide people who need to integrate with LDP. Then the group can decide whether it should be tagged
Added to editors draft (#257) as per discussion above. We still need to decide the
This should be moved to an Annex and marked 'non-normative'.
It is a highly plausible, but essentially un-tested, proposal.
Furthermore, it introduces new elements in the dcat: namespace, which have not been specifically discussed and approved. I suggest moving these into a dcat-ld: namespace to make it clear that this is not part of core DCAT.
Move to Annex actioned in #873, but some further discussion on ultimate home needed as per comment before this issue is ready to close.
Returning to this:
LDP is just one of many possible platforms on which DCAT might be implemented. Yes it is a W3C technology, but there is no certainty that it will dominate the marketplace as a consequence.
The extensions/alignments introduced in this section are relatively simple and quite reasonable. But they are outside the scope of the DCAT vocabulary so probably don't belong in this document. Suggest moving to a separate document, perhaps formulated as a 'profile'.
@andrea-perego would this approach address your comment ?
As resolved in DCAT sub-group meeting, tidy up of ED with preservation of contribution for future publication in more appropriate place - proposed edits in #915
Now #915 is merged, mark as due for closing
Most helpful comment
Hey @jakubklimek - I admire your ambition to grandly unify W3C's thinking here.
Mind you, to get this into the normative content there will have to be a stronger use-case than mere (!) consistency ...
My current expectation is that DCAT will mostly be stand-alone (with a lot of DC and some references to ODRL, and possibly ADMS). The alignments (many!) will probably be 'informative' annexes and graphs.
I started a couple here: https://github.com/w3c/dxwg/tree/gh-pages/dcat/rdf
Perhaps you could formulate DCAT-LDP as an RDF graph to be dropped in there?