Re: A modest proposal concerning blank nodes.

On Mar 2, 2011, at 8:16 PM, Sandro Hawke wrote:

> On Wed, 2011-03-02 at 16:04 -0800, Gavin Carothers wrote:
>> On Wed, Mar 2, 2011 at 2:47 PM, Pat Hayes <phayes@ihmc.us> wrote:
>>> Ahem.
>>> 
>>> Thinking about this (below) and reading recent threads, I think I agree. Blank nodes are more trouble than they are worth. Lets get rid of them.
>> 
>> Quick run around the office here to this idea led to a rather simple
>> answer. Such a change would likely be out of charter. I don't think
>> the rest of the argument matters in addressing wither or not removing
>> Blank nodes is in charter, and I'm going to avoid disagreeing or
>> agreeing.
> 
> I agree it would be out of scope to just "get rid of" blank nodes, but
> as I read the charter, the WG has considerable latitude to "weakly
> deprecate" things.  If we really all agree people should not be using
> blank nodes, then I think we could weakly deprecate them.   That would
> mean they would stay in the specs, and RDF software would still have to
> handle them, but content creators (and creators of systems producing
> RDF content) would be advised against using them.   
> 
> I think, by the end of Pat's modest proposal, he'd come full circle to
> saying he was really just going to change blank node semantics, not
> really get rid of them.  

I was reacting to Richard's suggestion along these lines. I actually don't like that idea as much as deprecating them, myself.

>  As I read it, that tweaking of the semantics
> is explicitly out-of-scope in the charter.  However, Pat argues that
> he'd be changing them to what people actually implement; I'm not sure
> where we are on the scope if everyone actually agrees on that claim.
> Maybe we can at least defer that debate until we've addressed our
> more-pressing deliverables?

Yes, sure. Sorry. I got thinking about fixing the existing docs, and how amazingly much simpler everything would (have) be(en) if there were no blank nodes, and how almost everyone hates them anyway, and how much pain they caused for SPARQL and for RIF and for linked data and for just about everyone, and how people with graduate degrees in CS *still* can't properly understand what the specs say about them. And then there are the threads on semantic_web at this very moment, complaining about the pain caused by different systems essentially Skolemizing blank nodes differently and how much better it would be if there was one standard way to do this... and the whole point of RDF is to make interoperability simpler, and.... well, you can see how my thinking went. 

But yes, lets defer this debate until we fix the more pressing stuff, I agree. 

> There's obviously a lot more to say about blank nodes, but given my
> current understanding, I think the next version of the specs should at
> least explain the costs of using blank nodes, and perhaps counsel in
> favor of various alternatives.   Maybe that's just some text in the
> tutorial; maybe it's something stronger than that.   For some thoughts
> on that see [1].
> 
> FWIW, as much as I love them [2], I'm not at all sure tag: URIs are
> better than blank nodes, especially when machine-generated.  Pat says
> systems would have to do the naming "in some systematic way", and my gut
> feeling is that's equivalently hard to working with blank nodes.  In
> practice, it might be even worse, because if people did it badly they
> could easily produce vast numbers of tag: URIs for the same thing.

I can't see how that could happen. Or at any rate, no more so than it might with regular URIs at the present. 

> Perhaps I'm misunderstanding that part of the proposal; I don't really
> understand how RDF lists would be handled, for instance.

Just skolemize every bnode. The lists would have URIs, yes. Nobody need ever know about them, hopefully. They would not be resolvable. They would act in a Web setting just like blank node IDs, in fact, except (1) they would be syntactically legal IRIs and (2) they would be globally unique, which is of importance only because it means one can throw together sets of triples containing them, without needing to worry that two of them might accidentally coincide. 

Pat


> 
>    -- Sandro
> 
> [1]
> http://richard.cyganiak.de/blog/2011/03/blank-nodes-considered-harmful/
> [2] http://www.w3.org/2001/02/tann/
> 
> 
> 

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973   
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 3 March 2011 05:01:01 UTC