Re: DAML-S expressiveness challenge #1

Uh, assignment or binding, Baoshi? I hate to open a can of worms, but
the terminology you use may be problematic. There are many programming
languages and the spirit of this language is to be declarative, I think.
If true assignment is the only way to do this, then we've stepped
backwards. And if you have to step outside the language, there is a
problem. 

It seems to me, David, that you want the equivalent of unification in a
logic programming language (as you suggest), i.e., bind X = Y [where Y
is instantiated first] so that X has whatever value Y has (or actually,
v.v., if X is instantiated first). I don't know whether DAML-OIL
supports this or not, but binding in general implies unbinding, which in
a binding interpreter for a language means support for backtracking
(because in a sequentially processed expression -- say, a query --
initially "true" bindings may be undone because they are incompatible
with later information).

But I'll let others inform us both.

Leo

Baoshi Yan wrote:
> 
> My 2 cents:
> It may not be necessary to expand DAML in order to do that.
> What I have in mind is that we can introduce another process called
> "assignment", what it does is to assign the value of one property to
> another. Think about how programming language works: between function calls
> there are some assignments of parameters. Therefore the whole execution
> sequence would be like:
> getCreditCardNumFromUser(output),assignment(output,input),postCharge(input,a
> mount).
> 
> -baoshi
> 
> From: "David Martin" <martin@AI.SRI.COM>
> To: <www-rdf-logic@w3.org>
> Sent: Thursday, June 14, 2001 2:29 PM
> Subject: DAML-S expressiveness challenge #1
> 
> >          DAML-S expressiveness challenge #1 -
> >
> > Is it possible (or is it likely to be possible in some future release of
> > DAML+OIL or DAML-L) to express the following constraint/restriction:
> >
> >    "The value of an instance of property P1, in some particular
> > context/scope/situation, must be the same as the value of an instance
> > of property P2 in that same context/scope/situation."
> >
> > What do I mean by context/scope/situation?  Well, that's up for
> > discussion, but to get us started, let's just say I mean "namespace".
> >
> > I know about sameIndividualAs, but a straightforward use of
> > sameIndividualAs does not meet my requirements.  The instances of P1 and
> > P2 don't necessarily exist yet (that is, haven't been declared
> > anywhere); so I can't refer to them.  What I want to say is (re-phrasing
> > the above):
> >
> > "when an instance of property P1 is declared, in the same namespace as
> > an instance of property P2, they must have the same value"
> >
> > Can anyone suggest a way to express this, or a start toward doing so?
> >
> > -------------------------------------
> > BACKGROUND, MOTIVATION
> > -------------------------------------
> >
> > In DAML-S (DAML for Services), we are developing, among other things, a
> > process modeling ontology/language, for describing how a service works.
> > (For more about DAML-S, please visit http://www.daml.org/services/.)  We
> > are finding a variety of things we'd like to express, which apparently
> > aren't expressible in DAML+OIL, and it would be very helpful to have
> > some principled discussion of whether these things should be expressible
> > in some future version of DAML+OIL, or suggestions as to alternative
> > ways to express these things.  This is the first such topic posted to
> > www-rdf-logic; hence the subject header (DAML-S expressiveness challenge
> > #1).
> >
> > We want to be able to describe a process, using constructs such as
> > Sequence, If-Then-Else, etc., which are subclasses of a very general
> > class called Process.
> >
> > Imagine we want to describe the following subprocess (part of a larger
> > process on some B2C web site), expressed here in a logic programming
> > style:
> >
> >     chargePayment(Amount) :-
> >         getCreditCardNumFromUser(CCNum),
> >         postCharge(CCNum, Amount).
> >
> > What I want to express in DAML+OIL (or DAML-L) is, I believe, exactly
> > analogous to what the repeated use of CCNum expresses.  That is, it
> > restricts the 1st argument input value of postCharge to be identical to
> > the output value of getCreditCardNumFromUser, when an instance of this
> > procedure executes.
> >
> > In DAML-S, there is a top-level Process class, which has an input
> > property and an output property.  For this example, both
> > getCreditCardNumFromUser and postCharge are declared as subclasses of
> > Process, and their inputs (outputs) are declared as subproperties of
> > input (ouput).  Something like this (simplifying and omitting details):
> >
> > PREREQUISITE INFO:
> >   In DAML-S, a process is described using CLASSES; a particular
> >   USE/EXECUTION of a process is described using INSTANCES.
> >
> >     <!-- GIVEN:
> >           chargePayment is a subclass of Sequence
> >                 (and Sequence is a subclass of Process)
> >           An instance of chargePayment is constrained to have an
> >           instance of getCreditCardNumFromUser as its first element,
> >           and an instance of postCharge as its second element -->
> >
> >     <Class ID=getCreditCardNumFromUser>
> >         <subClassOf Process> .....
> >
> >     <Property ID=ccNumOutput>
> >         <subPropertyOf output>
> >         <domain getCreditCardNumFromUser> ....
> >
> >     <Class ID=postCharge>
> >         <subClassOf Process> .....
> >
> >     <Property ID=ccNumInput>
> >         <subPropertyOf input>
> >         <domain postCharge> ....
> >
> >     <!-- DESIRED CONSTRAINT GOES HERE, and says something like:
> >            "when ccNumInput and ccNumOuput are instantiated within the
> >             same instance of chargePayment, they have the same value"
> > -->
> >
> > So, again, the questions are:
> >
> >     (1) Can the DESIRED CONSTRAINT be expressed in DAML+OIL, and if not,
> >     is it likely that DAML+OIL will evolve to allow its expression?
> >
> >     (2) If no is the answer to both parts of (1), what are alternative
> >     means to accomplish what we need - a way to say that the output of
> >     (an instance of) subprocess A serves as the input to (an instance
> >     of) subprocess B?
> >
> > - David Martin
> >

-- 
_____________________________________________
Dr. Leo Obrst		The MITRE Corporation
mailto:lobrst@mitre.org Intelligent Information Management/Exploitation
Voice: 703-883-6770	7515 Colshire Drive, M/S W640
Fax: 703-883-1379       McLean, VA 22102-7508, USA

Received on Thursday, 14 June 2001 20:19:55 UTC