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

Re: ExpressCongoBuy atomic service description

From: David Martin <martin@AI.SRI.COM>
Date: Tue, 04 Mar 2003 15:55:06 -0800
Message-ID: <3E653CDA.AC41BDED@ai.sri.com>
To: sam@ksl.Stanford.EDU
CC: mits1@cs.umbc.edu, www-ws@w3.org

sam@ksl.Stanford.EDU wrote:

> Mithun,
>
> Sorry for the delay in responding and thanks to Dave for offering a
> response.  I had a different answer :-), which is that the domain
> could be specified at the time the actual service instance is
> defined.  ExpressCongoBuy is a class of processes with a particular
> form.  An instance of that class might be "Bob" express buying "Harry
> Potter and the Sorcerer's Stone" from Congo on a particular day.
> This instance of the process could be defined with the appropriate
> domain specified.

Well, allow me to amend/clarify.  When you specify an instance of ExpressCongoBuy, the instance
specification won't say anything about the domain of congoOrderShippedEffect - not *explicitly*, that
is.  It will implicitly do so, however, simply by creating an instance of congoOrderShippedEffect
that belongs to the "Bob-HarryPotter" instance of ExpressCongoBuy.

However, I don't think the creation of a congoOrderShippedEffect instance at service-instantiation
time addresses the concern expressed by Mithun and others.  I believe their concern is the following:
how does a tool that's responsible for creating an instance of ExpressCongoBuy know which properties
to instantiate?  (The answer is not going to be "instantiate all properties known to have Process as
their domain".) Of course, it may be spelled out in some informal documentation, but  for a tool to
answer that question, it must be indicated explicitly in connection with the definition of the class
ExpressCongoBuy.

This is clearly a matter of service specification *style*, since DAML+OIL is so flexible in this
regard. It may be that the DAML+OIL community will need a style guide with regard to such matters.
My personal style, currently, is to use restrictions on the cardinality properties, within the
process' main definition, to indicate all of its IOPEs, as I mentioned in my previous message.  This
is what's done in FullCongoProcess (at least with respect to inputs).

If there is no objection, I would like to update the example files using this style.

Sheila, please let me know if I'm overlooking something here.

Regards,
David

>
>
> As you can see, there are many ways to work with the DAML-S ontology.
> This is simply another perspective.
>
> Regards,
> Sheila
>
> ===== Original Message =====
>
> David Martin wrote:
>
> Sheila and Mithun -
>
> You are both right.  That is, as Sheila says, we deliberately did not specify a domain for
> congoOrderShippedEffect, so that it could potentially be used with multiple different processes.
> Of course the domain is implicitly "Process", because it's a subproperty of effect.  Similarly
> for congoOrderShippedOutput.
>
> However, it it also true that there is currently nothing that indicates which processes it should
> be used with.  This could be done by specifying a restriction on the property that's associated
> with ExpressCongoBuy.  For instance a cardinality restriction could be used:
>
> <daml:Class rdf:ID="ExpressCongoBuy">
>     ....
>      <rdfs:subClassOf>
>         <daml:Restriction daml:maxCardinality="1">
>         <daml:onProperty rdf:resource="#congoOrderShippedEffect"/>
>     </daml:Restriction>
>             ....
>
> Regards,
> David Martin
>
> Mithun Sheshagiri wrote:
>
> > Hello Sheila,
> >                        Thank you for the reply. I am still wondering how
> > do I bind a particular I/P/O/E to a service if the domain is not
> > specified. Since congoOrderShippedEffect is a part of ExpressCongo,
> > don't we have to bind these somewhere. At what stage should this be
> > happening?
> >
> > peace,
> > mithun
> >
> > sam@KSL.Stanford.EDU wrote:
> >
> > >Hi Mithun,
> > >
> > >Thanks for your question about ExpressCongoBuy.  As you noted,
> > >we did not explicitly define a domain for the properties
> > >property:congoOrderShippedEffect
> > >and
> > >property:congoOrderShippedOutput.
> > >This was done on purpose.  It certainly would not have been
> > >incorrect to have defined a domain, but it was not necessary.
> > >The advantage of not explicitly defining a domain is that it
> > >enables these properties to be used by multiple processes.
> > >For example, the non-express version of CongoBuy could have the
> > >same conditional outputs and effects.  By not defining the domain
> > >explicitly, it enables the use of the properties in the definition
> > >of both processses.
> > >
> > >Hope this helps.
> > >
> > >Sheila
> > >
> > >
> > >==============================================================================
> > >
> > >Sheila McIlraith, PhD                 Phone: 650-723-7932
> > >Senior Research Scientist             Fax:  650-725-5850
> > >Knowledge Systems Lab
> > >Department of Computer Science
> > >Gates Sciences Building, 2A-248       http://www.ksl.stanford.edu/people/sam
> > >Stanford University                   E-mail sam@ksl.stanford.edu
> > >Stanford, CA 94305-9020
> > >
> > >
> > >
> > >
> > >       Hi All,
> > >                    I need some clarification regarding the description of
> > >       ExpressCongoBuy atomic service which is part of the ProcessModel
> > >       described by the file
> > >       <http://www.daml.org/services/daml-s/0.7/CongoProcess.daml>.
> > >       Is property:congoOrderShippedEffect part of the ExpressCongoBuy service?
> > >       If the answer is yes, shouldn't  it have a domain pointing to the
> > >       ExpressCongoBuy class.
> > >
> > >       - <daml:Property rdf:ID="congoOrderShippedEffect">
> > >         <rdfs:subPropertyOf
> > >       rdf:resource="http://www.daml.org/services/daml-s/0.7/Process.daml#effect"
> > >       />
> > >       - <rdfs:range>
> > >       - <daml:Class>
> > >         <rdfs:subClassOf
> > >       rdf:resource="http://www.daml.org/services/daml-s/0.7/Process.daml#ConditionalEffect"
> > >       />
> > >       - <rdfs:subClassOf>
> > >       - <daml:Restriction>
> > >         <daml:onProperty
> > >       rdf:resource="http://www.daml.org/services/daml-s/0.7/Process.daml#ceCondition"
> > >       />
> > >         <daml:toClass rdf:resource="#BookInStock" />
> > >         </daml:Restriction>
> > >         </rdfs:subClassOf>
> > >       - <rdfs:subClassOf>
> > >       - <daml:Restriction>
> > >         <daml:onProperty
> > >       rdf:resource="http://www.daml.org/services/daml-s/0.7/Process.daml#ceEffect"
> > >       />
> > >         <daml:toClass rdf:resource="#OrderShippedEffect" />
> > >         </daml:Restriction>
> > >         </rdfs:subClassOf>
> > >         </daml:Class>
> > >         </rdfs:range>
> > >         </daml:Property>
> > >
> > >       Similarly shouldn't the output: congOrderShippedOutput have a domian as
> > >       well. Am I missing something?
> > >
> > >       peace,
> > >       mithun
> > >
> > >
> > >
> > >
> > >
Received on Tuesday, 4 March 2003 18:55:05 GMT

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