10000 DCAT removing inverse properties from Vocabulary Specification by riccardoAlbertoni · Pull Request #1410 · w3c/dxwg · GitHub
[go: up one dir, main page]

Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DCAT removing inverse properties from Vocabulary Specification #1410

Merged
merged 9 commits into from
Oct 19, 2021

Conversation

riccardoAlbertoni
Copy link
Contributor
@riccardoAlbertoni riccardoAlbertoni commented Oct 1, 2021

This PR removes the properties dcat:next and dcterms:isReplacedBy from the Vocabulary specification (section 6).

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.

Preview: https://raw.githack.com/w3c/dxwg/DCAT-adjustementForInverseProperties/dcat/index.html

Diff: https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fw3c.github.io%2Fdxwg%2Fdcat%2F&doc2=https%3A%2F%2Fraw.githack.com%2Fw3c%2Fdxwg%2FDCAT-adjustementForInverseProperties%2Fdcat%2Findex.html

Addressing open issue in #1410
@andrea-perego
Copy link
Contributor

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

@andrea-perego
Copy link
Contributor

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.

@riccardoAlbertoni
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@andrea-perego
Copy link
Contributor

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

@riccardoAlbertoni
Copy link
Contributor Author

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.

@andrea-perego
Copy link
Contributor

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

@dr-shorthair dr-shorthair merged commit 350786f into gh-pages Oct 19, 2021
@dr-shorthair dr-shorthair deleted the DCAT-adjustementForInverseProperties branch October 19, 2021 23:09
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0