RE: DAML-S expressiveness challenge #1

If DAML is to be used to describe programs (at a high level) then it seems
to make sense to use the representations that the software engineers use for
this purpose. This representation is UML.  UML has a number of ways of
representing behavior: sequence diagrams, collaboration diagrams, state
transition diagrams and activity diagrams. I believe it is better to adopt
some or all of these representations rather than invent new ones.

==Mitch Kokar


> -----Original Message-----
> From: www-rdf-logic-request@w3.org
> [mailto:www-rdf-logic-request@w3.org]On Behalf Of David Martin
> Sent: Sunday, July 15, 2001 4:08 AM
> To: Ian Horrocks
> Cc: tim finin; www-rdf-logic@w3.org
> Subject: Re: DAML-S expressiveness challenge #1
>
>
>
>
> Ian Horrocks wrote:
> >
> > 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).
>
> Right; I think we're pretty much in accord on this.  I didn't mean to
> imply that we are aiming for a full-fledged programming language.  We
> are, for starters, aiming to describe a service for advertising and
> discovery purposes, as you mention above.  But we're also aiming for
> some level of description of the steps involved in the execution of the
> service, and the hope is that this description will be complete enough
> that the service provider and the service user could use it for purposes
> such as monitoring the progress of the service, determining when and
> what they need to communicate with one another, and reasoning about
> services and composing services.
>
> Regards,
>
> - David
>
> >
> > Regards, Ian
> >
> > >
> > > Regards,
> > >
> > > - David
>

Received on Sunday, 15 July 2001 08:33:22 UTC