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

Re: A use case for anon nodes - action from telecon

From: Brian McBride <bwm@hplb.hpl.hp.com>
Date: Tue, 24 Jul 2001 12:09:10 +0100
Message-ID: <3B5D5756.5ED6018D@hplb.hpl.hp.com>
To: pat hayes <phayes@ai.uwf.edu>
CC: w3c-rdfcore-wg@w3.org

pat hayes wrote:

> OK, though you really shouldnt have used the same '-:q' as in the
> first example.

I did that exactly to expose the issue of the scope of anon resource

> BUt now, how is any matching done between these?
> Rewrite the second example using a different anon-name:
> ><#advert456> <foo:role>        "seller" .
> ><#advert123> <foo:description> _:service .
> >_:service    <foo:produce>     <foo:roses> .
> >_:service    <foo:quantity>    _:qq.
> >_:qq          <foo:units>       <foo:kg> .
> >_:qq          <foo:maxValue>    "500" .
> and put it all together and we have a total of 12 triples which refer
> to two anonymous things called _:q and _:qq which have no obvious
> connection to one another. No variables, nothing to 'match', no
> obvious consequences. Certainly it doesnt follow that _:q  equals
> _:qq; they might be respectively 256 and 483, say.

It was never my intentiont tht _:q and _:qq denote the same resource.
One denotes a buyer service.  The other denotes a seller service.
However, a broker might usefully note some things in common between
these two descriptions.

A broker might 'know' that there is profit to be made introducing
two services, one a buyer and the other a seller of the same product
where the quantity constraints are compatible.

> Agreed, though that isnt the key issue here. What matters is what
> kind of process is allowed to 'bind' a value to a variable, and the
> (sad but true) fact that whatever is doing that had better not claim
> to be doing anything that is valid in RDF1.0.

On what grounds?

> >
> >[...]
> > > > I'm not sure that standard FOL captures this.  FOL is built
> > > > around a conceptual model where there can be many interpretations
> > > > for statements in the FOL.  But that is not the situation we
> > > > are in here.  We have one interpretation - its a mapping to
> > > > the world out there.
> WHICH mapping? How can I possibly know, when reading your RDF, which
> mapping you have in mind?

Are you suggesting that there is more than one mapping from a URI to a 
resource?  From a URI to a property?  I hope not.

> The key issue is whether something is allowed to bind variables to
> new values during processing. If they are, and if this is considered
> valid, then those variables that get bound must be either universal
> variables in an assertion, or existential variables in a query.
> Either way that takes us outside the RDF 1.0 M&S, seems to me.
> >
> >What I'm getting at that traditional logic is about designing formal
> >systems that are true under any interpretation.  That's not what we
> >are dealing with here.
> No. Logic is about characterising how truth is preserved. The idea
> isnt that formal systems are true (actually that doesnt mean
> anything), but that the formal systems *preserve* truth: it the
> antecedents are true (in I) then the consequents must be true (in I).
> That 'if..then' is what has to be true for any I if the reasoning is
> valid. The point being that if I have no idea what your intended
> interpretation is (which in general I don't, in fact, other than
> knowing that it makes your assertions true), then that doesnt matter;
> I can still draw valid conclusions from your sentences since
> *whatever* your intended interpretation was, my conclusions will be
> true in it.

Quite right I wrote with my usual fuzzy lack of precision.  However,
the point I was trying to make remains valid.  RDF is not about a
truth preserving logic system which preserves truth in any interpretation.
Its about expressing facts with one interpretation.

> The key issue is who is doing the binding. If an RDF engine can bind
> values to variables at run time (ie at inference time), then it's
> going beyond the M&S.

Does M&S preclude this?

Received on Tuesday, 24 July 2001 07:11:45 UTC

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