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

Re: What do the ontologists want

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Fri, 18 May 2001 08:50:36 -0400
To: sandro@w3.org
Cc: phayes@ai.uwf.edu, www-rdf-logic@w3.org
Message-Id: <20010518085036I.pfps@research.bell-labs.com>
From: Sandro Hawke <sandro@w3.org>
Subject: Re: What do the ontologists want 
Date: Fri, 18 May 2001 06:29:53 -0400

> 
> pat hayes:
> > sandro:
> > >For example, I might want tell some entity that if it has the triple
> > ><A,B,C> in its store, it should remove it.  I want to say something
> > >like:
> > >
> > >   there exists some triple T with a first
> > >   element A, a second element B, and a
> > >   third element C.  If you currently believe
> > >   T to be true, forget that fact.
> > 
> > I have NOOO problem with you doing that, let me emphasise.
> 
> And then you go on to say, as I understand it, that the language of
> triples is not very expressive.  There are lots of things you can't
> say in it directly.  When you want to say such things, you'll have to
> build the syntactic structures of a more expressive language by
> describing them in these little RDF triples.
> 
> Which I agree with entirely.  And I think this somewhat-painful
> layering approach is probably good software engineering.  We can
> standardize on triples relatively easily (as long as we understand
> that's what we're doing).  And triples themselves are expressive
> enough for a lot of information, like much of what people are putting
> into XML or relational databases.  [...]

Unfortunately, using triples to build more-complex (syntactic) structures
means that the triples that are so used cannot play the same semantic role
as triples used to (directly) convey facts.  However, RDF requires that all
triples have the same status in its model.  This provides a problem if the
RDF model is supposed to be used to represent information.

>     -- sandro

Peter Patel-Schneider
Bell Labs Research
Received on Friday, 18 May 2001 08:51:52 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:45:37 UTC