Re: What do the ontologists want

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

I'm not sure I see this problem.

For an example, let me introduce a propositional logic and provide a
rule R which says that given triple <a,b,c> anyone may infer triple
<d,e,f>.  This logic is not very expressive; it does not even allow
conjunction in the premise:

    <R, premise, RP>
    <RP, subject, a>
    <RP, predicate, b>
    <RP, object, c>
    <R, conclusion, RC>
    <RC, subject, d>
    <RC, predicate, e>
    <RC, object, f>

Each of these triples is true itself, while also building a structure
for us.   I have a working system that uses a more complex version of
this, with datalog rules.

The big issue I see, and maybe this is what you're getting at, is
whether an agent is licensed to apply this rule simply by knowing
these 8 facts (no matter what we put in the place I put "R"), or if
some additional inference license is required.  But I think this is an
engineering problem, not terribly fundamental.

Do you see some other difficulty here?   

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

I don't understand how adding higher-level stuff would break the
underlying 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?)

The idea (I think) is that the languages are themselves just
ontologies. 

Since we're trying to develop an infrastructure which supports a
process of world-wide ontology development, where new ones can be
easily created, promoted, and compared against each other in any given
domain (presumable leading to new ones being created and widely
deployed) we'll be able to have our logic systems (such as DAML)
evolve and converge (to some degree) as well.

I think the infrastructure will also give considerable support to
migrating data between ontologies, especially when the differences are
superficial, with something like SQL views (ie rules).

So reasonable people probably disagree about how rapid this evolution
and standardization will be.  Some people think DAML is already the
perfect logic system [ :-) ] and others may think it'll take 30 years
to narrow the field to 100 primary contenders.  And of course there
will be some contenders fighting it out on other fields; I don't know
if KIF will somehow migrate to this field or stay in a different
arena, for instance.


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

Nope.   I've implemented several prototypes of this kind of thing,
mostly in Java a few years back.   I haven't seen it anywhere else,
but I imagine it exists in the RDF community in some forms now.  I
guess this is related to partial structures or something, but I don't
know the research.

One of my systems had a table of java classes which corresponded to
objects having certain properties.  As triples appeared in the
database, the system would attempt to "recognize" members of the java
classes by the presence of the properties.  If sufficient properties
were given values (of the appropriate type, as I recall), a java instance
would be constructed and attached as a "body" to the symbol.  Complex
structures would thus be recognized at the leaves first, and
structures which were entered erroneously were simply not recognized.
(I might have thrown an error for type mismatch, but missing
properties would simply be considered not-available-yet.)

Another version had Symbol.get_body() attempt the recognition when
asked; if data was not yet available, it would throw "not yet ready"
which was trapped at a higher level and caused a later callback when
more data was available -- a process transparent to the code which
called get_body().

I put that stuff down to move to more pure-logic systems which seem to
handle this more naturally.  (Prolog texts treat partial structures as
the normal order of the day, although perhaps for different reasons.)

   -- sandro

Received on Friday, 18 May 2001 17:06:39 UTC