W3C home > Mailing lists > Public > www-rdf-logic@w3.org > June 2001

Re: rdf as a base for other languages

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Fri, 01 Jun 2001 13:07:55 -0400
To: sandro@w3.org
Cc: www-rdf-logic@w3.org
Message-Id: <20010601130755B.pfps@research.bell-labs.com>
From: Sandro Hawke <sandro@w3.org>
Subject: Re: rdf as a base for other languages
Date: Fri, 01 Jun 2001 12:22:51 -0500

> In message <20010601115102E.pfps@research.bell-labs.com> you wrote:
> > Unfortunately RDF only has triples, so triples end up being used for both
> > the ground facts and the more-complex information.  RDF has no way of
> > distinguishing between these differing uses of triples, so any triples that
> > are used to store the more-complex information are also asserted as facts
> > by RDF.  Worse, ....
> The "more-complex information" is stored by being described with ground
> facts.  What's wrong with that?   Where is the confusion?
> The only potential for confusion I see is that some people might want
> to jump from having a triple described (with ground facts) to assuming
> the described triple is true, but that seems clearly wrong.

Clearly wrong, but RDF mandates that all triples are in the model.  If you
believe that the model is a representation of some information, then you
want these triples to be true.  If you don't believe that the model is a
representation of some information, then what are you using RDF for?

For example, suppose that you wanted to represent propositional formulae
within RDF.  You might do something like:

<rdf:type x OR>
<component x y>
<component x z>

<rdf:type y rdf:Statement>
<rdf:subject y John>
<rdf:predicate y loves>
<rdf:object y Mary>

<rdf:type z rdf:Statement>
<rdf:subject z John>
<rdf:predicate z loves>
<rdf:object z Susan>

<loves Bill Susan>

<rdf:type Bill Person>
<rdf:type John Person>
<rdf:type Susan Person>
<rdf:type Mary Person>

You understand this collection of RDF triples to mean that Bill loves
Susan and John loves either Mary or Susan, and that they are all people.

However, I, not knowing that you have discarded the usual meaning for RDF
triples, have to interpret this collection of RDF expressions as including two
kinds of things, Persons and ORs.  I have no way of distinguishing between
those resources that are Persons and those that are ORs---to me they are
both regular kinds of things, and have to be treated the same way.

This is an extremely simple example that only scratches the surface of the
problem.  If you want to have anything more complex, such as quantification
or beliefs, then things get much worse.

> Perhaps another possible confusion is around existence: if I describe
> to you that x is a blue Honda Civic with license plate 9948JI , does
> that mean that such a car exists?    (I think not.)

RDF either mandates that everything that it mentions exists, in that it is
in the model, or has no position on whether anything exists, if you believe
that being in the model has no necessary connection to existance.  In the
former view, x certainly exists.  In the latter view, there is no way (in
RDF) of saying that anything exists. 

> As a specific example, let's imagine a robot which can jump into the
> air.  I can send it knowledge in RDF.  I might say
>   :jump17 a :Jump.
>   :jump17 :height "21cm".
> describing a jump ("jump17") of 21 centimeters.  One could define the
> class (":Jump") such that on learning of an instance a receiver should
> attempt to perform it.  Alternatively (and I think preferably), one
> could define it as abstract, so that you can talk all you want about
> jumping, with no one doing anything.   If you want the robot to jump,
> you might use a non-RDF channel to say "perform operation :jump17", or
> you might define some act-as-soon-as-you-have-knowledge semantics for
> a few specific vocabulary terms the robot looks for, perhaps a
> ":request" term.

Sure, you can do anything you want outside of RDF.  However, if you want
RDF to represent anything, you better do all your work within RDF.

>     -- sandro

Received on Friday, 1 June 2001 13:08:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:35 UTC