Re: question: named vs. anonymous classes in creation of conditional outputs and effects

Hi!

>>   As far as  understand there are 2 ways to create conditional
>>   outputs and effects: using anonymous subclasses (via the
>>   use of DAML+OIL "Restriction")and using explicit naming of the
>>   "ConditionalOutput" and "ConditionalEffect" subclasses, respectively.
>>   Can anybody explain in some details which is the difference between
>>   them? Which is the advantage of using one instead of the other?
>>   When should we use one and when should we use the other?

> They have exactly the same meaning, except that named conditions can
> be referred to elsewhere and anonymous conditions cannot.

Consider a top level process which is a composite process, composed of a
sequence whose components are two atomic process, CheckFlight and PayFlight.
The CheckFlight has as inputs departureLocation and arrivalLocation, and a
conditional output FlightID (a flight ID in case there is a flight
(FlightExists - a Condition) between departureLocation and arrivalLocation).
This conditional output will serve as an input for the PayFlight process.
This conditional output is declared using owl "Restriction" in the following
way:

<rdf:Property rdf:ID="Air1FlightExistsOutput">
  <rdfs:subPropertyOf rdf:resource="&process;#output"/>
  <rdfs:domain rdf:resource="#CheckFlight"/>
  <rdfs:range>
    <owl:Class>
       <rdfs:subClassOf rdf:resource="&process;#ConditionalOutput"/>
       <rdfs:subClassOf>
          <owl:Restriction>
            <owl:onProperty rdf:resource="&process;#coCondition"/>
            <owl:allValuesFrom rdf:resource="#FlightExists"/>
          </owl:Restriction>
       </rdfs:subClassOf>
       <rdfs:subClassOf>
         <owl:Restriction>
           <owl:onProperty rdf:resource="&process;#coOutput"/>
           <owl:allValuesFrom rdf:resource="#FlightID"/>
         </owl:Restriction>
      </rdfs:subClassOf>
    </owl:Class>
 </rdfs:range>
</rdf:Property>

This conditional output being defined using anonymous classes, means that
it is not possible te refer the output of the CheckFlight to the input
of the PayFlight? Or is it possible to refer the output of the CheckFlight
to the input of the PayFlight in the following manner:

  <rdf:Description rdf:about="Air1_Process">
    <process:sameValues rdf:parseType="Collection">
      <process:ValueOf process:atClass="#CheckFlight" process:theProperty="#Air1FlightExistsOutput"/>
      <process:ValueOf process:atClass="#PayFlight" process:theProperty="#flightID"/>
    </process:sameValues>
  </rdf:Description>
?
When you said that the named conditions can be referred to elsewhere and
anonymous conditions cannot, did you refer to such a situation presented above?


>>   To the DAML-S team:
>>   In the http://www.daml.org/services/owl-s/0.9/CongoProcess.owl, in
the
>>   following property declaration:

>>   <rdf:Property rdf:ID="nameBookInCatalogue">
>>     <owl:domain rdf:resource="#BookInCatalogue" />
>>   <owl:range rdf:resource="http://www.w3.org/2000/10/XMLSchema#string"
/>
>>   </rdf:Property>

>>   the property domain shouldn't be "#BookInCatalogueP" instead
>>   "#BookInCatalogue"?

> I am a little shaky on what's going on here myself, so perhaps another
> DAML-S person will correct what I'm going to say, but here goes:

> BookInCatalogue is a process (the process of looking for the book in

If BookInCatalogue is a process shouldn't it be declared as a process
in the CongoProcess file?(there is no declaration of BookInCatalogue
in the http://www.daml.org/services/owl-s/0.9/CongoProcess.owl)

> the catalogue).  nameBookInCatalogue is a property of that process,
> namely, the name of one of the books that were found, if any were.
> BookInCatalogueP is a condition, represented as a set of process
> instances in which at least 1 book was found, i.e., those process
> instances for which the number of nameBookInCatalogue's is >= 1.

> The idea is that if a process instance is in BookInCatalogueP, then
> that's an occasion when the process is successful, and if it isn't,
> then that instance is an occasion when the process is unsuccessful.

> In other places we use other notions of what a condition is, which
> just reflects the difficulty of expressing conditions in the DL
> framework we're working within.

Thank you,
titi

Received on Wednesday, 21 May 2003 16:03:47 UTC