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

[bertvannuffelen]

In DCAT-AP this issue has been raised on the usage of dcat:catalog. SEMICeu/DCAT-AP#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 . 

• case A1: add :B as value dcat:catalog
• case A2: :B is a part of the aggregated catalogue and all catalogues provided as catalogued resources in B should go in dcat:catalog.

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]

"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]

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]

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]

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//issues/182 and then, https://github.com//issues/1156]
As a source of further context, we might refer to the DCAT_AP discussion
SEMICeu/DCAT-AP#292

I am marking this as future work.