w3c / dxwg

Data Catalog Vocabulary (DCAT)
https://w3c.github.io/dxwg/dcat/
Other
139 stars 55 forks source link

different uses of dcat:catalog (membership or part of interpretation) #1599

Open bertvannuffelen opened 2 months ago

bertvannuffelen commented 2 months ago

In DCAT-AP this issue has been raised on the usage of dcat:catalog. https://github.com/SEMICeu/DCAT-AP/issues/292.

In the harvesting use case, the aggregating catalogue A will harvest a catalogue B. What is then the expected representation of catalogue to indicate that B has been harvested by A .

:B a dcat:Catalog;
   dcat:dataset [ :dsB;  :cB ] .

:dsB a dcat:Dataset.
:cB a dcat:Catalog.

:A1 a dcat:Catalog;
   dcat:catalog :B ;
   dcat:dataset [ :dsB;  :cB ] .

:A2 a dcat:Catalog;
   dct:hasPart :B ;
   dcat:catalog :cB ;
   dcat:dataset :dbB . 

Which pattern should be followed to create an aggregated catalogue from the harvested catalogues while keeping a trace to the orginal catalogues in the aggregation?

nicholascar commented 2 months ago

"keeping a trace to the original catalogues" seems to be a requirement here and I've seen it elsewhere a lot. I deal with large, aggregated catalogues that harvest from other catalogues but often do a poor job of indicating the home locations of individual resources.

So we have been using qualified relationships from resources back to catalogues like this:

 {RESOURCE}
     dcterms:isPartOf [
         dcat:hadRole :home ;
         prov:entity {CATALOG} ; 
     ] ;
. 

We are trialling a series of Catalogue Roles in this vocab: https://data.idnau.org/v/vocab/vcb:cat-roles.

Would the use of qualified isPartOf roles be helpful here?

rob-metalinkage commented 2 months ago

Why not just use PROV natively?. Define subclasses of prov:Activity for federation. As a profile of PROV which can be used in a formal profile of DCAT. This way you get time for free if you need to know when.

bertvannuffelen commented 2 months ago

I like to bring the discussion back to the question: what is the semantics behind dcat:catalog? (also read issue #1598 for another perspective on the semantics of this property.)

Lets first define the proper use of the existing properties, before discussing extending DCAT.

riccardoAlbertoni commented 1 month ago

Managing the harvest catalog might open the door to more elaborate requirements than those considered by DCAT 2 and DCAT 3, i.e., distinguishing between harvested and non-harvested catalogs, which was not a requirement at the time the property was specified. [see https://github.com/w3c/dxwg/issues/182 and then, https://github.com/w3c/dxwg/issues/1156] As a source of further context, we might refer to the DCAT_AP discussion https://github.com/SEMICeu/DCAT-AP/issues/292

I am marking this as future work.