Reversed SupportedProperty

[lanthaler]

_This was raised by Gregg Kellogg:_

JSON-LD has the ability to define terms which, when used as properties, cause a reverse relationship to be asserted. For example:

{
  "@context": {
    ...,
    "isMemberOf": {"@reverse": "member", "@type": "@id", "@container": "@set"}
  }
}

N3 has a similar is xxx of construct, and RDFa has @rev, which all do similar things. The value of these constructs is that it prevents the anti-pattern of creating inverse versions of each property. For example, if I had a sports team with several members, I might describe it as follows:

:49ers a schema:SportsTeam
  schema:member :ColinKaepernick, :FrankGore, ...

When describing each team member, I'd like to use the same predicate to describe the reverse relationship

:ColinKaepernick a schema:Person;
  is schema:member of :49ers .

However, SupportedProperty requires that I define a property for each of these, particularly when it describes a Link or has operations. It might be nice to be able to define a SupportedProperty to be reversed, such as the following:

[ a hydra:SupportedProperty;
  hydra:property schema:member;
  hydra:readonly true;
  hydra:writeonly false;
  hydra:reversed true
]

Or, perhaps use something like hydra:reversedProperty. That way, if schema:Person was a hydra:Class, it could describe properties that appear in the lexical form within that entity. This would also be a good use of LDF, where an associated pattern would have the predicate and object values specified and wild-card the subject.

[lanthaler]

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.

[lanthaler]

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"

[lanthaler]

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

[alien-mcl]

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.

[akuckartz]

Why is this labelled as "obsolete"?

[alien-mcl]

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.

[akuckartz]

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.

[alien-mcl]

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.