W3C home > Mailing lists > Public > public-linked-json@w3.org > February 2013

RE: Inverse properties in JSON-LD

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Wed, 20 Feb 2013 16:48:55 +0100
To: "'David Rogers'" <david.rogers@bbc.co.uk>
Cc: <public-linked-json@w3.org>
Message-ID: <026c01ce0f81$cad4bae0$607e30a0$@lanthaler@gmx.net>
Hi David,

You didn't send the response to the mailing list. Anyway. I've created an
issue in our issue tracker for this feature request and already added our
conversation there:


If you don't mind we could move the discussion there to keep everything
organized in one place.

I will answer the rest of your mail inline below.

> Many of the ontologies we work with do not have inverse properties
> defined
> for every property, so there is no correct way of expressing the
> inverse as
> a separate property.

I think I wasn't clear enough in my example. What I meant was that the
context definition would define a term and is mapped to its reverse IRI.

    "children": { "@rev": "http://example.com/parent", "@type": "@id" }  

Children here doesn't have its own IRI. It is just a term that you can then
use in your data as if there would exist an inverse property. See the @rev
(for reverse) in the context definition, normally there would be an @id

> Additionally, we are working in a context where we want our JSON-LD to
> have
> a predictable tree structure (allowing the JSON-LD to easily be parsed
> and
> used as simply JSON). In this circumstance, it is not practical to
> express
> the triple the 'other way around', as this requires a deeper level of
> understanding of the data structure so that the data consumer can
> 'jump'
> from one @id to it's corresponding @id elsewhere in the JSON-LD.

Yes, I understand, that's often a requirement to provide a smooth upgrade

> Inverse properties are (currently) the
> only thing causing us to break the JSON-LD syntax 

I'm curious. May I ask how and for what you use JSON-LD? :-)

> As an example, let us assume that the 'children' property has not been
> defined. The following has been suggested:
> {
>   "@context": "http://json-ld.org/contexts/person.jsonld",
>   "@graph": [{
>     "@id": "http://dbpedia.org/resource/John_Lennon",
>     "name": "John Lennon",
>     "born": "1940-10-09"
>   }, {
>     "@id": "http://dbpedia.org/resource/Sean_Lennon",
>     "parent": "http://dbpedia.org/resource/John_Lennon"
>   }]
> }
> To use this data structure requires, in effect, a 'search' through the
> graph/map to discover references to
> "http://dbpedia.org/resource/John_Lennon" in order to discover his
> children.

Depending on your exact data you could also use the @index feature which
allows you to create maps.

  "@context": [
      "persons": { "@id": "http://...", "@container": "@index" }
  "@id": "http://example.com/addressbook",
  "persons": {
    "John_Lennon": {
      "@id": "http://dbpedia.org/resource/John_Lennon",
      "name": "John Lennon",
      "born": "1940-10-09"
    "Sean_Lennon": {
      "@id": "http://dbpedia.org/resource/Sean_Lennon",
      "parent": "http://dbpedia.org/resource/John_Lennon"

I simplified the keys to, of course you could also use the full IRI as key.
See http://json-ld.org/spec/latest/json-ld-syntax/#data-indexing for

> Using inverse properties:
> {
>   @id": "http://dbpedia.org/resource/John_Lennon",
>   "name": "John Lennon",
>   "born": "1940-10-09",
>   "^parent": "http://dbpedia.org/resource/Sean_Lennon"
> }
> Considerably simplifies the data, and crucially, no searching is
> required to
> use data structure. In fact "^parent" in itself can be treated as a
> simple
> property, so long as the developer is familiar with the fact that the
> micro-syntax '^' (or alternative symbol) means inverse.

I agree. It's definitely a useful feature and it has come up a number of
times. We just haven't come around to include it in JSON-LD 1.0 yet. As
already said, more than likely we would not use a micro-syntax as you
propose but introduce a dedicated keyword for the feature (@rev, @reverse or
something similar). The other thing that we would need to work out is how
it's going to be supported in the various algorithms (it should round-trip
when expanding/compacting, flattening seems to be simpler).

We are all very busy stabilizing JSON-LD at the moment and bringing the
specs in shape for last call. If you would like to take a stab and see how
such a feature would work with the various algorithms we could certainly
consider it. I know that at least Niklas Lindström is very interested in
this feature.

Markus Lanthaler
Received on Wednesday, 20 February 2013 15:49:27 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:36 UTC