- From: Bijan Parsia <bparsia@isr.umd.edu>
- Date: Thu, 17 Jun 2004 08:38:06 -0400
- To: Daniel Elenius <daele@ida.liu.se>
- Cc: public-sws-ig@w3.org
On Jun 17, 2004, at 5:34 AM, Daniel Elenius wrote: >> 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? > > If the Profile is a black-box view of a service, and the process a > glass-box view, what is the purpose of the SimpleProcess class? The perennial question. > Is it really needed? Isn't the purpose of SimpleProcess to provide a > "black-box" view of a CompositeProcess? Actually, it can provide an abstraction over a set of processes, be they atomic or composite. SimpleProcesses can be composed with other processes (profiles can't). OTOH, for many purposes SimpleProcesses really want some of the stuff that goes in a profile (e.g., templates where you want a cost function associated with the "holes"). You can work around this, I suppose, by associating SimpleProcesses with Profiles. Ick. Workable, but not the happiest. Cheers, Bijan Parsia.
Received on Thursday, 17 June 2004 08:38:06 UTC