- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Sat, 13 Jul 2013 15:54:36 -0400
- To: public-linked-json@w3.org
On 07/13/2013 02:23 PM, Markus Lanthaler wrote: > On Saturday, July 13, 2013 12:41 AM, David Booth wrote: >> On 07/12/2013 06:18 AM, Markus Lanthaler wrote: >>> On Friday, July 12, 2013 5:00 AM, David Booth wrote: >>>> On 07/10/2013 10:18 AM, Markus Lanthaler wrote: >>>>> What if I would have some (out-of-band) knowledge that tells me >>>>> that >>>>> >>>>> _:b2 rdfs:subPropertyOf > <http://example.com/someTheClientUnderstands1> . >>>>> _:b2 rdfs:subPropertyOf > <http://example.com/someTheClientUnderstands2> . >>>> It is not possible in RDF to do that, because the blank node label _:b2 >>>> has no meaning outside of the original graph. There is no way, from >>>> outside of that graph, to refer to _:b2 by name. It has no name >>>> outside of the original graph. >>> Since I am the client and I have out-of-band knowledge and I am the one >>> processing the graph I can simply inject that knowledge into the graph >>> before processing it. So it's certainly possible. How could someone > possibly >>> prevent that? >> If you are using standard tools then there is no way to inject a >> statement about _:b2 into the graph before processing it, because _:b2 >> has no name that you can reference. A standard JSON-LD extended-RDF >> parser would take JSON-LD as input and produce extended RDF like this: >> >> ... >> [] [] true . >> [] [] false . > In JSON-LD there's no way to have a property mapped to an unlabeled blank > node. If you map it to a blank node, it will be mapped to a blank node > identifier. > > >> The only way, using standard tools, that you could inject the above >> out-of-band knowledge would be to modify the *original* JSON document to >> inject additional JSON properties that would end up being converted to >> RDF using the same blank nodes. > Why's that a problem? > > >> In other words, you would have to: (a) >> parse the document as pure JSON; (b) augment that JSON with your >> out-of-band information;> (c) serialize back to JSON; and finally (d) >> re-parse the result using a JSON-LD extended-RDF parser. > That's trivial in every programming language I know And (a) is often done regardless. All current JSON-LD processor implementations (and for the foreseeable future) reuse existing "pure JSON" parsers before doing anything else. (c) would be unnecessary because the JSON-LD API accepts pre-parsed objects. So the steps would actually be: 1. parse JSON, 2. add out-of-band information, 3. run the result through a JSON-LD extended-RDF processor. In normal operation, you may already be doing 1 and 3. So, it may be common that the only extra step is adding the out-of-band information. In any event, this isn't about something being an elegant solution, it's about making it possible for authors to more easily transition so that they don't opt to avoid transitioning entirely. > > >> That does not sound like an elegant solution. That sounds like a crude >> hack. > So? > > > > -- > Markus Lanthaler > @markuslanthaler > > -- Dave Longley CTO Digital Bazaar, Inc.
Received on Saturday, 13 July 2013 19:55:00 UTC