RE: DAML-S expressiveness challenge #1

On June 20, Marcelo Tallis writes:
> 
> >
> > 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 this wouldn't work. What was requested (I think) was that two
> *different* instances representing the first two steps of a process (e.g.,
> s1 and s2) have a property each (e.g., input and output) with the same value
> (e.g., the credit card number). Cardinality restrictions apply to single
> instances in isolation even when they belong to the same class. For example,
> a person can have at most one father, but that doesn't mean that two
> different persons will have the same father. In your suggestion, the
> cardinality restriction applies to each individual instance in isolation
> (e.g., s1 and s2 cannot have more than one credit card number each) but does
> not implies that s1 and s2 will have the same credit card number.

You may be right - the original description of the problem is not
clear on this point. The solution I described allows you to say that,
e.g., for the class "happily-married-person" the properties "spouse"
and "lover" always coincide.

What David actually said was:

> > > "when an instance of property P1 is declared, in the same namespace as
> > > an instance of property P2, they must have the same value"

This is a bit difficult to understand, as instances of P1 and P2 are
(binary) tuples, e.g., <x,y>. If I take the description literally it
seems to say that (in a given namespace) there can only be one
instance of (P1 v P2), which I was guessing was not what was
intended. However, if this is what you want, you can do it by
introducing a new "skolem" individual called, say,
"object_of_P1_or_P2" and asserting that:

1) For every individual, the object of all its P1 properties must be
object_of_P1_or_P2 (i.e., Thing is a subClassOf a toClass restriction
with "oneOf object_of_P1_or_P2" being the restricting class).

2) For every individual, the object of all its P2 properties must be
object_of_P1_or_P2

3) object_of_P1_or_P2 has at most 1 inverse P1 properties

4) object_of_P1_or_P2 has at most 1 inverse P2 properties

I will leave the RDF or N3 serialisation as an exercise for the
reader.

Omitting parts 3 and 4 would lead to the situation where there can be
many different instances of P1 and P2, but all of them have the same
individual as their object. Maybe this is what was intended.

Another possible interpretation is some sort of "role value map", as
it is called in description logics. i.e., we may want to say that for
all pairs of individuals (x,y) related by some property P (or some
chain of properties), the P1 property of x and the P2 property of y
must have the same individual as their objects. I believe that we
can't capture this in DAML+OIL - if we can then we made some mistake
somewhere as the language would certainly be undecidable.

Regards, Ian

Received on Thursday, 21 June 2001 13:53:34 UTC