W3C home > Mailing lists > Public > public-linked-json@w3.org > July 2013

Re: Blank nodes as predicates [was Re: Input needed from RDF group on JSON-LD skolemization]

From: David Booth <david@dbooth.org>
Date: Mon, 15 Jul 2013 10:57:45 -0400
Message-ID: <51E40DE9.5020609@dbooth.org>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:38 UTC