W3C home > Mailing lists > Public > public-sws-ig@w3.org > June 2004

Re: [OWL-S]: proposal to collapse ProcessModel and Process

From: Terry Payne <trp@ecs.soton.ac.uk>
Date: Tue, 15 Jun 2004 22:41:45 +0100
Message-Id: <CC3BB21F-BF14-11D8-AE20-000A95DA4396@ecs.soton.ac.uk>
Cc: public-sws-ig@w3.org, Daniel Elenius <daele@ida.liu.se>
To: David Martin <martin@AI.SRI.COM>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:13 UTC