Re: Proposed redefinition of "Property"

At 10:01 AM 1/2/01 -0500, Peter F. Patel-Schneider wrote:
>From: David Silberberg <david.silberberg@jhuapl.edu>
>Subject: Proposed redefinition of "Property"
>Date: Wed, 27 Dec 2000 15:28:47 -0500
>
> > Hi,
> >
> > With that said, I am specifically questioning the definition
> > of a property. Currently, properties are specified as
> > "first class" definitions. The property itself specifies
> > the domain resource and a cardinality. For example, a "parent"
> > property is associated with the domain resource "Animal" with
> > a cardinality of 2, meaning that an Animal can have 2 parents.
> > However, there is nothing that restricts the domain of the parent.
> > For example, one would want to restrict parents of Animals to be
> > Animals. While there is a mechanism for doing this using the
> > "toClass" property in the "restrictedBy" portion of a Class
> > definition, it is somewhat awkward to break up the definition of
> > a property like that. It would seem more appropriate to define
> > the "toClass" in the property itself.
>
>The association of domains, ranges, and cardinality with properties is
>interesting and probably useful, but extremely non-modular.  I think that
>it would place a very large hurdle in the merging or extension of
>ontologies.

It would seem that "not" having these would limit the modularity
of ontologies just for the reasons given in your next paragraph.
If a property name needs to be used in an extended ontology,
but the domains, ranges, and cardinality would need to be modified,
the fact that they cannot be modified would make it difficult to extend.

>For a typical example of this, consider the problem that Ian Horrocks has
>discovered with the DAML walkthrough.  In the walkthrough the property
>``height'' is given domain ``Person''.  This has the effect that any
>extension or merger of this ontology cannot use (this) height for any other
>kind of object.  Yes, I know that you could use another height, but then
>you would have two kinds of heights.

Exactly. This is why there needs to be some sophisticated way of
both defining flavors of properties and extending them. If I need to
extend or merge my ontology with another, I might either like to
point to a particular flavor of height (heights for skyscrapers and people
would have different domains (and maybe even ranges) and thus different
flavors) or define a new flavor of height. You are right that this could be 
confusing. On the other hand, if I cannot merge my skyscraper ontology with 
your person ontology because I cannot use your version of height nor can I 
introduce my own flavor of height, then I might not choose to reuse and
extend your ontology. This is true even if most of your ontology is useful 
to me.
If I cannot override some aspect of properties to reflect my own domain, then
I will not be able to use the other ontology. Without a way to provide some
kind of property overriding (flavoring) for a domain, people might
potentially be discouraged from reusing other ontologies and thus
DAML might have limited use.

The problem is that defining flavors of properties seems difficult and
confusing. I am not convinced that it has to be. Often, properties
will have one flavor. However, when multiple flavors are necessary,
then some syntax that defines different flavors might be useful such as:

<Property ID="height">
   <Flavor ID="default">
     <cardinality>... </cardinality>
     <domain resource="#Person"/>
     <range resouce="#..."/>
   </Flavor>
   <Flavor ID="skyscraper-height">
     <subclassOf flavor="#default"/>
     <domain resource="#Building"/>    // just call out the differences
   </Flavor>
</Property>

An extension to this might be the following:

<rdf:RDF
   xmlns:old-ont = "http://.../old-ont" >
...
<Property ID = "old-ont:height">
     <Flavor ID="sandcastle-height">
     <subclassOf flavor="old-ont:#default"/>
     <domain resource="#sandcastle"/>    // just call out the differences
   </Flavor>
</Property>

I haven't fully thought out the syntax, but at least this is the idea. You
are right that you have two kinds of heights, but that is only of concern
to the person who merges the ontologies. However, it should be
transparent to anyone using the ontology. Thus, if I specify height
(not skyscraper-height or sandcastle-height) in my application,
my application should automatically know from the context (in this
case the domain) which flavor of height is meant.

> > What this does is remove some of the frame-based flavor
> > of the DAML specification language, but it seems cleaner.
> > I would be interested in other people's opinions on the
> > matter.
> >
> > David
>
>I don't care (much) about losing any possible frame-based flavour.  I do
>care about losing other aspects, such as utility and modularity.
>Unfortunately, many of these aspects have to be traded off against each
>other.  (Actually, I do lean (technically) somewhat towards allowing
>domain, range, and cardinality for properties, but I am very concerned
>(operationally) with the increased possibility of creating ontologies that
>are less useful that they could be.

Again, if there is a way to define flavors both clearly and unambiguously
as well as make them transparent to applications, I believe that it
will increase the utility and reusability of DAML ontologies. If not,
I believe people might not reuse DAML ontologies if small conflicts
in property definitions arise.

>Peter Patel-Schneider
>Bell Labs Research

David Silberberg

Received on Tuesday, 2 January 2001 11:29:06 UTC