Re: DAML-S expressiveness challenge #1

Ian Horrocks wrote:

> On June 14, David Martin writes:
> >          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?
>
> You can do this now, or something close. Simply introduce a new
> property called say "P1_or_P2" such that both P1 and P2 are asserted
> to be subProperties of P1_or_P2. Now you can use a cardinality
> restriction to assert that a class C has at most one P1_or_P2. Thus if
> some instance of the class is related to individual x by P1 and
> individual y by P2, then x=y.
>
> I believe that Dan Connolly is making a list of useful DAML+OIL
> "recipes". Perhaps he could add this one.

2 additional comments on the above suggestion -

(1) What I want to express doesn't assume the same domain for P1 and P2, as
you do.  However, I assume that can easily be addressed by creating a union
class of the two domains, and attaching the cardinality restriction to that
union class.

(2) BUT - even though I agree with the conceptual soundness of this particular
"recipe", I should also say that I'm thoroughly skeptical about its ultimate
usefulness for practical purposes.  (And I suspect that other recipes may be
similarly impractical, although I will be delighted if I turn out to be
wrong.)

Take my case for example.  I want to say (what is mundane in any programming
language) that  output property P1 of subprocess A is identical with  input
property P2 of subprocess B. Let's say my goal is to have an interpreter or
compiler execute my process model.   So I'm going to create an artificial
union property for A and B, and also an artificial union property for P1 and
P2, and then restrict the cardinality of P1_or_P2, and expect the interpreter
or compiler to deduce that output P1 gets copied into input P2 - and do this
for every such output/input pair?  Surely not.

Note - I realize you didn't claim to address any of my issues specific to
process modeling or execution.  But I'm just making the general point that
logical "recipes" may not get us too far in practical settings.

- Dave

Received on Monday, 18 June 2001 22:37:34 UTC