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

On 4/13/20 3:00 PM, Robert Sanderson wrote:
> 
> 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?

Yes, exactly.

David

> 
> Rob
> 
> On Sun, Apr 12, 2020 at 7:06 AM Melvin Carvalho 
> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
> 
> 
> 
>     On Sun, 12 Apr 2020 at 15:34, David Booth <david@dbooth.org
>     <mailto: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

Received on Monday, 13 April 2020 20:58:13 UTC