Re: DAML-S service definition, attributes

I had replied privately to Edward on this message, but since it seems
to have made the mailing list, I share my answer with everybody.

 > According to the comments in the Profile ontology, Isn't the correct way to
 > define a Service Profile to use service:OfferedService or
 > service:NeededService, rather than just service:ServiceProfile?

The idea behind DAML-S is that there is no distinction between a
request and an advertisement.  Both of them describe a service.  The
distinction is in the way the profile is used.  For this reason we
defined properties at the level of service:ServiceProfile that were to
be inherited by OfferedService and service:NeededService.  The way to
use them is to specify an instance of NeededService when you want to
create a request, and an instance of OfferedService for an
advertisement.  

Note though, that this distinction is deprecated in the forthcoming
0.7.  The reason for that is that we decided that the service profile
should only describe the functionality of a service. The way the
profile is used (whether it is used to request a service, or to
advertise a service) is not specified in the profile itself, but it
should be specified in the interaction with the registry.  This means
for example, that a "DAML-S aware UDDI" will have in its API an
advertise message and a request message that specify what the registry
will do with the profile.

 > Expanding this question to the whole DAML-S ontology, does a UML diagram (or
 > something similar) exist that describes in detail all the possible
 > relationships?

As David Martin said in his answer, there is no DAML_S specific tool.
There are some DAML tools that may help you such as DUET and VisioDAML
available from the DAML.org tools page.

I hope that my answers helped you (and others),

--- Massimo

Received on Wednesday, 14 August 2002 11:12:53 UTC