Re: Existentially Quantified Variables (bNodes) in RDF-like-languages

>This is an old issue.  Pat Hayes explained very nicely a year ago [1] that
>RDF M&S has always had existentially-quantified variables (in the subject
>role), and to take them out would be a change.  Many others (including myself
>at the time) supported this position, including the RDF Core WG.  Some
>agreed that's what M&S said, others simply thought existentials would
>be good to have.
>
>But I want to revisit the question more fundamentally.  What good are
>existentially quantified variables in a language like RDF? [2] Why would we
>possibly want them?  I no longer know a good reason.
>
>Here are four reasons I have heard for them, and my counter-arguments.
>
>Reason 1:  Because people often express themselves without giving URIs for
>            things.  Using pronouns like "something" feels like a very natural
>            and comfortable way to communicate.
>
>	   Response: While we may not explicitely have names for things, the
>	   ability of natural language to "go meta" means you can always talk
>	   about "the thing you meant when you said '...'".   So we can still
>	   identify the denotations of terms used in conversations, even if no
>	   explicit identification was given at the time.

Well, yes and no. What you are talking about here isnt really going 
META, its more like referring back to something in a CONVERSATIONAL 
context, what linguists call the 'common ground'. And that is the 
point: in order to do that, you have to have a common ground to refer 
to. Imagine someone who just walks up to you and says 'remember that 
thing you were talking about...' and it turns out that he is 
referring to a conversation you and he had several years ago. (This 
has actually happened to me, by the way; the person in question hadnt 
seen me for almost a decade, and he phoned one day and just carried 
on the conversation.) The point of the example being that in order 
for this to work, you both need to have some way to refer to the 
context of the conversation in which the name was used; and 
remembering enough stuff in order to be able to make sense of such a 
back reference is a major computational cost. So major, in fact, that 
it isnt reasonable to expect that any agent does maintain all such 
contexts.

Insisting on having globally unique URIs for every occurrence of 
every local variable amounts to saying that the Web should somehow be 
able to remember every use of every blank node in every context, for 
ever. Maybe it would be logically nice if that could be done, but it 
clearly can't be done, and it just won't happen.

>
>	   Alternatively, who cares.  This is a formal system, and 
>any appeals to
>	   human qualities are likely to be misleading anyway.
>
>Reason 2:  We were getting a lot of noisy URIs in our knowledge bases.
>
>	   Response: This isn't really a model-theory issue.

It is a real issue, however, and I think it is central. The point is 
not just the syntactic clutter, but the inference patterns that these 
names will block. If I copy some RDF then I do not have a licence to 
rename any of the urirefs in it. But I *should* have such a licence 
for the blank-node urirefs that you want to insert, because those 
urirefs don't actually mean anything; they are just arbitrary labels. 
.

>  A
>	   best-practices approach might be to suggest that urn:uuid's be
>	   used for any identifiers which are both not meant for humans and
>	   not tied to any on-the-web knowledge base.  User interfaces
>	   shouldn't be showing URIs anyway, but they could hide these even
>	   more.
>
>	   Another approach is to have meta-data, with triples saying that
>	   the URI "urn:uuid:57c259ca-47ed-11d6-8002-0050ba4812a6" is not
>	   meant for humans, or something.   (Note that such an assertion
>	   must be about the above string, not the object denoted by that
>	   string.   That object may be denoted by many URIs, some of which
>	   are prettier than others.)
>
>Reason 3:  Because we can use existential variables for querying RDF.
>            (Pat suggests this in [1].  It was my reason a year ago.)
>
>            Response: I've seen a lot of RDF query languages now, and this
>            approach is not being used.

It is in the proposed DAML query language.

>  In my own query language designs,
>            I've found them unsatisfactory.
>
>Reason 4:  One should be able to commit to a statement like "Someone on E-Bay
>            is selling a signed copy of 'Weaving the Web'."  That statement is
>            different from "Someone on E-Bay is selling the signed 
>copy of 'Weaving
>            the Web' which has the URI http://example.com/copy7".  The second
>            one entails the first, of course.
>
>	   Response: Why do you want to make the first statement?  What bad
>	   thing will happen if you call it
>	   <urn:uuid:57c259ca-47ed-11d6-8002-0050ba4812a6> ?

A better question would be, what bad thing would happen if you said 
<urn:uuid:5-0850-123985=0-129ut0jfopqi7>  is selling a signed 
copy..., and then some inference engine tried to figure out 
<urn:uuid:5-0850-123985=0-129ut0jfopqi7>'s SS number, knowing that he 
is a person living in the USA.

But a direct answer is that one bad thing would be that any inference 
that did not use that particular name would be blocked.

>
>	   Are you worried that someone else will say something about
>	   <urn:uuid:57c259ca-47ed-11d6-8002-0050ba4812a6>?

No, the point is more the other way round: if they want to say 
anything about the thing that is for sale, they are obliged to use 
that particular uriref. It is unique, remember. Also, if you 
generated it, then you are responsible for remembering what it is 
supposed to denote. For ever.

>  Like "it's
>	   missing page 7?"  But they could do that anyway (with existentials)
>	   by using various more-expressive ontologies, perhaps talking about
>	   all the books on E-Bay, or talking about the terms in your
>	   original statement.
>
>	   When you used a URI for E-Bay, were you committing to any
>            facts?

That the thing in question has a certain name, yes. Suppose another 
engine, given all the facts about 
<urn:uuid:57c259ca-47ed-11d6-8002-0050ba4812a6>, wants to use some 
other name for it and assert those facts using that other name. Is 
that a logical crime?

>  Which ones?     I think that's the real issue here. 
>
>	   I think a URI enables a client to learn more about a thing,
>	   but the use of a URI in one document cannot be taken to
>	   mean that someone asserting the document believes any facts
>	   outside the document.  
>
>	   ... but then how do you know what was meant?  If I write
>	   you a check for $100, how do you know if I meant $US or
>	   $Canadian?  The fuzzy vision of the Semantic Web involves
>	   the meaning of URIs being established by some kind of
>	   consensus reality, I think.  But how does one commit to a
>	   statement in such fuzzy terms?  
>
>	   Anyway, maybe existentials will be useful as being free
>	   from consensus reality issues, but I don't see how.  I want
>	   to see the argument you present to a judge when you're
>	   suing someone for breech-of-RDF-assertion.  Maybe it comes
>	   down to the natural-language comments in the ontology.  Do
>	   you need to explicitely commit to an ontology, or just use
>	   terms from it.  What if two ontologies exist with the same
>	   URIs?  Which one are you committing to?  I think the only
>	   solid ground is to explicitely import facts (including
>	   natural-language documentation) from some URI, giving a
>	   secure hash of the contents if you're worried it might
>	   change.   (but that's not the way RDF is being used today...)
>
>The reason to leave them out is that they complicate things.  
>
>Its worth noting, too, that if you really want to make an existential
>statement, you can do it in some higher-layer logic language.

That is quite unclear. It depends on the higher layer and how it is 
connected to RDF. If there are no anonymous nodes in RDF-lite, how 
does it handle containers? If it has no containers, how does it 
encode higher-level syntax?

Pat Hayes
-- 
---------------------------------------------------------------------
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, 4 April 2002 23:58:26 UTC