RE: DAML-S Ontologies inconsistencies??

I have been also trying to understand and use DAML-S and here are a few more
uncertain issues (to me anyhow), in no particular order, which I would
appreciate some comments and clarifications, in case I am on the wrong track
:

· How does a sub-process refer to another service? via request service
profiles?, or does its input/output/pre-conditions/effects will be used to
search for a service profile matching that sub-service?
· How execution monitoring defines input and output parameter routing in and
out of sub-processes? The new DAML-S 0.6 leaves the 'process control' out.
Will these be defined as part of the 'process' ontology?
· If an agent has a service or creates a service at run-time (in a format
internal to that agent), is there any API which allows turning this local
description into a DAML-S? (Jena is a parser; what I am thinking is a to do
the inverse; i.e. take a service description in an agent and create the
DAML-S equivalent using that API).
· Effects V post-conditions : Are these the same? Where and how constraints
are defined? E.g. from an example of LARK research, a "sort" service
specifies input and output as list of numbers; the output adds the
constraint that the list will be ordered. Also. Am I right that from the
LARK example, DAML-S will allow for intelligent matchmaking to take place;
e.g. a request for a sorting integers will find a service which sorts real
numbers?
· When DAML-L (DAML-logic) comes out, how will it be used to add
pre-conditions to the DAML-S objects? At the moment, a pre-condition
parameter has a range (which is left unspecified - i.e. the root of DAML/OIL
object hierarchy). Will these logical constraints and rules be defined as
DAML/OIL objects?
. The profile properties : some properties apply to an offered service,
others refer to a needed-service. E.g. qualityOf Service (fastest, cheapest)
applies to a needed-service and not offered-services.
· EXCEPTION Handling : will process model be used for this? and how?


Many thanks
Manooch Azmoodeh
BTexact Technologies, UK

-----Original Message-----
From: Charlie Abela [mailto:abcharl@maltanet.net]
Sent: 16 February 2002 16:32
To: www-ws
Subject: DAML-S Ontologies inconsistencies??
Importance: High


Hi All.

I looked at the DAML-S version
0.6 and noticed what might
seem to be inconsistencies in
the way that these ontologies
are expressed.
Apart from the fact that the
BravoAir and Congo ontologies
are not displayed correctly by
IE, due to some syntax errors
that they contain, they are
somewhat defined differently.
In the BravoAir process
ontology there is an instance
definition for the service
process which the CongoBuy
process does not define. Also
in the BravoAir definition
there is a reference to
topLevelProcess and to
isImplementedBy constructs.
Where are these defined in the
Service ontologies?
And why is it that these
examples still use rdfs:Class
and not the daml:Class which
is now correctly used in the
base ontologies?

I was hoping that this new
version would bring about some
kind of standardization in the
way that these WS ontologies
are expressed, but it seems
that there still remains
ambiguity in the way one can
define these ontologies.
Correct me, if I'm wrong.

With the advent of the OWL
language it seems that
interest is getting lost in
DAML and derivatives. Should
people place the semantic web
idea on the hold and wait for
this new language to hopefully
surface?

Charlie

Received on Monday, 18 February 2002 05:08:08 UTC