W3C home > Mailing lists > Public > www-ws@w3.org > September 2003

what is the "semantic core" of DAML-S?

From: <Joachim.Peer@unisg.ch>
Date: Sat, 20 Sep 2003 17:30:46 +0200
To: www-ws@w3.org
Message-ID: <OF04A1F3FD.136F2A49-ONC1256DA7.0053F6D4@unisg.ch>

hi all,

i was wondering what can be considered the "semantic essence" of DAML-S,
and i was also wondering whether DAML-S/Semantic Web Service Description
could be decoupled a bit from DAML+OIL.

1. my problem

Currently, DAML-S is consequently tied to DAML+OIL (or OWL), which in my
opinion, is not always optimal:

* No "native" language support to represent vital parts of a service's
semantics: in DAML+OIL, there is no language level construct to represent
logical variables, hence helper constructs such as "profile:parameterName"
must be used. Further, it is impossible to freely represent
relations/functions between input and outputs, preconditions and effects,
whereas in a  simple rule based format i could write something like
Person(X), Output= phoneNumber(X).

* Usability issues (personal taste): DAML+OIL is tied to to RDF
serialization. This concrete representation (usally RDF/XML) leads to
relatively large files that are hard to understand and maintain, at least
if plain text editors are used [1]. This clearly heightens the entry
barrier for web service developers.

So, we have the following situation:

a) surely everything can be represented somehow by DL ontologies, and
DAML-S does just that.

b) but on the other hand, not all problems can be successfully solved by DL
based reasoning only. I think it is safe to say that Description Logic (DL)
based reasoning is a useful but not sufficient technique for applications
like automatic Web Service retrieval and composition. While there exists
much work on using pure DL reasoning for Web Service retrieval (e.g. [2]),
lot's of other work, especially in the context of Web Service composition
relies on non-DL based techniques, e.g. AI planners [3].

To me, this is a paradox situation. What is the technical justification for
using DAML throughout the whole DAML-S concept even where disadvantages
outweight the benefits? I.e. why do i deal with the cumbersome aspects of
DAML+OIL when DAML+OIL reasoning will not solve my problems?

Why can't DL's use be restricted to those parts of a service representation
where it clearly pays off, e.g. representation of input and output types,
or qualitiative service properties?

2. a potential solution

I think this issue can be addressed by de-coupling the semantic aspects of
DAML-S from its notational aspects. I am not sure if this has been proposed
before, because it is such a simple idea, but i would really like to see
something like a "kernel" which tells us how a web service should be
described. This kernel would capture just the _essence_ of what can be
considered the core of the current DAML-S concepts, e.g. the IOPE
semantics, the semantics of the  process composition constructs and so
forth. Fortunately, much work has been  done to carry that out (e.g. [4] or
the recent posting by McDermott [5])

In addition to this kernel, mappings could be created to several different
styles of notations, such as "classical" DAML-S and various alternative or
leightweight dialects, which can be transformed into each other.

The abstract semantic core should be designed with the issues related to
computational complexity in mind, and it should also make use of core
Semantic Web techniques (e.g. the use of ontologies to represent type

 Semantic Web Service description concept
    (ie. DAML-S' core or "semantic essence")
     |               |                |
   transform.  transformation    transformation
   rules           rules            rules
     |               |                |
     |               |                |
DAML+OIL       encoding  X         encoding Y
endoding        (e.g. using          (e.g. using
                 Rules in prolog      RuleML/XML)

The benefit of such a decoupled hierarchy of languages would be:

1) the semantics of DAML-S could be expressed in very straightforward, more
transparent and still formal/obliging way.

2) people could chose from a variety of representational styles, without
necessarily sacrificing interoperability. Specialized formats could be
created to satisfy requirements from various communities (e.g. the WSDL

what do you think about this? which document would you recommend as (a
starter for) the DAML-S core/essence document ?

kind regards,

[1] Marta Sabou, Debbie Richards, and Sander van Splunter: An experience
report on using DAML-S. In The Proceedings of the Twelfth International
World Wide Web Conference Workshop on E-Services and the Semantic Web (ESSW
'03). Budapest, 2003 [http://www.iids.org/publications/essw03.pdf]

[2] Lei Li and Ian Horrocks. A software framework for matchmaking based on
semantic web technology. In Proc. of the Twelfth International World Wide
Web Conference (WWW 2003), pages 331-339, 2003.

[3] Dan Wu, Bijan Parsia, Evren Sirin, James Hendler and Dana Nau:
Automating DAML-S Web Services Composition Using SHOP2. ISWC-2003

[4] Concurrent Execution Semantics for DAML-S with Subtypes, Anupriya
Ankolekar, Frank Huch, Katia Sycara, The First International Semantic Web
Conference (ISWC), Sardinia (Italy), June, 2002.

[5] McDermott D., posting "DAML-S formal

Joachim Peer
Research Assistant
MCM Institute, University of St. Gallen
Blumenbergplatz 9, 9000 St. Gallen, Switzerland
Phone: ++41 (0) 71 224 3441, Fax: ++41 (0) 71 224 2771
Received on Saturday, 20 September 2003 11:31:02 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:12 UTC