Re: Remarks on the white paper "DAML-S: Semantic Markup for Web Services"

From: David Martin (martin@AI.SRI.COM)
Date: 10/29/03

Fabien & Norman -

Thanks (very belatedly) for these comments on the DAML-S 0.9 Technical 
Overview.  Now that we are finalizing OWL-S 1.0, we are in a position to 
  adopt and/or respond to your suggestions/criticisms/questions.  Since 
this might be of educational benefit to the world-at-large, I would like 
to forward this message to, and we can respond to it 
there.  Is that OK?


- Fabien Gandon - wrote:

> Remarks on the white paper "DAML-S: Semantic Markup for Web Services"
>                                 -- Fabien L. Gandon, Norman M. Sadeh
>                                    Mobile Commerce Laboratory
>                                    Carnegie Mellon University
> The following are a few informal comments on the new version of the 
> white paper "DAML-S: Semantic Markup for Web Services".
> 1, As the article tries to systematically make links with other domains 
> and terminologies, one could insert a sentence stating that the 
> matchmaking capabilities and the knowledge bases containing the 
> profiles/service advertisement are sometime respectively called 'yellow 
> pages services' and 'yellow pages'.
> 2, There is not enough emphasis on the necessity and use of an ontology 
> of the types of services (e.g. booking, renting, ordering, etc.) and the 
> domain of the services (e.g., cinema tickets, car, pizza) with its 
> specific concepts and properties (e.g. half price for students, 2 years 
> warranty, deliver at home) that specialize the upper class Service and 
> allow the matchmaking.
> 3, Why is it the case that the Service instance is not simply annotated 
> with domain-dependent ontologies? Why a taxonomy slot and not simply a 
> use of namespaces? Why a categoryName slot instead of using a subtype of 
> service in an ontology and multiple instantiation? This really seems 
> counter-intuitive since all these mechanisms already exist in RDF/S. 
> While we understand the rationale of section 4, we don’t see the point 
> of sub-sections 4.2.6, 4.2.8, 4.2.9 ; these are typically 
> domain-dependent and should be addressed using domain ontologies 
> (identified by their namespaces) and multiple instantiation. Possible 
> links between these ontologies and/or between these ontologies and the 
> Service ontology would be done using subsumption, class equivalence, 
> etc. In our opinion these domain-dependent aspects should be handled 
> independently, thus only part of the profile should be specified and the 
> rest should be left to extensibility and semantic search capabilities.
> 4, There is no reference to the RDF/S version of WSDL not even as 
> "related work" while it seems extremely relevant be it only for the 
> grounding. Advances on WSDL 2.0 should be acknowledged too.
> 5, Section 4.2.4: Failure during the activation of a Web service could 
> have effects too e.g. report misuse of credit card and ban access if 
> wrong PIN. It seems that the effects should really be linked to some 
> stages of the process. Are we missing something here?
> 6, The white paper should also make some links with existing ontologies 
> (time, space, persons, services, etc.) and acknowledge that some content 
> / ontologies already exist.
> 7, In section 5.1, first bullet, when declaring the property 'input', 
> there is no use to overwrite the range since it is the same as the one 
> inherited from 'parameter'.
> 8, Concerning the SimpleProcess, it seems to us that a better labeling 
> would be "AbstractProcess" since this really is what its definition 
> means: we understand it as an abstract  building block of the process 
> model (i.e. it cannot be invoked or grounded) and it has nothing to do 
> with being simple vs. complex or composite.
> 9, Section 7.1: what if a resource can be used exactly X times (e.g. a 
> 10-trip bus pass, right to access a location tracking device 2 times per 
> day), should it be modeled as the capacity of a non 'replenishable' 
> resource ? Also these issues are closely related to security and access 
> rights this would eventually need further details.
> Some typos / formatting details:
> Section 3: "The class service provides aN organizational point of 
> reference (...)"
> Section 6.1 : "XSD" acronym should be introduced when talking about XML 
> Schema data type, and may be it would be good to insert a line insisting 
> on what semantic web frameworks buy us compared to XSD
> Section 7.2 : the acronym "DAML-L" is used without being defined.
> Best regards,
> Fabien and Norman.

This archive was generated by hypermail 2.1.4 : 10/29/03 EST