Closed lanthaler closed 5 years ago
In most cases, you would probably want to "overwrite" the label and description of a reverse property. That feature request has been tracked as issue #1.
Ruben and I discussed an alternative design which defines inverse properties on the fly; either using owl:inverseOf or adding something like that to Hydra if we want to avoid pulling in OWL as a dependency. The advantage of such an approach is that it would also work with a property path:
{
"@type": "PropertyConstraint",
"property": "schema:award",
"propertyPath": [ { "inverseOf": "schema:author" } ],
"required": true
}
This would, e.g., make it possible to point from a Person to the awards it won for its CreativeWorks:
schema:Person <--[schema:author]-- schema:CreativeWork --[schema:award]--> "Award"
PROPOSAL: Describe how reverse properties can be used in SupportedProperty
/PropertyConstraint
either using owl:inverseOf
or something like hydra:reverseOf
(reverse because that's the term that it's used in JSON-LD and RDFa).
There was neither activity nor consensus regarding this issue. In addition, reverse and other more complex constructs makes it difficult to implement in thin clients. I'm closing it as there are more urgent matters ahead. It could be reopened in future if necessary and the spec is stable and stuffed with features.
Why is this labelled as "obsolete"?
I think that lack of activity in this matter rendered this issue either abandoned or obsolete. Also as stated, while it is relatively easy to have more complex constructs like reverse (or transitive, etc.), it makes implementing clients a nightmare. After review of all issues, we decided to mark some of them with obsolete label and agreed to close them on the last call.
For the record - and I think this will perhaps come up again: I disagree that this would make "implementing clients a nightmare". But I unfortunately can not spend time on this.
For the record - and I think this will perhaps come up again:
No problem with that - if some real case pops out, we can discuss it.
I disagree that this would make "implementing clients a nightmare".
It will. RDF does not make things easy. While we try to mention in the spec to explicitly type resources we we can hookup correct logic in the client, we won't be able to enforce that rule and the client needs to understand RDF basics including range/domain rules. I wouldn't like to use any advance reasoning mechanism within the client, thus implementing basics is quite complicated.
Throwing @reverse
, which is conceptually equal to owl:inverseOf
will make things even more complicated.
Unless JSON-LD API resolves it to some simple form, taking special care of @reverse
complicate things from my perspective.
_This was raised by Gregg Kellogg:_