-
Notifications
You must be signed in to change notification settings - Fork 47
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
Applying PROV's lightweight approach for DCAT inverse properties #1336
Comments
It is a bit clunky, but there is the PROV precedent. |
I was shocked to read that approach in a W3C recommendation. |
They implicitly reserved the keywords without actually implementing them. |
A draft section about inverse properties is available at the link [1] and has been discussed at the last DXWG plenary. The meeting minutes [2] register the rationale behind the section and the so-far positive reactions from the group. Are there any remarks or objections to the approach described in the section? We want to make sure we are all on the same page about the general approach, which is largely inspired by the PROV's lightweight solution, then refine the section incrementally, considering what inverse properties are missing in the current list and the remaining open issues in GitHub about the inverse properties. [1] https://w3c.github.io/dxwg/dcat/#inverse-properties |
As no objections have been raised so far on the adopted approach, I propose we close this issue. |
Discussions on adding inverse DCAT properties have appeared in distinct issues (e.g., #1322 and #1335).
Some people feel DCAT should recommend only one direction of properties, essentially to avoid extra efforts when maintaining and consuming the metadata. Others argue that inverse properties are not that difficult to maintain.
A middle-out option would be supporting inverse properties with a "lightweight approach" such as the one adopted by PROV-O (https://www.w3.org/TR/prov-o/#inverse-names).
The idea is to avoid inverse properties (unless grounded explicitly by use cases). But rather, to claim in the DCAT Appendix the name of the inverse properties to ensure interoperability in case any specific application needs to use the non-recommended inverse properties.
In a recent DCAT teleconference, we started discussing whether this strategy is suitable for DCAT, and we agreed on following/exploring the PROV approach for inverse properties (see https://www.w3.org/2021/03/17-dxwgdcat-minutes#r02).
What do group members and contributors think about this approach?
The text was updated successfully, but these errors were encountered: