Re: Input needed from RDF group on JSON-LD skolemization

On 07/04/2013 04:16 AM, Markus Lanthaler wrote:
> On Thursday, July 04, 2013 3:54 AM, David Booth wrote:
>>>> Regarding stability, AFAICT relative IRIs would be nearly as stable as
>>>> any versioned IRI: the IRI may change if the author decides to version
>>>> it, but aside from that it is exactly the same every time the data is
>>>> generated, even if other data elements are added, etc.  That is far
>>>
>>> I completely disagree. While technically you are right, the whole point
> of
>>> using a bnode is to convey it is in fact *not stable* and is not
> intended
>>> to be.
>>
>> Again, you may think of blank nodes that way if you wish, but that is
>> not why they were invented.
>
> Just out of curiosity, why have they then been invented if not provide a way
> to express some facts about an "entity" that is unknown?

They were invented to allow an RDF author to indicate that an entity is 
known to exist, and allow facts to be expressed about it.  The fact that 
bnodes lack a stable identifier was an (unfortunate) by-product -- not 
the purpose of their invention.

>
>
>>> The point is that I don't want them to be stable. I explicitly want to
>>> prevent that people start to rely on them.
>>
>> I suppose that would make sense if your goal is to annoy downstream
>> consumers of your data, but that's rather anti-social.   Making it hard
>> for others to refer to resources mentioned in your data is widely
>> viewed
>> as a *negative* -- not a positive -- and it goes against the philosophy
>> of the web.
>
> That might be true.. but exactly the same applies to bnode subjects and
> objects. Arguably even more so to subjects. So why do you think predicates
> are so special?

Yes, it does apply to subjects and objects also.  Blank node predicates 
are special because they are not a part of standard RDF.  And they are 
not a part of standard RDF because enough of the working group thought 
it would not be a good idea to allow blank nodes as predicates, just as 
enough of the working group thought it would not be a good idea to allow 
literals as subjects.  That could change, of course, but it cannot 
change anytime soon, because the RDF working group charter explicitly 
states that blank node predicates are out of scope.

>
>
>>> OK, so what if we would add a "generalizedRDF" flag to the toRDF
> algorithm
>>> which, when set to false would filter all quads where a bnode is in
>>> predicate position? I would prefer the default value to be set to true
> but
>>> could, if there's a good argument, also live with a false.
>>>
>>> Would that address your concerns?
>>
>> Well, no.  An option for extended RDF would be fine (defaulting to
>> standard RDF), but discarding triples would not be fine, because it
>> would involve unnecessary information loss.  That would bring us back to
>> figuring out how to avoid that information loss.  Skolemization would be
>> one way to do it, but the use of relative URIs seems like a better
>> option because it is so much simpler and it gives the additional
>> benefits (which I understand you do not see as benefits) of more stable
>> identifiers that could eventually be made dereferenceable.
>
> You can't have a syntax which sometimes allows bnode predicates and
> sometimes doesn't. The only option in that case is to raise an error when
> converting to RDF saying that information may be lost because some generated
> triples contain bnode predicates. That would be acceptable for me but I fear
> it won't satisfy you either.

Right.  So the other option is for JSON-LD to prohibit blank nodes as 
properties.  Authors could simply use relative IRIs instead.

David

Received on Thursday, 4 July 2013 16:28:53 UTC