From: Terry R. Payne (terryp@cs.cmu.edu)
Date: 10/02/01
Marja, Though the distinction was made between requestedBy/providedBy and role in V0.5, there is no real reason for this, and in V0.6 (which should be released shortly) we have made both requestedBy & providedBy subclasses of role. The definitions of each however extend the definition of role, by explicitly stating whether the actor is a service requester or a service provider (each of which is subclassed from actor) - as in DAML-S V0.5. <rdf:Property rdf:ID="role"> <rdfs:domain rdf:resource="#FunctionalAttributes" /> <rdfs:range rdf:resource="#Actor" /> </rdf:Property> <rdf:Property rdf:ID="requestedBy"> <rdfs:subPropertyOf rdf:resource="#role" /> <rdfs:range rdf:resource="#ServiceRequester" /> </rdf:Property> <rdf:Property rdf:ID="providedBy"> <rdfs:subPropertyOf rdf:resource="#role" /> <rdfs:range rdf:resource="#ServiceProvider" /> </rdf:Property> The idea here is to provide specific semantics for two the subproperties of actor, to distinguish from any third-party actors that may be involved with the service. At the moment, processes are not annotated with role information; there is an implicit assumption that transactions are between two parties only, and that the flow of information between the service provider and service requester based on whether parameters are 'input' or 'output'. However, this will change, either with the explicit annotation of role within a process, or through the definition of the grounding (most probably the latter - though the jury is out on this one right now). It is also important to maintain symmetry between advertisements and requests (and hence ServiceProviders and ServiceRequesters) right now, as we are trying to be agnostic regarding the type of discovery service and hence reasoning that may be done. For example, a "Classified Ads" based discovery service may be used, where service requesters submit desired services, and service providers then look these up and contact the requester directly. This contrasts with the more obvious yellow-pages styled discovery service. A prototype of the new Profile can be found at [1]; this however may change before the formal release of DAML-S V0.6. [1] http://www.daml.ri.cmu.edu/ont/DAML-S/Profile.daml Regards, Terry _____________________________________________________________________ Terry R. Payne, PhD. | http://www.cs.cmu.edu/~terryp/index.html CMU, Robotics Institute | Voice: (412) 268-8780 Fax: (412) 268-5569 Pittsburgh, PA 15213 | Email: terry@acm.org or Terry.Payne@cmu.edu -----Original Message----- From: owner-daml-services@mail.daml.org [mailto:owner-daml-services@mail.daml.org]On Behalf Of marja.j.phipps@gd-is.com Sent: Monday, October 01, 2001 4:02 PM To: daml-services@daml.org Subject: role vs. requestedBy or providedBy I do not understand the distinction between role and requestedBy or providedBy. The Profile specification defines the role property as a link between the profile and an actor, and then states that the actor is the entity that provides the services or makes the request. The requestedBy and providedBy properties are defined as similar but distinct from the role. Is the intent of the role property to allow the requestedBy or providedBy properties to take on "job context" information, e.g. a "user" (actor) executing an "administration" function (role). If so, wouldn't one subproperty requestedBy or providedBy? Clarification or examples would be much appreciated. Thanks - Marja
This archive was generated by hypermail 2.1.4 : 03/26/02 EST