Re: DAML-S expressiveness challenge #1

Tim -

Thanks again for helping to clarify one of my messages.  (I was planning to write
a similar clarification
myself, with reference to my original DAML-S example, with which this thread
began.)

Yes, your example is right on with respect to what I need to model. Continued
below ...

tim finin wrote:

> I'm not exactly sure what David Martin needs to model
> in his work with DAML-S, but here's a simple example
> that I think brings out the problem or at least a related
> one.  I'm basing this on an old example from KL-ONE days:
>
>    a person is a thing with
>        one home address of type address
>    a worker is a person with
>        one office address of type address
>    a homeworker is defined as a worker
>        who's home address and office address are the same.
>
> in logic we would (partially) model this as
>
>    homeworker(X) <-> person(X), homeaddr(X,A), officeaddr(X,A)
>
> What's missing in DAML+OIL (as far as I understand) is the ability
> to express the equality constraint between the values of the two
> properties which is no nicely done with variables and unification
> in many languages.

As I understand things, it is possible to express the above in DAML+OIL, and in
fact, an approach to expressing this was suggested in an earlier message.  That
approach was in this message:
http://lists.w3.org/Archives/Public/www-rdf-logic/2001Jun/0219.html.

In the simplest case, where the domain of P1 (homeaddr) and P2 (officeaddr) are
the same, the suggested approach involves creating a "dummy" union property that
is a super-property of P1 and P2, and relying on a cardinality restriction to
enforce that there can only be a single instance of the property, and hence the
value of homeaddr and officeaddr must be the same.  However, for DAML-S purposes,
things very quickly become much messier, because (for starters) we need to allow
for cardinalities of greater than 1, and we also need to allow for different
domains for the 2 properties.

My reaction to that suggested approach is that yes, it might work, but once
you've tied up all the loose ends, you've got an approach that is FAR TOO BAROQUE
for any practical use.  (Even in the simplest case, I don't want a Website
developer or reader to have to understand that a dummy property and a non-obvious
cardinality restriction have been created just for the purpose of stating that
homeaddr and officeaddr are the same.)

This led me to propose a new property, sameValuesAs, which would be used like
this:

    <sameValuesAs homeaddr officeaddr>

and would state that the set of values of all the instances of homeaddr would be
the same as the set of values of all the instances of officeaddr.  (Where y is
the value of property instance <p x y>).

It may be the sameValuesAs could be defined simply as syntactic sugar, an
expression that is equivalent to the creation of some union classes and some
union properties and some restrictions.  I haven't had time to get clear about
this yet. Regardless of that, I'm also not yet clear whether sameValuesAs would
be fully adequate for practical purposes, with respect to DAML-S requirements.
But it seems to me it could certainly be useful for some purposes, including some
of our DAML-S needs.   I'll try to find time to elaborate further in another
message.

- David

>
>
> --
>  Tim Finin, Prof Computer Science & Electrical Eng, Director Inst. for Global
>  Electronic Commerce, U Maryland Baltimore County, 1000 Hilltop, Baltimore MD
>  21250. mailto:finin@umbc.edu 410-455-3522 fax:-3969 http://umbc.edu/~finin/

Received on Tuesday, 10 July 2001 15:40:18 UTC