Re: What do the ontologists want

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

Have to build the structures, and could describe them in RDF triples, yes.

>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.  This is probably not KR research
>material.
>
>And with triples standardized, people can build their more-expressive
>logical languages on the somewhat more abstract cons-cells of triples
>instead of directly on byte strings.  I imagine this will be useful in
>very roughly the way that LISP seems to be better for building AI/KR
>systems than C: you can avoid worrying about concrete syntax and the
>semantics of simple stuff.

We seem to agree. But it seems to me that in order to be able to do 
this larger-syntax-building, the triples model needs something that 
it currently does not have: it needs a way to distinguish triples 
which really are intended to be atomic ground facts (that a binary 
relation is true of two things), and triples which are intended to be 
cons cells of some larger thing. Maybe this could be done implicitly, 
eg if a triple is pointed to by something else then it is a cons cell 
(?), but that seems likely to backfire. It would be safer if there 
was some explicit way to tell by looking at a triple in isolation, 
whether it was a simple tripl-ish assertion, or part of some larger 
thing.  Maybe there is such a way in the RDF model already that I 
have not yet grokked ??

> And more: you should get nice,
>interoperable libraries, without namespace collisions, because of the
>other aspect of RDF triples: the fact that the symbols are handed out
>in a way which avoids unintended reuse.

This is getting more technical, but I think this aspect of the RDF 
picture is a fantasy, unless it involves some new piece of machinery 
I know nothing about (quite possible, let me add.) Look at the old 
LISP distinction between equal (same, ie isomorphic, abstract 
structure) and eq (same actual datastructure object). You can 
'define' triples to be abstract all you want, but you can only point 
to one token of a triple, and if you want to be protected against 
having distinct but isomorphic tokens, something smart has to be 
working away in the background to stop it happening; it isn't going 
to come for free.

>(Some people also want the symbols to contain (or be) a pointer to
>some definitional truth.  I'm still skeptical about that.)

Me too. Definitional truth is a very tricky topic.

> > set of triples will be) and we will probably need a few
> > datastructuring primitives (like end-of-chain markers, cf. Lisp NIL.)
>
>Yeah -- that's one of those silly-but-necessary bits DAML does, of
>course.  Now other people building KR languages on RDF don't need to
>reinvent that.  (not that it would be too hard....)

Sure, it wouldnt be hard, though the details do take up a devil of a 
lot of time, and it would kind of mess with the RDF *semantics*. But 
the point is that if we all start inventing ontology languages on top 
of RDF in this way then they will all have different semantics and 
syntax, and so the semantic web is in just as much a mess as it was 
when we started. Isnt part of the RDF idea to provide a universal 
semantic notation to deal with that kind of babelization problem? (I 
know I expressed cynicism about this idea, but given that it is a 
goal, we could try to do it as well as possible, no?)

> >                                                        There isnt
> > anything odd or exotic about all this, let me emphasize: its is just
> > ordinary bread-and-butter datastructure design.
>
>Mostly agreed.  Building data structures on triples is somewhat
>different from building them with pointers in memory because of
multi-valued slots and incomplete structures.

Ah, now you have me intrigued. Do you have pointers to these issues 
being discussed anywhere?

Pat Hayes

---------------------------------------------------------------------
IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
phayes@ai.uwf.edu 
http://www.coginst.uwf.edu/~phayes

Received on Friday, 18 May 2001 15:22:26 UTC