Re: Multiple inputs and multiple outputs

Hi Yuzhong -

Thanks for your comments.  I will not address all of them here, but I
want to clarify the status of the 1.0 files, which you mention.

Some of your points under "More comments" point out incompleteness or
inconsistency in OWL-S version 1.0.  Yes, there are many ways in which
the 1.0 files are incomplete or inconsistent, because they have not yet
been released.  Please be aware that these files are under development,
and still have much work to be done on them before the release is announced.

Regards,
David Martin

Yuzhong Qu wrote:

> [Drew McDermott wrote]
> 
> 
>>   [Yuzhong Qu" <yzqu@seu.edu.cn>]
>>   As we know, a process in DAML-S can have multiple inputs and multiple (conditional)outputs.
>>   (From http://www.daml.org/services/owl-s/1.0/Process.owl
>>   http://www.daml.org/services/owl-s/0.9/Process.owl)
>>
>>   1. In the case of  multiple inputs
>>
>>       It seems to me that the process specified should take multiple
>>       inputs satisfying corresponding type constraint.
>>       Am I right?
>>
>>Yes.
>>
>>       But, how do you know the exact number of inputs? You just know
>>       what you know, maybe there is another statement about a new
>>       input (another input may be specified in other place) due to
>>       the openness of the Semantic Web (it's not a closed world).
>>
>>Good point.  We really need a fixed list of inputs and another of outputs.
>>
>>[It would be interesting denial-of-service attack to tell a service
>>that it needed another input and have it then stall because no one is
>>supplying it. :)  Of course, this scenario would depend on a service
>>using an open RDF spec as the actual code that it uses when running,
>>which is not likely.  More likely, potential clients would be the ones
>>to run into trouble.]
> 
> 
> Thanks for your understanding. 
> Recently, I tried to design a new structure to resolve this issue.
> 
> 
> 
>>   2.  In the case of  multiple outputs
>>
>>       What's the intended meaning?
>>
>>Putting aside the issue of conditional outputs for a moment, if the
>>process has outputs A,B,C, it just means (in essence) that the output
>>is a record whose fields are called A, B, and C.
> 
> 
> It sounds very good. 
> 
> Does these fields are distinguished by the output names(property name, e.g. congoOrderShippedOutput)?
> 
> 
> 
>>A conditional output might not even exist, so you can picture it has
>>always being there, but having a Null value when the condition isn't
>>true.
> 
> 
> In the case of two conditional output, suppose two (co)Conditions are satisfied in a situation, there should exist two parts in the output? (or two outputs?) 
> 
> Further, the overlaping between two (co)Conditions is allowed? or this kind of usage is discouraged in the design stage?
> 
> 
> 
> More comments:
> 
> 1. Multiple inputs and multiple outputs in the profile
> 
> On the one hand, a service may have multiple processes, and a process may have inputs and outputs. One the other hand, a profile may have multiple inputs and outputs.
>  
> But, there is no mechanism to group the related profile:input(s) and/or profile:input(s). Without such grouping mechanism, it's hard for the registry's algorithm to match the request with the offers of service providers to identify which of them is the best match. One may argue that it can be done through looking up the inputs/outputs within process through the refersTo property. I think this is another isuue although it's somewhat related to this isuue.
> 
> 2. ProcessPowerSet  
> 
> (This issue is related with the discussion entitled "PowerSet  in DAML-S 0.9")
> 
> There is no definition of ProcessPowerSet in Process.owl (version 1.0), but the the has_process is defined to have ProcessPowerSet as its range:
> 
> <owl:FunctionalProperty rdf:ID="has_process">
>       <owl:domain rdf:resource="#Profile" /> 
>       <owl:range rdf:resource="http://www.daml.org/services/owl-s/1.0/Process.owl#ProcessPowerSet" /> 
> </owl:FunctionalProperty>
> 
> 3. The range of the hasProces proproty
> (This issue is also related with the discussion entitled "PowerSet  in DAML-S 0.9")
> 
> The hasProces proproty is defined to have the Process class as its range. But, ExpressCongoBuyProcessModel has two processes FullCongoBuy and ExpressCongoBuy (CongoProcess.owl.xml,version 1), which are subclasses/descendants of Process.
> 
> The range of the hasProces perproty should be defined to be the class of all subclasses of Process (with the name ProcessClass, as I suggested before). Any other suggestion?
> 
> 
> 
> 
>>                                             -- Drew McDermott
>>                                                Yale Computer Science Department
>>
> 
> 
> Yuzhong Qu
> Dept.Computer Science and Engineering
> Southest University, Nanjing, China
> http://cse.seu.edu.cn/People/yzqu/en
> 
> 
> 
>

Received on Monday, 29 September 2003 03:01:36 UTC