Re: Inverse properties in JSON-LD

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.

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.

> 
>> 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:04:53 UTC