W3C home > Mailing lists > Public > www-ws@w3.org > May 2003

Re: process:sameValues redefined

From: Saied Tazari <Saied.Tazari@zgdv.de>
Date: Fri, 23 May 2003 10:03:30 +0200
Message-ID: <3ECDD5D2.9040505@zgdv.de>
To: www-ws@w3.org

Drew McDermott schrieb:
 >    From: Saied Tazari <Saied.Tazari@zgdv.de>
 >
 >    regarding the issue raised in
 >    http://lists.w3.org/Archives/Public/www-ws/2003Mar/0019.html, I would 
like
 >    to make a suggestion for enhancing the concept behind 
'process:sameValues'.
 >      According to my idea, we may express a statement like (cp.
 >    http://www.daml.org/services/owl-s/0.9/CongoProcessDataFlow.owl):
 >
 >       <process:sameValues rdf:parseType="Collection">
 > 	<process:ValueOf process:atClass="#FullCongoBuy"
 > 			 process:theProperty="#fullCongoBuyBookName"/>
 > 	<process:ValueOf process:atClass="#LocateBook"
 > 			 process:theProperty="#bookName"/>
 >       </process:sameValues>
 >
 >    this way (the new property and class names are supposed to come from the
 >    'process' ontology):
 >
 >       <process:dataFlow>
 > 	<process:ValuePipe>
 > 	  <process:source>
 > 	    <process:ValueOf process:atClass="#FullCongoBuy"
 > 		 process:theProperty="#fullCongoBuyBookName"/>
 > 	  </process:source>
 > 	  <process:sink>
 > 	    <process:ValueOf process:atClass="#LocateBook"
 > 			   process:theProperty="#bookName"/>
 > 	  </process:sink>
 > 	  <process:pipes rdf:resource="&process;allValues"/>
 > 	</process:ValuePipe>
 >       </process:dataFlow>
 >
 >    This would make it possible to define another alternative for
 >    'process:pipes', namely "&process;someValues" which would solve my 
problem
 >    with restricting input depending on output.
 >
 >    Could this be used as an initial idea for enhancing DAML-S in terms of
 >    dealing with data flow?
 >
 > Yes, it could.

Hopefully, something similar to the above suggestion will be adopted by 
DAML-S so that I can keep conformed to DAML-S.  The above suggestion means 
that in addition to the new class 'ValuePipe' and the new properties, 
'sameValues' is no more a property but an instance of an enumeration class 
where this enumeration has two more instances, namely 'someValues' and 
'oneValue'.

 >    ...
 >    P.S. I wonder if we could rewrite the above in the following 
abbreviated form:
 >
 >       <process:dataFlow>
 > 	<process:ValuePipe>
 > 	  <process:source rdf:resource="#FullCongoBuy.fullCongoBuyBookName"/>
 > 	  <process:sink rdf:resource="#LocateBook.bookName"/>
 > 	  <process:pipes rdf:resource="&process;allValues"/>
 > 	</process:ValuePipe>
 >       </process:dataFlow>
 >
 > I take it the innovation here is the use of dot-notation to indicate
 > class.property relationships more concisely than RDF allows.
 >
 > Well, we're pretty much operating in a gray zone, where we're
 > apparently using RDF syntax, but in ways that don't really obey the
 > intended meaning.  The dot notation may go too far, but it's a matter
 > of taste.

Maybe I should discuss this notation within RDF community.  Nevertheless, I
would like to add the following: if we define 'ND-Name' as an XML-name 
(http://www.w3.org/TR/REC-xml#NT-Name) minus . and give this special 
meaning to dots connecting names to each other, we will have the needed 
clarification.  The simple idea is that with each name we identify some 
resource and a dot connecting the name with another name would address the 
value of the property named by the second name.  If the first resource was a 
class then the property is one of those adopted by that class, but if it is 
an instance then the property is one of those adopted by the class from 
which the last resource is an instance.

 > When you're designing these notations, keep in mind that it may be
 > difficult to say exactly what they mean.  LocateBook is a _class_, to
 > wit, the class of all its execution instances.  So when you talk about
 > LocateBook.bookName, you mean the value of bookName on a particular
 > instance of that class.  In particular, when used in a sameValues or
 > ValuePipe context, it means "the instance of this class that is part
 > of the same execution instance that supplies
 > FullCongoBuy.fullCongoBuyBookName."  Otherwise, you would get
 > nonsensical assertions about someone's FullCongoBuy last week
 > providing the input to my LocateBook this week.  There is no way to
 > infer this constraint from the RDF semantics, so you have to spell out
 > how these instance equalities are extracted from an arbitrary
 > occurrence of ValuePipe.

I understand the point, but I thought that with

<rdf:Description rdf:about="#MySequence">
   <process:dataFlow>
     <process:ValuePipe>
       <process:source>
         <process:ValueOf process:atClass="#MyFirstStep"
            process:theProperty="#anOutputOfMyFirstStep"/>
       </process:source>
       <process:sink>
         <process:ValueOf process:atClass="#MySecondStep"
             process:theProperty="#anInputOfMySecondStep"/>
       </process:sink>
       <process:pipes rdf:resource="&process;#someValues"/>
     </process:ValuePipe>
   </process:dataFlow>
</rdf:Description>

we are saying that for the class 'MySequence' (and I understand by that 
'forall instances of MySequence') holds that the value assigned to the 
property 'anInputOfMySecondStep' of an instance of 'MySecondStep' must be a 
subset of the value provided for the property 'anOutputOfMyFirstStep' of an 
instance of 'MyFirstStep'.  An instance of 'MySequence' deals with only one 
specific instance of 'MyFirstStep' and one specific instance of 
'MySecondStep' and this would solve the problem.

Regards,

-- Saied
Received on Friday, 23 May 2003 04:03:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:42 GMT