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

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