- From: David Booth <david@dbooth.org>
- Date: Sun, 12 Apr 2020 09:32:42 -0400
- To: public-linked-json@w3.org
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? David Booth
Received on Sunday, 12 April 2020 13:32:56 UTC