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

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
>
>