- From: David Booth <david@dbooth.org>
- Date: Mon, 15 Jul 2013 10:57:45 -0400
- To: Markus Lanthaler <markus.lanthaler@gmx.net>
- CC: 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 point is that at the RDF level the labels are arbitrary -- they are not stable or predictable. Unless you have special knowledge of the internals of the parser, then you won't know if a particular blank node will be called _:b1 or _:af3878ed or _:node_009937 or something else. You would have to inject your out-of-band information at the JSON level, *before* conversion to RDF. > >> 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? It is messy. It means that part of the logic is at the JSON level and part of it is at the RDF level, with one depending on the other. It could be done that way, but IMO it would be cleaner and better simply to use relative URIs. That would allow all the processing to be done cleanly at the RDF level. If you are concerned that consumers will erroneously assume that an undocumented URI is stable -- an irresponsible assumption, by the way -- here are a few ways that can be avoided: (a) Serve documentation from the URI, explicitly stating that the URI is unstable. (b) Register a .well-known/UNSTABLE URI suffix whose purpose is to indicate that any URI minted under that URI space is unstable, so that authors can mint relative URIs like .well-known/UNSTABLE/foo that others will know are unstable. (c) Explicitly tell users in the JSON-LD spec that undocumented URIs are likely to be unstable. This of course is common sense to many developers, as it is never wise to rely on an undocumented "feature", but maybe it would help to say it. But really, it seems to me that if a consumer has the ability to complain to an API author if something changes, then the consumer *also* ought to have the ability to RTFM about the author's API instead of making unfounded assumptions about it. David
Received on Monday, 15 July 2013 15:04:52 UTC