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

Re: log:forSome/#rdfms-identity-anon-resources

From: pat hayes <phayes@ai.uwf.edu>
Date: Tue, 3 Jul 2001 10:22:27 -0700
Message-Id: <v04210107b76743633229@[]>
To: jos.deroo.jd@belgium.agfa.com
Cc: w3c-rdfcore-wg@w3.org
>that query thing is an interesting idea!
>when we try to unify 2 anonymous nodes it is actually
>like a query of one node against the other node
>(the latter node looking like an in-line set of statements)
>so the former one is existentially quantified
>whereas the latter one is universally quantified
>(and subjects match immediately (we use null's for them))
>and so everybody is right

Well, you had better make sure that your unifications are all 
one-way. It is OK to instantiate an U-variable to an E-variable, but 
not the other way around.

Pat Hayes

>Jos De Roo, AGFA http://www.agfa.com/w3c/jdroo/
>Frank Manola <fmanola@mitre.org>@w3.org on 2001-06-29 07:19:07 PM
>Please respond to fmanola@mitre.org
>Sent by:  w3c-rdfcore-wg-request@w3.org
>To:   Dan Connolly <connolly@w3.org>
>cc:   pat hayes <phayes@ai.uwf.edu>, w3c-rdfcore-wg@w3.org
>Subject:  Re: log:forSome/#rdfms-identity-anon-resources
>Dan Connolly wrote:
> >
> > Frank Manola wrote:
> > > Dan Connolly wrote:
> > [...]
> > > > [[[
> > > > 4. A person is between a rock and a hard place.
> > > > [...]
> > > >
> > > > Following is the KIF representation:
> > > >
> > > > (exists ((?x person) (?y rock) (?z place) (?w hard))
> > > >         (and (betw ?y ?z ?x) (attr ?z ?w)))
> > > > ]]]
> > > >
> > > > --        Conceptual Graph Examples
> > > > http://www.bestweb.net/~sowa/cg/cgexampw.htm#Ex_4
> > > > Thu, 22 Mar 2001 01:45:12 GMT
> > > > linked from http://www.bestweb.net/~sowa/cg/
> > > > linked from http://www.w3.org/DesignIssues/CG#[2]
> > >
> > > Yes, that was the interpretation I'd been assuming as well (see my
> > > message
> > > http://lists.w3.org/Archives/Public/w3c-rdfcore-wg/2001Jun/0326.html)
> >
> > Ah... good... then we're agreed, on the essential point.
>I'm not quite sure about that (as usual, the devil is in the details),
>so I'm going to follow up a bit on your bookseller example.  This may be
>where my apology about barging in should really have come, since I think
>I'm now bringing the discussion back to the point where Pat replied to
>your bookseller example (I'll try to use different words though!)
> >
> > [...]
> >
> > >  So I don't understand how queries come into
> > > this.
> >
> > Then never mind; somebody was convinced by the bookseller
> > scenario about the need for existentials in RDF, so I thought
> > I'd try it here. But I don't need the WG to agree with
> > the bookseller/query scenario; only with the interpretation
> > of triples as (exists (?a1 ?a2 ...) (and (p1 s1 ?a1) ...) ).
> >
>The need for existentials is one thing;  how they are interpreted is
>another.  Take your example:
> > In detail: let's suppose you're buying a book.
> > You transmit, to the bookseller, a description
> > of the book you want to buy; roughly,
> > "it's by Barnsley and it's called
> > Fractals Everywhere. I want it in
> > hardback, tomorrow."
> >
> > Formally, in n-triples:
> >
> > ---8<---
> > _:g0 <http://purl.org/dc/elements/1.1/title> "Fractals Everywhere" .
> > _:g0 <http://purl.org/dc/elements/1.1/creator> "Barnsley" .
> > _:g0 <http://booksellers.example/vocab#binding>
> > <http://booksellers.example/vocab#hardback> .
> > _:g0     <http://booksellers.example/vocab#shipping>
> > <http://booksellers.example/vocab#nextDay> .
> > ---8<---
>The problem is that in the interpretation of RDF triples we've been
>discussing, if I ran across these n-triples on the Web, I should
>interpret them, not as a request, but as an assertion that "there is a
>book, which I'm calling -:g0, by Barnsley, with title "Fractals
>Everywhere", in hardback, with shipping "nextDay" " (ignore for now
>whether it makes any sense to talk about shipping in this context).  If
>I used Sergey's URI generation algorithm on this RDF, I'd substitute
><http://skolem.example#432oj34oij2o3ijo23j> for _:g0, so the assertion
>would now be:  "there is a book, which I'm calling
><http://skolem.example#432oj34oij2o3ijo23j>, by Barnsley, with title
>"Fractals Everywhere", in hardback, with shipping "nextDay";  but the
>essence of the assertion would be the same, only the name I'm now using
>to refer to the book has been changed.
>The issue of context (or query vs. assertion) comes up in your example
>when you send that RDF to the bookseller.  If the interpretation of the
>RDF as an assertion continues to hold, this would simply be a statement
>to the bookseller that "there is a book...", to which the bookseller
>might reply "that's nice" or "so what?".  In this interpretation, it
>doesn't much matter whether, in what you send to the bookseller, you
>refer to the book locally as _:g0 or
>If the RDF is to mean a statement of requirements (a query), then the
>interpretation is at least slightly different, and may be more
>substantially different. The slightly different interpretation could be
>something like "there is a book, which I'm calling _:g0, by Barnsley,
>with title "Fractals Everywhere", in hardback, with shipping "nextDay"
>", do you have one that matches?  Changing _:g0 to the Skolem doesn't
>change the essence of this situation;  in this case the interpretation
>of the RDF would be "there is a book, which I'm calling
><http://skolem.example#432oj34oij2o3ijo23j>, by Barnsley, ..." do you
>have one that matches?  The bookseller may have a book that *s/he* calls
><http://booksRus.example/inv2001-06-25#item342323> that matches the rest
>of the description, and the problem is to decide whether
><http://booksRus.example/inv2001-06-25#item342323> is the same book as
>_:g0 on the one hand, or <http://skolem.example#432oj34oij2o3ijo23j> on
>the other.
>[The situation is the same in a purer logic notation:  the request might
>say "there exists a book x, ..." and the bookseller's "fact base" might
>say "there exists a book y, ..." and the problem would be matching x and
>y;   even if the bookseller's assertion was also "there exists a book x,
>..." you would be unwise to assume that your x and the bookseller's x
>were necessarily the same, without doing the rest of the feature
>comparison, since the variable names come from different
>In the more substantially different interpretation, you're not really
>making an assertion about the existence of the book on your side at all,
>you're asking the question "*is there* is a book, by Barnsley, with
>title "Fractals Everywhere", in hardback, with shipping "nextDay"? [and,
>if so, bind its identifier to _:g0].  Here, you really are interpreting
>_:g0 explicitly as a true variable, rather than a local name, and asking
>some process to determine bindings for it.   And I would say this isn't
>quite the same as saying that _:g0 is an existentially quantified
>variable in a logical assertion.
>In either case, you want what you're calling the book to be interpreted
>differently in a query, because there you need to indicate which parts
>of the description of the book are purely local/arbitrary and need not
>match exactly, and which parts are essential descriptions of the book
>you want.  I.e., in the case of the query, you want to distinguish "what
>I call the book" (which may differ between the requestor and the
>bookseller, and thus need not match) from the title, author, etc., which
>must match to satisfy the request (and a true variable, rather than a
>local name, is a much more explicit way to indicate that).  The reason I
>think queries complicate the situation is that the additional meaning
>you have in mind for the existentials in queries is beyond the strictly
>logical interpretation of existentials in assertions.
>Frank Manola                   The MITRE Corporation
>202 Burlington Road, MS A345   Bedford, MA 01730-1420
>mailto:fmanola@mitre.org       voice: 781-271-8147   FAX: 781-271-8752

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Tuesday, 3 July 2001 13:25:34 UTC

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