Re: What do the ontologists want

"Peter F. Patel-Schneider" wrote:
> 
> From: Frank Manola <fmanola@mitre.org>
> Subject: Re: What do the ontologists want
> Date: Mon, 21 May 2001 13:08:56 -0400
> 
> > Peter--
> >
> > It seems to me when you say "makes it essentially impossible to use the
> > semantics for the positive ground triples to represent domain
> > information" you're going a bit beyond what Pat said.  It seems to me
> > that Pat was pointing out that all RDF allowed you to do in the example
> > was define a collection of relationships between some instances
> > ("positive ground triples");  it didn't give those relationships any
> > special semantics, either logical (to support inferencing) or domain
> > semantics.  If I say "author(a,b)", RDF doesn't define the semantics of
> > what an "author" is either (we want DAML+OIL to do things like that).
> [
> ]
> > However, I presumably can use a collection of "author(X,Y)" triples to
> > represent useful domain information (given that my processor knows how
> > to interpret "author" properly, of course).  This is what databases do
> > all the time, and what the simplest examples of RDF illustrate.
> 
> This is precisely the sort of thing that I meant when I said that there are
> useful things that RDF can represent.  I'm sorry if I was unclear in what I said.

That's what I *thought* you had in mind, but in the context of the rest
of what you said I wasn't quite sure.

> 
> > Now suppose I introduce some new relationships like "premis" and
> > "conclusion" (and possibly some other encoding tricks to get everything
> > into triples).  It seems to me it's certainly possible to mix triples
> > involving "premis" and "conclusion" (and any other relationships needed
> > for the encoding) with triples involving "author", "subject", and other
> > domain relationships, and not mess up whatever domain semantics I get
> > out of the domain relationships, provided I can properly separate the
> > stuff that is to be interpreted as part of the "more-expressive"
> > formalism from the stuff that is to be the ground facts.
> > Or, to translate this into database terms, suppose I take my relational
> > database and store my ground triples representing authors in it.  Now
> > suppose I add some additional tables to the database to support an
> > encoding of logical rules, to be operated on by some inference engine.
> > The same author information (domain semantics) can be extracted from the
> > database as before those additional tables were added, so I haven't lost
> > the ability to represent domain information (any ability you already
> > had, that is).  But obviously you need to make sure that you keep the
> > use of the domain tables appropriately separated from the tables
> > representing the "more expressive formalism" if you're going to make any
> > sense of what you have.  In other words, RDF doesn't restrict the
> > relationships you define to any one level of abstraction (whether one of
> > those levels is called "encoding" or not), but it doesn't provide any
> > magic means of defining (much of) the semantics of those relationships
> > (no matter what level they are), or sorting those levels out either.
> 
> This is what I think that *cannot* be in RDF, at least as it stands now.
> In RDF as it stands now the ``premis'' and ``conclusion'' triples are given
> exactly the same semantic import as the ``author'' and ``subject''
> triples.  Even worse, the triples that are used with the ``premis'' and
> ``conclusion'' triples are also given the same semantic standing, and these
> triples will have ``author'' and ``subject'', or other domain predicates,
> as their predicates.  There is no mechanism (in RDF) for separating the
> triples that actually convey domain meaning from those that are just part
> of implications, or negations, or existenials, or ....
> 
> This is why I say that you cannot use RDF semantics when you have an
> encoding of more-expressive formalism.  There is no way (in RDF) to
> separate the triples that have direct semantic meaning from those that need
> other treatment.
> 

Actually, what wasn't clear to me was what you meant by the "semantics
for the positive ground triples" in the original message, but your
mentioning negation in the above caused a light to go on (I think). 
Correct me if I'm wrong, but an example of the problem would be that
you've decided to add something like a NOT relation and have it mean
that certain domain triples (which you also provide in the same "place"
and which you reference in instances of the NOT relation) are not true. 
A processor that understands the NOT "language" of course does the
appropriate thing, but an ordinary RDF processor sees what it thinks are
asserted domain triples, doesn't understand what NOT means, and gets a
meaning opposite to what is meant.  That is, the "semantics for the
positive ground triples" is that they are asserted (ignoring a bunch of
stuff about the context in which they are asserted, which needs some
clearing up too).  

--Frank


-- 
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

Received on Monday, 21 May 2001 16:05:14 UTC