Re: [dxwg] DCAT removing inverse properties from Vocabulary Specification (#1410)

> @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 using your GitHub account

Sent via github-notify-ml as configured in

Received on Wednesday, 13 October 2021 16:58:14 UTC