RE: DAML-S expressiveness challenge #1

> -----Original Message-----
> From: www-rdf-logic-request@w3.org
> [mailto:www-rdf-logic-request@w3.org]On Behalf Of Dickinson, Ian J
> Sent: Sunday, July 15, 2001 1:02 PM
> To: www-rdf-logic@w3.org
> Subject: RE: DAML-S expressiveness challenge #1
>
>
> From: Mitch Kokar [mailto:kokar@coe.neu.edu]
> > 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.

> I disagree. That would be like saying that companies today should
> advertise
> in the yellow pages by posting the flow charts of their business
> processes.
> Consumers choose vendors by *what* they do, not how they do it.
> Similarly,
> agents (e-services, web-services, etc ... pick your poison) will also want
> to choose other services based on what they do, i.e. on the pre- and
> post-conditions, and meta-data such as cost and quality. So a state
> transition diagram would simply be the wrong level of detail.  In
> any case,
> a graphical notation is not really suited to automated processing.
>
> Cheers,
> Ian
>

I certainly agree with your statement that in order to advertise services
you don't need to describe how they work. I was referring to the statements
made in the discussion included below. It seems that this discussion
suggests that in some cases one would need to go into more detail than just
advertising what particular services can do. It seems that both David and
Ian recognize a need for some language that would specify the operation side
of the processes. This is why I suggested to look at UML and its
capabilities, in particular sequence, collaboration, state transition and
activity diagrams. I should also clarify that "diagrams" have their mappings
to XML, so it is not just a graphical form.

I would also like to mention that some of the DAML investigators
participated in the OMG meeting last week. I must say that the software
engineering community is now aware of DAML and is seriously interested in it
as a language that would complement the capabilities of other modeling
languages that the OMG promotes. Their approach is to develop UML "profiles"
for various languages, among others they would like to see a profile for
DAML. To me this seems natural to first investigate the capabilities of
other, already existing languages before starting a new effort of developing
an extension to DAML.

==Mitch






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 Monday, 16 July 2001 12:03:22 UTC