Re: [dxwg] dcterms:hasPart in the context of nested Catalogs (#1454)

Thanks for the detailed response, @andrea-perego . I had typed but not yet proofread a lengthy text to clarify my concern (which is copied below in case you need information out of it for the new issue), but Issue #1469 is exactly the solution i imagined. Thanks again!

----
The issue I wanted to have addressed is indeed the definition of dcterms:hasPart.

I think you understood correctly what I was trying to do (modelling the metadata contents of our repository in DCAT, and clearly stating the hierarchy of all catalogs and which dataset is listed in which (sub-)catalog). But I’m not sure that I correctly understand your response or that you saw the exact issue that I was trying to get across, so let me try to re-formulate. Sorry for the bother.

For one, is there any specific reason that you used dcterms: isPartOf instead of dcterms:hasPart in your model?

Secondly, if I go with the left route of your model:
```
:TUDarmstadt a dcat:Catalog ; dcterms:hasPart :FB16 .
:FB16 a dcat:Catalog ; dcterms:hasPart :IMS .
:IMS a dcat:Catalog ; dcterms:hasPart :DFG_AMOS .
:DFG_AMOS a dcat:Catalog ; dcat:dataset :Supp_Data1, :Supp_Data2 ;
```

From my understanding, that would be the same as if I used dcat:catalog instead of dcterms:hasPart
```
:TUDarmstadt a dcat:Catalog ; dcat:catalog :FB16 .
:FB16 a dcat:Catalog ; dcat:catalog :IMS .
:IMS a dcat:Catalog ; dcat:catalog :DFG_AMOS .
:DFG_AMOS a dcat:Catalog ; dcat:dataset :Supp_Data1, :Supp_Data2 .
```

Which means that:
:TUDarmstadt is a dcat:Catalog with one listed dcat:Resource (:FB16)
:FB16 is a dcat:Catalog with one listed dcat:Resource (:IMS)
:IMS is a dcat:Catalog with one listed dcat:Resource (:DFG_AMOS)
:DFG_AMOS is a dcat:Catalog with two listed dcat:Resources (:Supp_Data1, :Supp_Data2)


This understanding is based on the following definitions (I’m quoting the definitions from https://www.w3.org/TR/2022/WD-vocab-dcat-3-20220111/)

dcterms:hasPart: An item [my addition: dcat:Resource] that is listed in the catalog. [only in the context of dcat:Catalog, for dcat:Dataset it is the more generic definition]
dcat:dataset: A collection of data that is listed in the catalog.
dcat:service: A site or end-point that is listed in the catalog.
dcat:catalog: A catalog that is listed in this catalog.

With the Usage note for dcterms:hasPart stating “This is the most general predicate for membership of a catalog. Use of a more specific sub-property is recommended when available. “.

I assumed dcterms:hasPart is suggested to be used if you were to create your own subclass of dcat:Resource and wanted to list an instance of that subclass in the catalog. But if you used it with an existing subclass of dcat:Resource (dcat:Dataset, dcat:DataService, and dcat:Catalog) it would have the same meaning as dcat:dataset, dcat:service, and dcat:catalog. After all, the more specific definitions are only recommended.

What I want to show is that :TUDarmstadt is a dcat:Catalog that contains a number of datasets. There are certain subcatalogs that only contain a subselection of those datasets. I think that would be possible with the dcat:Dataset interpretation of dcterms:hasPart, but not the dcat:Catalog interpretation of dcterms:hasPart, because that one is identical to dcat:catalog. 

The point is was trying to make: I think it would be good to have, for dcat:Catalog, properties that cover both interpretations of dcterms:hasPart. Or make it clear that these interpretations exist, if they do.

The best “other” option I was able to think of so far to create some relation between the dcat:Catalogs would be:
```
:TUDarmstadt a dcat:Catalog ;
 dcat:catalog :FB16 ;
dcat:dataset :Supp_Data1, :Supp_Data2 .

:FB16 a dcat:Catalog ; 
dcat:catalog :IMS ;
dcat:dataset :Supp_Data1, :Supp_Data2 .

:IMS a dcat:Catalog ; 
dcat:catalog :DFG_AMOS ;
dcat:dataset :Supp_Data1, :Supp_Data2 .

:DFG_AMOS a dcat:Catalog ; 
dcat:dataset :Supp_Data1, :Supp_Data2 .
```

However, this would mean that the lower level catalogs are also listed in the higher level catalogs. This is not what you would see in most views and not what is seen the OAI-PMH “distributions”. Also, it would mean then we would have a heap of dcat:Catalogs and not a big one with subcatalogs, at least not explicitly. I don’t like that with regard to the dcat:Catalog usage note “A Web-based data catalog is typically represented as a single instance of this class.”. Finally, it does not get the message across that content listed in the lower level catalogs is by default also listed in the higher level ones.


-- 
GitHub Notification of comment by andreasgeissner
Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1454#issuecomment-1054218321 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Monday, 28 February 2022 12:42:22 UTC