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 17:26:33 UTC