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

On Saturday, September 20, 2003, at 11:30  AM, Joachim.Peer@unisg.ch 
wrote:

> hi all,
>
> i was wondering what can be considered the "semantic essence" of 
> DAML-S,

Which part?

> and i was also wondering whether DAML-S/Semantic Web Service 
> Description
> could be decoupled a bit from DAML+OIL.

It a way, it already is and has always been.

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

Drew McDermott has posted an alternative surface syntax which is 
designed to mitigate some of these problems. We'll see how much we can 
safely and naturally represent with OWL.

> * Usability issues (personal taste): DAML+OIL is tied to to RDF
> serialization.

OWL has alternative syntaxes (even xml ones). OWL-S will almost 
certainly have an alternative surface syntax.

>  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

This was a very strong motivation for moving to Classes as Instances.

The trade off, of course, is trying to stay with the general course of 
Semantic Web development and standardization.

> So, we have the following situation:
>
> a) surely everything can be represented somehow by DL ontologies, and
> DAML-S does just that.

Uh. That seems false to me, unless you mean, "some representation can 
be encoded in" a la how DRS encodes more complex logical formulae in 
plain RDF. Not the most useful sense of "able to represent", IMHO.

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

It really really depends on the class of retrieval and compositoin 
problems. Also on the DL in question (we can pretty much presume OWL 
DL, which, as SHION, is a rather expressive DL, but it's by no means 
even remotely the most natural one for, say, composition tasks. Some 
varient of ALCreg (ACL + a set of role constructors) is the standard 
choice).

But, I pick the nits: Suffice to say for most folks, what you say is 
quite true.

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

There is also some work using an ALCreg reasoner for AI Planning. But 
again, I nit.

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

Some of it isn't a technical justification, but an historical one. If 
you read some of the, say, 2 year ago presentations on DAML-S, you'll 
see mention of DAML-L (for "daml-logic/rules") that was anticipated to 
have come along by now and provided enough expressiveness for our 
desires.

Given some of the layering issues already coming out of OWL and RDF, 
some of the game plan might have to me more radically revised than was 
hoped for.

A semi-technical justification is to try to exploit what we all hope to 
be a wave of tools for OWL.

> I.e. why do i deal with the cumbersome aspects of
> DAML+OIL when DAML+OIL reasoning will not solve my problems?

Funding? :)

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

This is a bit trickier to figure out than one might expect.

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

It's not only been proposed, but is somewhat underway. You might also 
look to the SWSI and SWSI-L effort, as they're (we're) starting from a 
somewhat fresher and blanker slate.

I guess the cheering word is pretty much, "Yes, we agree and are trying 
to make something like this happen".

Cheers,
Bijan Parsia.

Received on Saturday, 20 September 2003 15:21:15 UTC