RE: Inverse properties in JSON-LD

Hi David,

I've just added the @reverse feature to my JSON-LD processor. Turns out that
it adds surprisingly little complexity to the algorithms.

If you wanna play with it, it is live at my playground:
  http://www.markus-lanthaler.com/jsonld/playground/

Here's a slightly modified version of your initial example:
  http://bit.ly/Xfy5vO


The feature works with index-containers and property generators; obviously
language-maps and type-coercions are not supported since a reverse property
must point to an IRI.

Would love to hear what others think. By a large margin I would prefer
@reverse over property generators.


Have a nice weekend,
Markus



--
Markus Lanthaler
@markuslanthaler




> -----Original Message-----
> From: David Rogers [mailto:david.rogers@bbc.co.uk]
> Sent: Wednesday, February 20, 2013 6:00 PM
> To: Niklas Lindström
> Cc: Markus Lanthaler; public-linked-json@w3.org
> Subject: Re: Inverse properties in JSON-LD
> 
> Hi Niklas!
> 
> I'd add my support for a @rev 'reverse property container'. It seems
> very
> clean.
> 
> As a rule of thumb (from my perspective), any metadata provided in the
> @context is not practically usable by a data consumer who is not
> interested
> the 'LD' part of JSON-LD. Putting the @rev alongside the rest of the
> data
> makes it consistent and usable by anyone. We have added an additional
> restriction to our JSON-LD to help developers use the full IRIs in a
> simple
> way: the @context is simply used as a dictionary for the whole JSON-LD
> response, and is only allowed at the root. We have clear requirements
> for
> predictability of structure, so additional restrictions like this help
> us
> achieve that.
> 
> It's great to see others taking the approach I described in my previous
> email.
> 
> Dave
> 
> On 20/02/2013 16:37, "Niklas Lindström" <lindstream@gmail.com> wrote:
> 
> > 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.
> >>
> >>
> 
> 
> 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 Friday, 1 March 2013 19:23:02 UTC