Re: inverse properties in JSON-LD

Hi!

I have a pressing need for something like this. I suggested a similar
mechanism, using @rev in a previous post to this list [1].

While that suggestion was a (kind of) @rev equivalent to RDFa, I've
also been thinking about the merits of what Pierre-Antoine suggests.
It's certainly cleaner, and a better way for adapting "regular" JSON
to a linked data structure. (By "regular" I mean JSON without any
explicit JSON-LD syntax beyond "@context" – using non-CURIE terms,
keyword aliases, default language and coercion for everything.)

The most important reason for why I need this is because I have
avoided modeling explicit reverse properties in the legal information
project. This is because the direction of a relation, for example
"modifies", embodies an authoring perspective. While a defined
reverse, "modifiedBy", would be semantically correct, it isn't useful
in our domain for creating data, as (legal) documents are changed by
other documents, published later in time.

When using RDF libraries to process and display data, this is not a
problem, since I can extract relevant contextual data for a document
(including partial data from documents linked by, and *linking to* the
current document), and navigate this graph in any direction.

*However*, when exposing this data as JSON, I need to "fold" the
extracted graph of relevant data about a document into a tree. Hence I
need to have reverses for things linking *to* this current document.
Also, it *may* actually be useful for consumers of this data to
understand that certain parts are actually "things referring to the
current thing". (And I mean "understand" in a rather mechanical way,
not in the way one can get the underlying linked data graph by
grasping the finer details of @context.) I therefore currently use a
"@rev" key to explicitly express this.

Although our data and services are all in swedish, so examples might
not give you much more insight, I am quite happy to give you an
example from our *demo* service (no guarantees for uptime nor
stability).

This is data about the Swedish Freedom of the Press Act
("Tryckfrihetsförordning") as Turtle:

    http://service.demo.lagrummet.se/publ/sfs/1991:1469/data.ttl

and JSON-LD:

    http://service.demo.lagrummet.se/publ/sfs/1991:1469/data.json

You can also view it in our experimental "API UI" (incoming relations
are at the bottom):

    http://service.demo.lagrummet.se/ui/#/publ/sfs/1991:1469/data.json

(For the interested, the Turtle above which includes "relevant
contextual data" is at 549 triples, while the raw RDF source at
http://rinfo.demo.lagrummet.se/publ/sfs/1991:1469/rdf contains 264
triples.)

In conclusion, I believe that my "@rev" suggestion takes care of the
general case, in an explicit but not too overly complex manner. The
coercion mechanism that Pierre-Antoin presents has a definitive merit
in that it enables "regular" JSON. From my perspective, reverse
relations *are* advanced (they relate to the graph nature for which
there is no natural dimension in JSON). In our service above the
"@rev" makes this explicit, hopefully for the benefit of consumers.
(At least it was easier for me to write the UI without *needing* the
@context, since I could directly pick out the "incoming parts".) In
any case my primary need can be solved by either of these
alternatives.

Best regards,
Niklas

[1]: http://lists.w3.org/Archives/Public/public-linked-json/2011Sep/0007.html



On Mon, Oct 3, 2011 at 1:17 PM, Ivan Herman <ivan@w3.org> wrote:
> Hi pa,
>
> I guess this is the analogue of the usage of @rev in RDFa.
>
> There has been lots of discussion in the RDFa WG at some point whether @rev is necessary at all. The completely anecdotical evidence (ie, not based on hard crawl results, for example) is that @rev is very rarely used in deployed RDFa. As Manu pointed out, the JSON community is not the same as the Web developers' community but, nevertheless, this may be an indication that the take up of such a feature would not be big...
>
> On the other hand, the fear I have is that, while the behaviour of this is pretty clear to you or me or Manu or people who think essentially in triples, it might be fairly confusing for those who come from a different direction:-( Such a confusion could backfire on us.
>
> Of course, we could have a separate 'obscure^H^H^H^H^H^H^Hadvanced features' or something in the document:-)
>
> Ivan
>
>
> On Oct 3, 2011, at 12:57 , Pierre-Antoine Champin wrote:
>
>> Hi all,
>>
>> is there any plan in JSON-LD to provide a way to declare an *incoming*
>> arc, for example
>>
>>  {
>>    "@subject": "#me",
>>    "http://xmlns.com/foaf/0.1/member": {
>>       "@inverse": "http://univ-lyon1.fr/#this"
>>    }
>>  }
>>
>> producing the following triple
>>
>>  <http://univ-lyon1.fr/#this>
>>     <http://xmlns.com/foaf/0.1/member> <#me> .
>>
>>
>> This would prove very useful with a coercion rule, as I would (much!)
>> rather write:
>>
>>  {
>>    "@context": {
>>      "foaf:": "http://xmlns.com/foaf/0.1/",
>>      "memberOf": "http://xmlns.com/foaf/0.1/member",
>>      "@coerce": {
>>        "@inverse": "memberOf"
>>      }
>>    }
>>
>>    "@type": "foaf:Person",
>>    "foaf:name": "Pierre-Antoine Champin",
>>    "memberOf": [
>>      "http://univ-lyon1.fr/#this", "http://liris.cnrs.fr/#this"
>>    ]
>>  }
>>
>> (with the context possibly kept off-band) than write:
>>
>>  {
>>    "@context": {
>>      "foaf:": "http://xmlns.com/foaf/0.1/",
>>      "@coerce": {
>>        "@iri": "foaf:member"
>>      }
>>    }
>>    "@subject": [
>>      {
>>        "@subject: "_:me",
>>        "@type": "foaf:Person",
>>        "foaf:name": "Pierre-Antoine Champin",
>>      },
>>      {
>>        "@subject: "http://univ-lyon1.fr/#this",
>>        "foaf:member": "_:me"
>>      },
>>      {
>>        "@subject: "http://liris.cnrs.fr/#this",
>>        "foaf:member": "_:me"
>>      }
>>    ]
>>  }
>>
>>
>> pa
>>
>>
>> PS: as I see it, "@inverse" would imply "@iri", as the subject of a
>> triple has to be an IRI in RDF.
>>
>
>
> ----
> Ivan Herman, W3C Semantic Web Activity Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153
> PGP Key: http://www.ivan-herman.net/pgpkey.html
> FOAF: http://www.ivan-herman.net/foaf.rdf
>
>
>
>
>
>
>

Received on Monday, 3 October 2011 14:06:01 UTC