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

RE: Modeling complex results as logic formulas, or as composite p rocesses

From: Camara Melgosa, Javier <JCAMARA@softwareag.es>
Date: Fri, 17 Dec 2004 11:23:27 +0100
Message-ID: <1C8C5F8C3092D711BA7900B0D0FEBDBA029394C9@sag-es.es.sag>
To: "'drew.mcdermott@yale.edu'" <drew.mcdermott@yale.edu>
Cc: public-sws-ig@w3.org

Right now I am working only with retrieval services (i.e. those pure
functional, that just return information without changing the world), and
thus I am focusing only in output and conditions both for discovery and
composition, ignoring effects. So I included in the profiles of the existing
services OutputBindings with ValueFunctions like "IsWorkingTime(Input Time)"
and "IsOnVacation(Input Person,Input Date)", being IsWorkingTime and
IsOnVacation a concept meaning a Function. The requesting profile specifies
a OutputBinding with a ValueFunction of "IsWorking(Input Person, Input
Time)", and through the equivalence between IsWorking(), IsWorkingTime() and
IsOnVacation(), my proof of concept is (now) able to resolve the profile.
The question is whether other "OWL-S resolvers" will interpret the same or
not.

I hope "OWL-S resolver" is a better term than "OWL-S processor", by which I
meant something having planning capabilities; I aim to having a component
that receives a OWL-S profile and searches in a base of OWL and OWL-S
definitions in order to find out how to resolve the needs of that profile,
returning the precise instructions for doing so.

When I start handling services with permanent effects (e.g. create or modify
data), then I will start taking service effects into account. I hope this is
the proper way of modeling things.

Thank you very much for your comments

> -----Mensaje original-----
> De: Drew McDermott [mailto:drew.mcdermott@yale.edu] 
> Enviado el: jueves 16 de diciembre de 2004 20:43
> Para: Camara Melgosa, Javier
> CC: public-sws-ig@w3.org
> Asunto: Re: Modeling complex results as logic formulas, or as 
> composite proce sses
> 
> 
> 
> > [Javier Camara]
> >  
> > I have an scenario in which want to find out whether a person is 
> > working at a given date and time, i.e. 
> isWorking(Person,Time) . There 
> > are two available services for performing this, one telling 
> me whether 
> > isWorkingTime(Time) and other telling whether 
> > isOnHoliday(Person,Date). Thus, one can say that
> >  
> >         isWorking(Person,Time) == isWorkingTime(Time) & not
> > isOnHoliday(Person,Date(Time) )
> >  
> > Now, how would it be better to model this in OWL-S? Assuming the 
> > existing services have OWL-S descriptions including no 
> effect and with 
> > respective outputs of isWorkingTime(Time) and 
> > isOnHoliday(Person,Date), I can see at least three options:
> >  
> > 1) In the requester profile,specify a required output of
> > isWorking(Person,Time) , and then define using OWL that
> > isWorking(Person,Time) is equivalent to isWorkingTime(Time) & not
> > isOnHoliday(Person,Date(Time) )
> >  
> > 2) In the requester profile, directly specify a required output of
> > isWorkingTime(Time) & not isOnHoliday(Person,Date(Time) )
> >  
> > 3) Have the requester profile specifying an output of 
> > isWorking(Person,Time), and create a new composite process 
> description 
> > whose output is isWorking(Person,Time) and whose model 
> invokes the two 
> > existing services in a proper way
> >  
> > I would choose option 1) , but it looks to me that most OWL-S 
> > processors would handle better option 3). Any opinion on 
> this? Would 
> > option would be better? Are there other options?
> 
> I like option (1) as well, although I would try to be a bit 
> more precise in specifying the outputs and effects.  What is 
> requested is a service such that invoking it will produce a 
> boolean-literal output B with effect "knows-value-is(client, 
> isWorking(Person,Time), B)." However, that doesn't address 
> your main question.
> 
> I don't think an Owl-S processor's job is to figure out how 
> to achieve the requested goal.  You need a planner with a 
> reasoning engine clever enough to infer that if P & Q <-> R, 
> then one way to achieve 
> KG = knows-value(client, R) is to achieve 
> 
>         knows-value-is(client,P,true) & knows-value-is(client,Q, true)
>         OR
> 	knows-value-is(client,P,false)
> 	OR
> 	knows-value-is(client,Q,false)
> 
> (omitting several important details).  If we schematize this as 
> 
>        KG = ((KG1 & KG2) OR KG3 OR KG4)
> 
> then the planner must figure out that service 1 will achieve 
> KG1 or KG3, and service 2 will achieve KG2 or KG4, after 
> which it will have achieved KG.
> 
> -- 
> 
>                                          -- Drew McDermott
>                                             Yale University
>                                             Computer Science 
> Department
> 
Received on Friday, 17 December 2004 10:20:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 March 2008 00:10:59 GMT