Re: A library that converts regular JSON to JSON-LD

You can pipe your JSON through jq to add the context.

Le lun. 13 avr. 2020 à 21:02, Robert Sanderson <azaroth42@gmail.com> a
écrit :

>
> I don't understand the rationale behind this, I'm afraid. Making JSON into
> JSON-LD is just a matter of associating a context with the JSON, either in
> the data with the @context key, or at the protocol level with a link
> header.  So a unix utility to make JSON into JSON-LD is ... cp :)
>
> Is what's needed some code that traverses a JSON document (or set of
> documents) and determines all of the possible paths, to then build a
> skeleton context document, such that it's a matter of associating the right
> predicate with the particular key or path?  E.g. a helper tool for context
> creators?
>
> Rob
>
> On Sun, Apr 12, 2020 at 7:06 AM Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>>
>>
>> On Sun, 12 Apr 2020 at 15:34, David Booth <david@dbooth.org> wrote:
>>
>>> On 4/12/20 6:13 AM, Melvin Carvalho wrote:
>>> > On Sat, 11 Apr 2020 at 21:23, David Booth wrote:
>>> >     On 4/11/20 11:54 AM, Melvin Carvalho wrote:
>>> >      > Is there are library that converts simple json (think just a
>>> flat
>>> >      > object of key value pairs) Into JSON-LD
>>>  > [ . . . ]
>>> >     I have not seen one yet, but it's good idea.  In particular, the
>>> >     algorithm needs to recursively traverse the JSON tree and keep
>>> track of
>>> >     nesting to generate an @context that will keep nested properties
>>> of the
>>> >     same name distinct.  See the discussion here:
>>> >     https://github.com/w3c/EasierRDF/issues/29
>>> >
>>> > [ . . . ]
>>> > Does the algorithm specifically need to traverse the tree to
>>> distinguish
>>> > foo from baz/foo
>>> >
>>> > I can see why you may want to in JSONPath for example, but given that
>>> > JSON predicates are "just names", would you specifically need that
>>> > prefix in a name, or is it a nice to have?
>>>
>>> It depends on the application.  Some will need to distinguish foo from
>>> baz/foo and some will not.
>>>
>>> As one real-life example, in the case of FHIR RDF the distinction was
>>> important, which is why we were not able to use JSON-LD 1.0 in the
>>> original design of FHIR RDF (because 1.0 lacked the necessary nested
>>> context feature) but we are now able to take advantage of JSON-LD 1.1
>>> (which added that feature).
>>>
>>> The reason I think the distinction between foo and baz/foo is important
>>> to retain in a general purpose algorithm is merely because it is much
>>> easier to forget the distinction between foo and baz/foo later -- or
>>> treat baz/foo as a subproperty of foo -- than it is to re-create that
>>> distinction if it is lost by the algorithm.  If a general purpose
>>> algorithm provides an option for ignoring the distinction, then that's
>>> great, but I think the default should be to retain the distinction.
>>> Make sense?
>>>
>>
>> Thanks for the explanation.  It makes a bit of sense.  I think seeing an
>> example from FHIR of why it's useful may be an eye opener.
>>
>> So the mind set I am in right now think of JSON as key value pairs.  When
>> I consider the key, my thought is "it's just a name", or "it's just a
>> string of characters".  This is in line with my understanding of JSON.  ie
>> it has the key itself has no special meaning whether or not it's nested.
>>
>> There's probably a few things I havent considered.  But that's my thought
>> process in at moment.  Id be happy to try and expand that thought process,
>> tho!
>>
>>
>>> David Booth
>>>
>>>
>
> --
> Rob Sanderson
> Semantic Architect
> The Getty Trust
> Los Angeles, CA 90049
>