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

On Friday, July 12, 2013 3:17 PM, David Booth wrote:
> On 07/12/2013 06:18 AM, Markus Lanthaler wrote:
> 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?

It's the clients decision what to do with the data.


> 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.

The decision doesn't affect JSON clients at all. They couldn't care less
about to what properties are mapped (or if they are mapped at all). The
decision however affects whether the author of such data leverage his
JSON-LD tool chain or not. As I've now said several times, the JSON-LD
algorithms throw away every property (including the complete subtree) that's
not mapped to a IRI/blank node/keyword.

If a publisher needs to include some data which can't or shouldn't be mapped
to stable URLs, e.g., because it's only there to not break old JSON-only
clients it couldn't rely on the JSON-LD algorithms anymore because they
throw those properties away. Mapping them to blank nodes is a compromise

 
> 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.

There's no need for that, just don't map the property.
 

> Would an approach like that satisfy your use cases?

No, but as I already said, I could live with a solution where the blank node
properties only exist within JSON-LD and are only exposed if a specific flag
is set.

Wouldn't that address your concern as well? Authors would be discouraged
from using bnode properties since the resulting triples won't be exposed by
default. At the same time, we could keep the functionality which the
majority of the JSON-LD CG believes is important for adoption.


--
Markus Lanthaler
@markuslanthaler

Received on Friday, 12 July 2013 14:07:16 UTC