From: David Martin ([email protected])
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 [email protected], and we can respond to it
there. Is that OK?
Regards,
David
- 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