reverse link relations (inverse properties)

[elf-pavlik]

currently schema.org tries to address challenges related microdata not having proper support for inverse properties: https://www.w3.org/wiki/WebSchemas/InverseProperties

JSON-LD and RDFa support it nicely with

• @reverse - http://www.w3.org/TR/json-ld/#reverse-properties
• @rev - http://www.w3.org/TR/rdfa-syntax/#iri-object-resolution

RFC 5988 states

The "rev" parameter has been used in the past to indicate that the semantics of the relationship are in the reverse direction. That is, a link from A to B with REL="X" expresses the same relationship as a link from B to A with REV="X". "rev" is deprecated by this specification because it often confuses authors and readers; in most cases, using a separate relation type is preferable.

and HTML5 removes rev https://blog.whatwg.org/the-road-to-html-5-link-relations#rel-author

We could clarify AS2.0 strategy here, for example as:result makes a lot of sense to me as inverse property - relevant schema.org example http://lists.w3.org/Archives/Public/public-vocabs/2014Sep/0112.html

{
    "@id": "https://wwelves.org/__perpetual-tripper/bookmarks/__dfaf8a0fd9",
    "@type": "Bookmark",
    "about": "http://example.net",
    "@reverse": {
        "result": {
            "@id": "https: //wwelves.org/perpetual-tripper/activities/s0dfa091",
            "@type": "BookmarkAction"
        }
    }
}

[jasnell]

Good idea. This can be addressed by defining an "as:resultOf" property that is the reverse of "as:result"

[elf-pavlik]

TimBL recommends not to create in(re)verse properties on vocabulary level https://github.com/mnot/I-D/issues/39#issuecomment-89789736

[evanp]

Welp, 9 years later, I want to re-open this! I have been working on just this problem -- having the inverse property of result. I'd like to revisit the topic and consider how we deal with it.

I made a FEP for the inverse properties of ActivityPub collections (inbox, outbox, followers, following, liked, replies, shares, likes), and I wonder if we should consider it for all properties:

https://codeberg.org/fediverse/fep/src/branch/main/fep/5711/fep-5711.md

[trwnh]

i'm not 100% certain about whether inverse/reverse relations should be defined natively using json-ld @reverse or ontologically via owl:inverseOf on a new property, but based on my current understanding it is better to use @reverse

pros of @reverse:

• you don't need to use OWL (or otherwise know that two properties are inverse of each other)
• you end up with a single statement (so you can't have two statements that might drift out-of-sync with each other)

pros of new property that is owl:inverseOf current property:

• ??? maybe you do want 2 statements after all? not sure why though
• ??? maybe you want it to be possible to make conflicting claims? again, not sure why though

example:

{
  "@context": {
    "id": "@id",
    "result": {
      "@id": "https://www.w3.org/ns/activitystreams#result",
      "@type": "@id"
    },
    "resultOf": {
      "@reverse": "https://www.w3.org/ns/activitystreams#result",
      "@type": "@id"
    }
  },
  "id": "https://activity-2.example/",
  "resultOf": "https://activity-1.example/"
}

if you didn't have resultOf defined in your processor's context, then it would look like this (as in the issue description):

{
  "@context": {
    "id": "@id",
    "result": {
      "@id": "https://www.w3.org/ns/activitystreams#result",
      "@type": "@id"
    }
  },
  "id": "https://activity-2.example/",
  "@reverse": {
    "result": "https://activity-1.example/"
  }
}

either way the information you are conveying is a single statement:

<https://activity-1.example/> <https://www.w3.org/ns/activitystreams#result> <https://activity-2.example/> .

if you define a new property you end up with 2 statements which give the same information (redundant with each other):

<https://activity-1.example/> <https://www.w3.org/ns/activitystreams#result> <https://activity-2.example/> .
<https://activity-2.example/> <https://vocab.example/resultOf> <https://activity-1.example/> .