Re: ExpressCongoBuy atomic service description

Dave,

Let's discuss this as a first agenda item on the telecon.  It
I don't have time for a lengthy email discussion.  Sorry.

Sheila

	From martin@AI.SRI.COM Tue Mar  4 15:54:27 2003
	Return-Path: <martin@AI.SRI.COM>
	Received: from Labrea.AI.SRI.COM (Labrea.AI.SRI.COM [130.107.64.124])
		by ksl.Stanford.EDU (8.11.6+Sun/8.10.2) with ESMTP id h24NsPY13749
		for <sam@ksl.Stanford.EDU>; Tue, 4 Mar 2003 15:54:25 -0800 (PST)
	Received: from ai.sri.com (Birch.AI.SRI.COM [130.107.65.8])
		by Labrea.AI.SRI.COM (8.10.2+Sun/8.9.3) with ESMTP id h24NsO728526;
		Tue, 4 Mar 2003 15:54:24 -0800 (PST)
	Message-ID: <3E653CDA.AC41BDED@ai.sri.com>
	Date: Tue, 04 Mar 2003 15:55:06 -0800
	From: David Martin <martin@AI.SRI.COM>
	Organization: SRI International
	X-Mailer: Mozilla 4.77 [en] (Windows NT 5.0; U)
	X-Accept-Language: en
	MIME-Version: 1.0
	To: sam@ksl.Stanford.EDU
	CC: mits1@cs.umbc.edu, www-ws@w3.org
	Subject: Re: ExpressCongoBuy atomic service description
	References: <200303042238.h24Mcsa12710@ksl.Stanford.EDU>
	Content-Type: text/plain; charset=us-ascii
	Content-Transfer-Encoding: 7bit
	Content-Length: 6787
	Status: R

	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 19:08:36 UTC