- From: Terry Payne <trp@ecs.soton.ac.uk>
- Date: Tue, 15 Jun 2004 22:41:45 +0100
- To: David Martin <martin@AI.SRI.COM>
- Cc: public-sws-ig@w3.org, Daniel Elenius <daele@ida.liu.se>
David, > Terry Payne wrote: > >> Daniel, >> I am embarrassed to say that you are absolutely right. I was >> convinced that this property was in OWL-S; but looking (briefly) at >> the previous versions, I can't find it. > > hasProfile was removed from Process.owl, a while back, because we > wanted to allow for the possibility / likelihood that a Process might > have several different profiles, and to emphasize that, in general, > the author of a process needn't know about or keep track of the > profiles used to advertise the process. This sounds bizarre, as one could argue that a profile provides the black-box representation of a service (in addition to operational / non-functional parameters), whereas the process model provides a glass box view. As a consequence they are intimately related, thus necessitating that the author of a process to be aware of or keep track of the related profiles. In fact, what is the utility of having a profile that differs (and possibly contradicts) the process model, other than perhaps to optimise the behaviour of a given mechanism for a given matchmaker or discovery service? In fact, if there are no non-functional parameters, then one could expect that a profile represents a candidate subset of parameters required to execute a service (thus necessitating several profiles to represent alternate candidate execution pathways through a service). All the more reason to maintain the relationship between profile and process. > Of course having one or more instances of hasProfile would not > preclude this possibility, but we felt that the use of hasProfile > might be confusing (that is, it might imply to some users that the > valid advertisement of a process is limited to the specified > Profile(s). There was also a concern that it might create somewhat of > a maintenance burden; that is, when and where would the hasProfile > instances be maintained, for a given process? Finally, the > information would be duplicative of relationships already captured > elsewhere (in Service instances). Not necessarily. It may be possible to represent several processes within a single model, relating to different profiles. We already have the has_process in the profile that can be used to provide these links, but this property has no defined inverse. If there is a credible argument against concurrently maintaining the profile and process, surely we should remove this as well by your same argument? > >> This does raise some interesting questions: >> 1) profile:has_process >> This is a functional property, pointing to a "Process". Should this >> be functional, or may we want a profile to point to several >> processes (and what would this mean)? > > We've always made the assumption that a profile is meant to represent > a particular process. I think this simplifies some things, such as > maintenance of the Profile in the face of process version changes. Fair enough. A profile can refer to only one process, whereas a process may be referred to by several profiles. In which case, what would be the problems raised if we created a "has_profile" which simply was the inverse of has_process? We want to consider now that we are changing the definition of a profile, that it advertises a single process (though this may be a composite process). Am I right in assuming that it would be legal to have several such processes in a service, and that there could be several such profiles, each referring to the different processes? In which case, is the profile really advertising the service itself? > >> 2) inferring the profile given the process >> If we have a full OWL-S model in some RDF store or reasoner, is it >> possible to identify the profile given a reference to the process >> model? Because of the "has_process" property, we can go the other >> way round (and yes, this means we can do tricks with RDQL), but, for >> example, could we generate the class of all profiles for a given set >> of processes? This would be necessary if, for example, we wanted to >> know the different non-functional parameters (attached to the >> profile) that related to a given composition of processes? > > The "standard" answer is to look for all the Service instances that > mention a given process, and then you can identify the related > profiles because they are mentioned in the Service instances. The > idea is that the Service instance bundles together a process with 0 or > more profiles that the Service provider considers to be valid > advertisements, and also with 1 or more groundings that the Service > provider supports. Think about the following usage model: 1) requester defines the service requirement as a profile Pr 2) submits this to get candidate matches P'1...P'n 3) requester inspects P'1..P'n, and related process models p'1...p'n 4) requester then invokes one of these. The properties all work (profile to process) fine. But... ...what if a reasoner, for example, stores all the processes p'1...p'n in an OWL cache, and then looks for the class of all composite processes that satisfy the requesters exact requirements. Each process model may be represented by different profiles. How can we identify the appropriate profile (from the list P'1...P'n) just from this inferred class? This may be necessary for additional inferences about non-functional properties. > We may well revisit these issues when it comes time to bring OWL-S > up-to-date with WSDL 2.0. Hmmm, I want to say "fair point", but these aren't really grounding issues. I'm not savvy with WSDL 2.0, and thus don't really understand how it will effect semantic discovery... Terry > > > -- David > >> Terry >> On 15 Jun 2004, at 08:13, Daniel Elenius wrote: >>> Regarding your figure: There is no hasProfile property in the >>> current OWL-S. >>> >>> /Daniel >>> >>> Terry Payne wrote: >>> This has my vote as well! >>> >>> I've attached a diagram that illustrates how processes, profiles >>> and services are connected, and it is a bit of a tangled web... >>> >>> Terry >>> >>> >>> >>> >>> >>> <image.tiff> >>> >>> >>> >>> On 13 Jun 2004, at 16:57, Drew McDermott wrote: >>> >>> >>> >>> >>> >>> [David Martin] >>> >>> I'd like to collapse ProcessModel and Process, in Process.owl. I >>> doubt >>> if anyone will object to this, in principle, but I think it should >>> be >>> mentioned "for the record". It has been discussed, now and then, >>> in the >>> past. >>> >>> ProcessModel has always been a simple class which points to a >>> Process >>> and also to a "process control model". Of course, >>> ProcessControlModel >>> is just a placeholder; no one has ever done any work on it (that >>> is, not >>> in the context of OWL-S). (But note that I think there's some >>> important >>> work to be done in this area; it's just that it's not a near-term >>> priority.) >>> >>> >>> I never understood what a process-control model was supposed to be, >>> so >>> I agree with your proposal. >>> >>> -- Drew >>> >>> >>> -- -- Drew McDermott >>> Yale Computer Science >>> Department >>> >>> >>> >>> >>> >>> _____________________________________________________________________ >>> __ >>> Terry R. Payne, PhD. | >>> http://www.ecs.soton.ac.uk/~trp/index.html >>> AgentLink III Co-coordinator | AgentLink III - >>> http://www.agentlink.org >>> University of Southampton | Voice: +44(0)23 8059 8343 [Fax: 8059 >>> 2865] >>> Southampton, SO17 1BJ, UK | Email: terry@acm.org / >>> trp@ecs.soton.ac.uk >>> >>> >>> >>> >>> >>> -- >>> Daniel Elenius >>> Usable Ubiquitous Research Group (U2) >>> Department of Computer and Information Science >>> Linköping University, Sweden >>> Tel: +46 13 28 56 06, Fax: +46 13 142 231 >>> <mime-attachment> >> ______________________________________________________________________ >> _ >> Terry R. Payne, PhD. | >> http://www.ecs.soton.ac.uk/~trp/index.html >> AgentLink III Co-coordinator | AgentLink III - >> http://www.agentlink.org >> University of Southampton | Voice: +44(0)23 8059 8343 [Fax: 8059 >> 2865] >> Southampton, SO17 1BJ, UK | Email: terry@acm.org / trp@ecs.soton.ac.uk > > _______________________________________________________________________ Terry R. Payne, PhD. | http://www.ecs.soton.ac.uk/~trp/index.html AgentLink III Co-coordinator | AgentLink III - http://www.agentlink.org University of Southampton | Voice: +44(0)23 8059 8343 [Fax: 8059 2865] Southampton, SO17 1BJ, UK | Email: terry@acm.org / trp@ecs.soton.ac.uk
Received on Tuesday, 15 June 2004 17:42:00 UTC