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

On Wednesday, July 03, 2013 6:08 AM, David Booth wrote:
> It is true that IRIs generated this way would not be dereferenceable,
> but this seems to me like a perfect example of why dereferenceable IRIs
> are a "SHOULD" instead of a "MUST".  And a benefit of using IRIs is that
> later on, those IRIs could potentially be made dereferenceable, and that
> is not possible with blank nodes, as blank nodes are never
> dereferenceable.

I think that's the whole reason of using a blank node. I don't won't it to
become dereferenceable ever. If I wish to do so, I replace it with a
concrete IRI.


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


> better than blank nodes, which have no stability at all.  (That's one
> of the reasons they are such a pain for downstream RDF consumers.)

That's a feature, not a bug IMO. I can create properties on the fly, perhaps
even describe what they mean in the current context, but consumers should
not start to rely on those properties. Simplest example:

  _:knownBy owl:inverseOf <http://xmlns.com/foaf/0.1/> .

(yes, we do support inverse properties out of the box in JSON-LD)


> In summary, it seems to me that in comparing blank nodes with relative
> IRIs: (a) blank nodes are far less friendly to downstream RDF
> consumption; (b) neither would likely be dereferenceable initially, but
> relative IRIs could later be made deferenceable, whereas blank nodes
> cannot; and (c) relative IRIs would be far more stable than blank nodes
> -- comparable stability to other versioned IRIs.

The point is that I don't want them to be stable. I explicitly want to
prevent that people start to rely on them.

This is similar to a private member in OO programming. Nothing would break
if everything were made public. Most of the time however I want control over
what is made public. I do mark things for which I cannot guarantee stability
as private to prevent that people start relying on them.


> The only significant downside I see to relative IRIs is that they
> create an expectation of being dereferenceable, and that expectation

and stability..


> (presumably) would not initially be met.  That seems to me like a small
> price to pay for the concrete benefits that are obtained from having
> IRIs instead of blank nodes.

I think we just have to agree to disagree :-)


> If a vendor wants to support value-added extensions then that is fine.
> But I would expect *standard* JSON-LD parsers by *default* to produce
> *standard* RDF -- not extended RDF -- although it is fine and good for
> them to have an option for producing extended RDF.
> 
> > All it would buy us is that some implementations may not be able to
called
> > conformant anymore (those who decide to not implement skolemization).
> > There's no way to enforce what consumers do with the data anyway.
> >
> > The easiest way out of this would be to define some additional product
> > classes:
> >    a) an "extended RDF to standard RDF converter using skolemization"
> >    b) an "extended RDF to standard RDF converter discarding the
extensions"
> >
> > Then we could say that class a) implementations MUST transform bnodes
used
> > in predicates to skolem IRIs.
> 
> Actually, this discussion has convinced me that prohibiting blank node
> properties would be a better solution than skolemizing.

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?



--
Markus Lanthaler
@markuslanthaler

Received on Wednesday, 3 July 2013 09:06:49 UTC