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

On 07/12/2013 06:18 AM, Markus Lanthaler wrote:
[ . . . ]
> You could say that every property in every JSON document is a blank node.

Properties in JSON are strings, and strings are stable -- they don't 
change.  But the meaning of the string depends on the document.   That 
is exactly what a relative URI gives you: a stable name whose meaning 
depends on the document.  That is not what a blank node gives you, 
because blank node labels are *not* stable -- they are arbitrary.

> So
> how does such a system work? Well, people simply rely on out-of-band
> knowledge to interpret the data nevertheless. Nothing prevents my "prop"
> property to mean something entirely different from your "prop". I the
> consumer has enough context, it will understand them, if not, it will ignore
> them.
>
> The goal of JSON-LD is to eliminate that out-of-band but we can't do so
> overnight.

Compared to blank nodes, relative URIs clearly give a better migration 
path away from relying on out-of-band information, because a relative 
URI is at least *potentially* dereferenceable, whereas a blank node is not.

But it seems that I am getting mixed messages about the use case.  Is 
the information important to retain or isn't it?  In some cases you seem 
to be saying that you want the information to be retained for the 
benefit of certain clients, and in other cases you seem to want the 
information to be eliminated.  Which is it?   If you want the 
information retained, then make it usable to the clients by using stable 
names.  If you don't want it retained, then eliminate it entirely. 
Don't hobble the data by making it easy for JSON clients to use but hard 
for RDF clients to use.  Either eliminate it entirely or make it useful.

I propose that the spec be changed to prohibit blank nodes as 
properties, and instead, to meet the use cases described:

  - encourage users to use relative URIs; and

  - specify a mechanism for entirely eliminating data that the author 
wants to eliminate from the JSON-LD model, such as by mapping the 
property to a special /dev/null or /UNMAPPED namespace or something like 
that.

Would an approach like that satisfy your use cases?

David

Received on Friday, 12 July 2013 13:17:50 UTC