Re: DAML-S expressiveness challenge #1

On July 10, David Martin writes:
> 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.

Whether or not this particular example is "too baroque" is a matter of
opinion, but it is obviously true that things can soon get pretty
baroque when trying to model the world using DAML+OIL. I think that we
should view DAML+OIL (and its extensions) as the assembly language(s)
of the semantic web. In the longer term there will certainly be high
level languages and/or tools that the vast majority of "programmers"
will use, and of course most people wont do any programming at all -
they will just use applications. Unfortunately, the price we pay for
being "in at the start" is that there are still very few such
amenities. Until they are developed we will just have to roll up our
sleeves and get our hands dirty.

Regards, Ian



> 
> - 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 18:54:00 UTC