@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.

About property prov:generated (not included in §6), it seems to be used only in the examples. Should this be the case, the fix may be limited to ensuring that all the examples use it in addition to prov:wasGeneratedBy - see, e.g., Example 45 and Example 48.

Example 54 uses an inverse property dcterms:references but not dcterms:isReferencedBy, I wonder if we should add
:d33937.owl dcterms:isReferencedBy :d33937 to make the example more consistent with DCAT policies on inverse property

@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.

@riccardoAlbertoni said:

Example 54 uses an inverse property dcterms:references but not dcterms:isReferencedBy, I wonder if we should add :d33937.owl dcterms:isReferencedBy :d33937 to make the example more consistent with DCAT policies on inverse property

Makes sense to me.

About property prov:generated (not included in §6), it seems to be used only in the examples. Should this be the case, the fix may be limited to ensuring that all the examples use it in addition to prov:wasGeneratedBy - see, e.g., Example 45 and Example 48.

Done.

@riccardoAlbertoni said:

Example 54 uses an inverse property dcterms:references but not dcterms:isReferencedBy, I wonder if we should add :d33937.owl dcterms:isReferencedBy :d33937 to make the example more consistent with DCAT policies on inverse property

Makes sense to me.

As discussed, we are going to postpone this, as it is possible that dcterms:references is not the property we want there. In case it was the right property, the addition of dcterms:references can be done when dealing with issue #1416.

Thanks, @riccardoAlbertoni . I think we can merge this PR.