> @riccardoAlbertoni said: > > > Still to decide if other properties mentioned in the inverse property section (e.g., `dcat:hasVersion` and `prov:generated`) need to be removed as well. > > I created PR #1413 to deal with `dcat:hasVersion` / `dcat:isVersionOf`. The proposal implemented there is to keep `dcat:hasVersion` in §6, and move instead `dcat:isVersionOf` to the section on inverse properties. > > The rationale is that this reflects the PAV approach, where only `pav:hasVersion` (≡ `dcat:hasVersion`) is defined, and not its inverse. Moreover, `pav:hasVersion` is the superproperty of `pav:hasCurrentVersion` (≡ `dcat:hasCurrentVersion`), which needs to be specified to link the abstract resource to the current version of the actual resource. For this reason, `dcat:hasCurrentVersion` should be kept in §6; in such a case, its superproperty (`dcat:hasVersion`) cannot be dropped from §6. That was one of the things into which I was stuck. I thought of defining `dcat:isVersionOf` as the inverse of `pav:hasVersion`, but I was not much convinced of such a solution. Your proposal sounds more reasonable to me. A concern is that the metadata of the abstract resources must be updated each time a new version is added. However, I am not sure there is a way to avoid this, even if we had chosen `dcat:isVersionOf` instead of `dcat:hasVersion`, we would have needed to update the `dcat:hasCurrentVersion`. The solution you have implemented which mimics the directions used by PAV looks like the proper equilibrium. -- GitHub Notification of comment by riccardoAlbertoni Please view or discuss this issue at https://github.com/w3c/dxwg/pull/1410#issuecomment-942504298 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-configReceived on Wednesday, 13 October 2021 16:58:14 UTC
This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:28:37 UTC