Re: DAML-S expressiveness challenge #1

Ian -

Thanks, as always, for your thoughtful remarks.  I wanted to respond to
your previous message, regarding the distinction between statements
about schema and statements about data, which is certainly of interest,
but upon reflection, it struck me that taking the discussion in that
direction would be too much of a digression.  For what it's worth, I'm
willing to stipulate that what I'm wanting to express are all statements
about schema.  (The diaper/nappies example was perhaps a
little misleading in that respect, so let's put that one aside.)

For now, I'd like to throw in a few general remarks at a higher level of
abstraction.  First, I think my observation, about certain "recipes" for
expressing things in DAML+OIL, that they are too baroque to be useful,
comes up in large part because we are asking the language to represent
things that (to my knowledge) a KR language isn't normally used to
represent - namely, processes/algorithms.

In our business, processes are most commonly described using programming
languages, and programming languages have lots of special features, many
of which were designed with process representation in mind.  I'm talking
about the familiar elements such as variables, procedure calls and
parameter passing, nested scopes, assignment statements, unification (in
Prolog at least), various constructors/accessors for compound terms, and
all the rest, many of which are not available in DAML+OIL.

To my mind, it's an open question whether it makes any sense to try and
describe processes using the expressive mechanisms of a
description-logic-based language.  If anyone knows of any work related
to this, I'd be interested to learn of it.  It may be that the gap
between what a process-modeler needs to express (conveniently,
intuitively, and compactly) and what a description logic is designed to
express easily is too big to make the effort worthwhile. 

But my point here isn't to say that DAML+OIL is flawed or too lacking in
expressiveness, necessarily.  It is, rather, that DAML+OIL may be just a
part of a bigger picture.  It may be that we need a process
representation language that goes beyond DAML+OIL, one that isn't
necessarily reducible to DAML+OIL - but that is set up so as to
integrate nicely with DAML+OIL.  Look at a typical object-oriented
programming language, such as Java, for instance.  There, data and
structure are represented using class hierarchies with inheritance, but
there's no attempt to represent algorithms in those same terms. 
Algorithms are by and large expressed using a different set of language
elements.  Perhaps that's the way things will turn out in DAML-S; that
is, data and structure will be represented using DAML+OIL, whereas
algorithm/process will be represented by language elements that go
beyond DAML+OIL, but integrate smoothly with it.

I was in an interesting discussion about this stuff today [with Pat
Hayes and Srini Narayanan], and I came out of the discussion thinking in
terms of 3 possible (not necessarily disjoint) paths of evolution for
DAML+OIL, which might enable it to represent (and execute the
representations of) processes conveniently:

(1) The DAML+OIL "assembly language of the Web" path (which I think is
in line with your comments copied below).  In this approach, we continue
to work with the expressive capabilities of a description-logic-based
language, and develop recipes, idioms, and higher-order ways of
expressing things that ultimately can be reduced to it.

(2) The "logic programming" path - where DAML+OIL acquires more of the
langage elements associated with logic programming. 

(3) The "part of a bigger language" path - what I've tried to
express above. 

Regards,

- David

Ian Horrocks wrote:
> 
> On July 10, David Martin writes:
> > Tim -
> >
> > Thanks again for helping to clarify one of my messages.  (I was planning to write
> > a similar clarification
> > myself, with reference to my original DAML-S example, with which this thread
> > began.)
> >
> > Yes, your example is right on with respect to what I need to model. Continued
> > below ...
> >
> > tim finin wrote:
> >
> > > I'm not exactly sure what David Martin needs to model
> > > in his work with DAML-S, but here's a simple example
> > > that I think brings out the problem or at least a related
> > > one.  I'm basing this on an old example from KL-ONE days:
> > >
> > >    a person is a thing with
> > >        one home address of type address
> > >    a worker is a person with
> > >        one office address of type address
> > >    a homeworker is defined as a worker
> > >        who's home address and office address are the same.
> > >
> > > in logic we would (partially) model this as
> > >
> > >    homeworker(X) <-> person(X), homeaddr(X,A), officeaddr(X,A)
> > >
> > > What's missing in DAML+OIL (as far as I understand) is the ability
> > > to express the equality constraint between the values of the two
> > > properties which is no nicely done with variables and unification
> > > in many languages.
> >
> > As I understand things, it is possible to express the above in DAML+OIL, and in
> > fact, an approach to expressing this was suggested in an earlier message.  That
> > approach was in this message:
> > http://lists.w3.org/Archives/Public/www-rdf-logic/2001Jun/0219.html.
> >
> > In the simplest case, where the domain of P1 (homeaddr) and P2 (officeaddr) are
> > the same, the suggested approach involves creating a "dummy" union property that
> > is a super-property of P1 and P2, and relying on a cardinality restriction to
> > enforce that there can only be a single instance of the property, and hence the
> > value of homeaddr and officeaddr must be the same.  However, for DAML-S purposes,
> > things very quickly become much messier, because (for starters) we need to allow
> > for cardinalities of greater than 1, and we also need to allow for different
> > domains for the 2 properties.
> >
> > My reaction to that suggested approach is that yes, it might work, but once
> > you've tied up all the loose ends, you've got an approach that is FAR TOO BAROQUE
> > for any practical use.  (Even in the simplest case, I don't want a Website
> > developer or reader to have to understand that a dummy property and a non-obvious
> > cardinality restriction have been created just for the purpose of stating that
> > homeaddr and officeaddr are the same.)
> >
> > This led me to propose a new property, sameValuesAs, which would be used like
> > this:
> >
> >     <sameValuesAs homeaddr officeaddr>
> >
> > and would state that the set of values of all the instances of homeaddr would be
> > the same as the set of values of all the instances of officeaddr.  (Where y is
> > the value of property instance <p x y>).
> >
> > It may be the sameValuesAs could be defined simply as syntactic sugar, an
> > expression that is equivalent to the creation of some union classes and some
> > union properties and some restrictions.  I haven't had time to get clear about
> > this yet. Regardless of that, I'm also not yet clear whether sameValuesAs would
> > be fully adequate for practical purposes, with respect to DAML-S requirements.
> > But it seems to me it could certainly be useful for some purposes, including some
> > of our DAML-S needs.   I'll try to find time to elaborate further in another
> > message.
> 
> Whether or not this particular example is "too baroque" is a matter of
> opinion, but it is obviously true that things can soon get pretty
> baroque when trying to model the world using DAML+OIL. I think that we
> should view DAML+OIL (and its extensions) as the assembly language(s)
> of the semantic web. In the longer term there will certainly be high
> level languages and/or tools that the vast majority of "programmers"
> will use, and of course most people wont do any programming at all -
> they will just use applications. Unfortunately, the price we pay for
> being "in at the start" is that there are still very few such
> amenities. Until they are developed we will just have to roll up our
> sleeves and get our hands dirty.
> 
> Regards, Ian
> 
> >
> > - David
> >
> > >
> > >
> > > --
> > >  Tim Finin, Prof Computer Science & Electrical Eng, Director Inst. for Global
> > >  Electronic Commerce, U Maryland Baltimore County, 1000 Hilltop, Baltimore MD
> > >  21250. mailto:finin@umbc.edu 410-455-3522 fax:-3969 http://umbc.edu/~finin/
> >

Received on Wednesday, 11 July 2001 03:22:36 UTC