Re: Inverse properties in JSON-LD

Hi David!

As Markus says, I have been very interested in this for quite some
time. I'm short on time right now, so I'll be brief.

On Wed, Feb 20, 2013 at 5:04 PM, David Rogers <david.rogers@bbc.co.uk> wrote:
> Hi Markus,
>
> I understand your example now, and it makes sense. I think the @rev syntax
> would work well for us.
>
> We would need a predicable way of generating inverse property names, so
> presumably we could prefix properties with '^' to indicate inverse for our
> APIs? And simply make a reference to this in the context. It would therefore
> no longer be micro-syntax, simply a convention in our APIs.

I have suggested two alternatives in the past (I only found some notes
about this in #84 [1], but I've written more about it on the mailing
list before). One is what Markus outlined, the other is to use the
`@rev` keyword as a "reverse relations container". E.g:

  {
    "@context": {
      "children": { "@rev": "parent", "@type": "@id" }
    },
    "@id": "http://dbpedia.org/resource/John_Lennon",
    "name": "John Lennon",
    "born": "1940-10-09",
    "@rev": {"parent": "http://dbpedia.org/resource/Sean_Lennon"}
  }

> More responses inline....
>
> Many thanks,
>
> Dave
>
> On 20/02/2013 15:48, "Markus Lanthaler" <markus.lanthaler@gmx.net> wrote:
>
>> 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:
>>
>> https://github.com/json-ld/json-ld.org/issues/221
>>
>> 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
>> there.
>>
>>
>>> 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
>> path.
>>
>>
>>> 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? :-)
>>
>
> We're building a set of APIs at the BBC which are powered by CONSTRUCT
> queries on our triple store. We want to provide this data in ways that are
> more familiar to developers not so familiar with RDF, whilst not losing the
> 'linked' aspect of the data. JSON-LD was the best fit.

That's *exactly* how I've been creating simple APIs upon RDF stores
(and for the query syntax, aligning it with the Linked Data API), for
the swedish legal information system (see e.g. the JSON underneath
this one-page-app [2]). Reverse relations where paramount in making it
work. It is the one thing I've been missing in JSON-LD. It's really
cool to hear that you are applying JSON-LD in the same way!

Since I thus need to create nested trees ("rooted" in the current
resource), I've needed to build that from a flattened compacted form,
and in doing so also adding these reverse relations using "null"-keys.
Alas, that means that lots of data is dropped when parsing it (since
null-keys aren't probed for nested data; which of course is good and
intentional by default).

We are also currently using JSON-LD as a storage and service format at
the National Library of Sweden. I've recently come across certain
situations where the lack of a `@rev` feature (at least in the first
form illustrated by Markus) may turn out to be a real problem (since
this is a case of primary storage (and editing) and not just a
packaging of data for convenient APIs). So I am very motivated to
pursue this need further.

Cheers,
Niklas

[1]: https://github.com/json-ld/json-ld.org/issues/84
[2]: http://service.demo.lagrummet.se/ui/

>>
>>> 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": [
>>     "http://json-ld.org/contexts/person.jsonld",
>>     {
>>       "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
>> details.
>
> This could be useful, but for us, it still involves quite a detailed
> understanding of the JSON-LD syntax in order to interpret the data in a
> simple JSON way. For the majority of our data consumers, we do not
> expect/want them to use JSON-LD parsers.
>
>>
>>
>>> 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
>> @markuslanthaler
>>
>
>
> http://www.bbc.co.uk/
> This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
> If you have received it in error, please delete it from your system.
> Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately.
> Please note that the BBC monitors e-mails sent or received.
> Further communication will signify your consent to this.
>
>

Received on Wednesday, 20 February 2013 16:38:20 UTC