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

On 07/09/2013 05:27 PM, Markus Lanthaler wrote:
> On Tuesday, July 09, 2013 10:28 PM, David Booth wrote:
>> Right, but you are assuming that they understand the notion of
>> "unstable" or "private" (not in a security sense).  Thus it seems
>> perfectly reasonable to generate URIs that are explicitly marked as
>> unstable, so that downstream consumers will not complain if they
>> change:
>>     ...
>>     "@context": {
>>       "@vocab": "UNSTABLE/"
>>     }
>>     ...
> That would require out-of-band knowledge. The whole reason to use JSON-LD
> instead of JSON is to *not* require out-of-band knowledge.

Hold on, let's back up a moment and make sure that we are on the same 
page about the overall objective.  Suppose I slightly extend Dave 
Longley's example to add one more blank node property, such as:

   "_:website_status": {
     "editor": {
       "id": "1",
       "changes": 4
     "_:ad636ee3fb": true,
     "_:ee3fbad636": false

Surely, as a design goal, it should be possible for the client to 
process this JSON-LD document either as JSON or as extended RDF.  So 
suppose the document is interpreted as extended RDF by a client that is 
*intended* to fully understand it.  And if you wish, you can even assume 
that the client has has out-of-band information to understand the 
meanings of the "private" data properties _:ad636ee3fb and _:ad636ee3fb. 
  But how is RDF client expected to obtain the values of the 
_:ad636ee3fb and _:ee3fbad636 properties?   Those two boolean statements 
would effectively become (in Turtle):

   _:website_status _:ad636ee3fb true ;
   _:website_status _:ee3fbad636 false .

But in RDF, blank node labels are merely syntactic devices, so the above 
is exactly the same as saying:

   _:b1 _:b2 true ;
   _:b1 _:b3 false .

or even:

   [] [] true ; [] false .

So how on earth can the RDF client figure out which of those private 
properties is supposed to be true and which is supposed to be false? 
It can't.  All it can determine is that there exists a property with a 
true value and there exists a property with a false value.

This use of blank nodes looks to me like a hack to intentionally make it 
harder for an *RDF* downstream consumer -- even an *extended* *RDF* 
downstream consumer that can handle blank node predicates -- to make use 
of the data than for a pure JSON downstream consumer.  This seams to me 
like an *anti*-design goal.  To my mind, the design goal should be the 
opposite: to make it as easy for *both* JSON and RDF consumers to make 
equivalent use of the document.


Received on Wednesday, 10 July 2013 02:47:06 UTC