- From: Andrea Perego via GitHub <sysbot+gh@w3.org>
- Date: Mon, 28 Feb 2022 20:56:02 +0000
- To: public-dxwg-wg@w3.org
@andreasgeissner said: > 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 https://github.com/w3c/dxwg/issues/1469 is exactly the solution i imagined. Thanks again! If I'm not mistaken, the two main points you raise concern: 1. `dcterms:hasPart` vs `dcat:catalog` 2. `dcterms:hasPart` vs `dcterms:isPartOf` About point (1), `dcterms:hasPart` and `dcat:catalog` have different semantics, as said in https://github.com/w3c/dxwg/issues/1469 . In particular, `dcat:catalog` (as well as `dcat:dataset` and `dcat:service`) is meant to link a set (`dcat:Catalog`) to one of its elements (another `dcat:Catalog`). Therefore, it cannot be used to link nested catalogues, whereas `dcterms:hasPart` can be used for that purpose. BTW, you can find existing examples of this use in DCAT-AP and DCAT-AP-JRC - e.g.: https://ec-jrc.github.io/dcat-ap-jrc/#catalogue-collection About point (2), `dcterms:hasPart` is included in DCAT because the direction of its sub-properties is from a catalogue to the listed resources. However, `dcterms:isPartOf` can also be used in addition to (but not to replace) `dcterms:hasPart` - about this, see [ยง7. Use of inverse properties](https://w3c.github.io/dxwg/dcat/#inverse-properties). In case you have reasons to think it should be the other way round, I suggest you contribute them to https://github.com/w3c/dxwg/issues/1469 -- GitHub Notification of comment by andrea-perego Please view or discuss this issue at https://github.com/w3c/dxwg/issues/1454#issuecomment-1054653629 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 20:56:04 UTC