Re: bNodes, MT, process model. Re: datatypes and MT (#rdfms-graph)

>Warning: ramble, vague unease, and potential can of worms.
>
>On Thu, 15 Nov 2001, Dan Connolly wrote:
>
>>  Pat Hayes wrote:
>>
>>  > the question of whether two blank nodes are the 'same' or 'different'
>>  > is settled in the syntax itself. This, in the graph syntax there are
>>  > no bound variables, or local names, or anything at all with a local
>>  > scope.
>>
>>  phpht. How are blank nodes not bound variables?
>
>Actually, I've been worrying about this recently. We have, in a
>nutshell,
>
>1.	a bNode is an existentially quantified variable

I disagree.

>
>and this is something I find slightly disturbing. I'd much rather
>replace it with:
>
>2.	a bNode (anonymous resource, whatever - leaving aside the
>	"is it a literal?" question for the moment) is a node
>	that we don't know the label of

I disagree again. It is a node that we know has no label. You can 
just look at it and see it has no label. That is a very important 
fact about a blank node, that it really is BLANK.

>Why? Well, first note, that this (ie, a node with conceptual identity
>what we just happen to be somewhat ignorant of) entails the same thing
>as the current MT - ie, it's making an existentially-quantified
>statement.

That is indeed a reasonable thing to say.

>Now look at some common questions that I've asked, others have asked,
>and even Pat asked at the F2F...
>
>	"how do I assert additional information about that node?"

Add some triples to the graph. Well, wait a minute. You don't assert 
more information ABOUT the node, strictly speaking; you assert it 
about the thing that the node might denote. And you do that by adding 
triples to the graph linked to the node, just like you would for any 
other node.

>	"how do I find that node again?"

I'm tempted to say, why did you lose it in the first place? But let 
me ask what does it means to 'find again' ?

>
>etc. etc.
>
>These questions are, from a MT point of view, missing the point. But
>I've had discussions with DB implementors for whom the common intuition
>follows the "thing we don't know the name of" line rather than the
>"existential variable" one.

Well, you can take that line, indeed. Any existentially quantified 
name can be just replaced by a new name, as long as it really is 
*new.* That is the skolemization idea. So we could just not have any 
blank nodes at all, and just invent 'dummy' urirefs to label them. We 
did consider that option at Sebastopol, as I recall, and indeed I 
argued for it on the grounds of simplicity, precisely to put an end 
to all this debate about what it meant to refer to something 
anonymous, and so on, but was overruled.

But the moral is, if blankness makes you feel uncomfortable, then you 
can always *pretend* that blank nodes have unknown names, if it makes 
you feel better. No harm will be done. (Of course, if you take this 
pretence to obsessive extremes, like actually trying to find these 
nonexistent names, or thinking of them as if they were real names, 
you could get to a point that might require professional intervention 
to restore sanity; but there is no harm in a little make-believe 
among mature, consenting adults.)

>
>The MT obviously doesn't deal with process issues - how do we assert,
>pass around, delete, transform bits of an RDF graph in an
>implementation. That's not its job. The MT doesn't actually change much
>(at all?) if you take the second point of view above. What does change
>is the reasonable expectation of supported (supportable) operations on
>an RDF store. Can we get away with this?

I think we need to distinguish two different kinds of question to ask 
an RDF store. One is about the syntax of the graph: does it contain 
certain triples, how many properties are linked to this node, etc., ; 
the other is about what the graph means: does it *entail* this or 
that.  The MT is only concerned with the latter, but it is quite 
legitimate to ask the former kind of question. Now, it makes perfect 
sense to be able to refer to a particular blank node as a syntactic 
object and ask the first kind of questions about it. If we stored the 
graph using  nTriples, we might use nodeIDs to do this, for example. 
But that sense of 'labelling' a node in order to be able to refer TO 
THE NODE and maybe identify it later, has to be distinguished from 
the use of a node label as a referring name in the semantics. A blank 
node may be identified as a node by its nodeID, but that nodeID is 
not a logical name in RDF itself: it doesn't refer to any thing in 
the interpretation in the way that a uriref or a literal does. It has 
no RDF semantics.

>
>PS. Pat, please shoot me down.

Did my best.

Pat
-- 
---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Thursday, 15 November 2001 17:17:43 UTC