Re: Inverse properties in JSON-LD

Markus,

This looks great; thanks for doing this! And I agree. I've written a
more thorough reply in the Github issue [1].

Cheers,
Niklas

[1]: https://github.com/json-ld/json-ld.org/issues/221#issuecomment-14326786

On Fri, Mar 1, 2013 at 8:22 PM, Markus Lanthaler
<markus.lanthaler@gmx.net> wrote:
> 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 Saturday, 2 March 2013 11:27:21 UTC