W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

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

From: Graham Klyne <Graham.Klyne@MIMEsweeper.com>
Date: Thu, 15 Nov 2001 17:02:05 +0000
Message-Id: <>
To: Jan Grant <Jan.Grant@bristol.ac.uk>
Cc: Dan Connolly <connolly@w3.org>, Pat Hayes <phayes@ai.uwf.edu>, w3c-rdfcore-wg <w3c-rdfcore-wg@w3.org>
At 03:28 PM 11/15/01 +0000, Jan Grant wrote:
>Actually, I've been worrying about this recently. We have, in a
>1.      a bNode is an existentially quantified variable
>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
>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

My understanding is that when RDF is used in its defined mode for asserting 
truths, then the entailments one gets are the same.  The motivation to 
consider the "existential variable" approach was because in some other 
contexts (not defined by RDF core), the entailments may be different.

Dan's example was of a query Q against some database D, treated as:

   From D is it possible to prove Q ?
   D entails Q ?

Which, by a twist of logic I don't fully recall, requires that the 
variables in Q be treated as universally quantified.  If the variables in Q 
are skolemized, the query doesn't work as required.  Simply saying that the 
variable represents a single node whose identifier is unknown doesn't work 
in this case.

So we ended up saying that the existentials were distinguishable from 
ordinary nodes, so they can be treated differently should circumstances 


Graham Klyne                    MIMEsweeper Group
Strategic Research              <http://www.mimesweeper.com>
      /\ \
     /  \ \
    / /\ \ \
   / / /\ \ \
  / / /__\_\ \
/ / /________\
Received on Thursday, 15 November 2001 12:16:18 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:06 UTC