Re: DAML-S expressiveness challenge #1

On July 11, David Martin writes:
> 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.

This may be a relatively new application area, although KR has been
used in a software information system (Devanbu, P., Brachman, R.,
Selfridge, P., Ballard, B., `LaSSIE: A Knowledge-Based Software
Information System', Communications of the ACM, Vol 34(5), pp 34-49,
1991). One nice feature about the process/algorithm application,
however, is that it seems to lend itself to exact descriptions in a
way that applications dealing with the "real world" often don't. This
is evident in the names, which are often simply mini-descriptions,
e.g., a composite-process is exactly a process that has one or more
components. In general, the more of these kind of description you
have, the more "added value" you can get from reasoning, because it is
possible to identify sub-classes and instances based purely on their
characteristics. E.g., when I find a process that has a component I
know that I have found a composite process even if it wasn't
explicitly described as such.

> 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 had never considered the idea of using DAML+OIL to describe
processes in such detail that the description could be "evaluated" -
this would surely be doomed to failure - as you rightly point out,
what you need for this is some kind of programming language. I was
under the impression that DAML+OIL would be used to describe/advertise
the services on offer so as to enable an "intelligent agent" to
identify a service that met its requirements. It would presumably then
go off and "evaluate" the appropriate chunk of programming language.

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

It has always been recognised by the DAML+OIL design team that
language extensions would be needed in order to meet a range of
application requirements. Our aim with DAML+OIL was to build a
language that was useful in itself but which also provided a solid
foundation for such extensions. (By the way, I don't think that this
makes (1) any less relevant - there are good reasons for keeping both
DAML+OIL and its extensions relatively compact, so I believe that more
"human friendly" tools/language layers will still be required.)

Even given this scenario, however, I wouldn't envisage a fully fledged
programming language being one of the extensions!  Instead, I would
imagine that a description of a service would be linked in some way
(e.g., via a pointer) to the actual service (e.g., a chunk of code).

Regards, Ian


> 
> Regards,
> 
> - David

Received on Wednesday, 11 July 2001 19:46:00 UTC