Re: DAML-S expressiveness challenge #1

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
>

Received on Thursday, 14 June 2001 18:09:30 UTC