Re: Proposed redefinition of "Property"

On December 27, David Silberberg writes:
> Hi,
> 
> I'm new to this forum so please forgive me if I'm not up
> to speed on some of the issues.
> 
> Jim Hendler is my dissertation advisor (I'm going for my
> Ph.D. after a very long hiatus) and my interest is in providing
> a simple query language for DAML documents/sources. I would
> like to use the semantics of the associated document/source
> ontology(ies) to relieve the query formulator from having to
> specify information that can be gleaned from the ontology(ies).
> 
> 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.

This is out of date. In the latest version, cardinality restrictions
are (usually) local to classes.

> 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.

I don't see this. All your example does is move the information around
so that instead of being mostly grouped with class specifications it
is mostly grouped with property specifications. If the same property
were used in lots of classes, this would make the property
specification very cumbersome (e.g., it might contain toClass
restrictions for every species in the ontology). Moreover, if you (or
your application) need the information in this form, it is easy to
derive from the ontology a list of all the (syntactic) restrictions
applied to a given property.

> Furthermore, it would be worthwhile to know the cardinality in
> the other direction. An Animal has 2 parents, but the parents
> may have many children. This would provide more semantics when
> defining another property which is the "inverseOf" the first
> property.

You can simply declare a global cardinality constraint on the inverse
property, i.e., thing subClassOf restriction onProperty hasParent cardinality 2.

> So here would be a portion of the revised specification of the
> Animal ontology:
> 
> <Class ID="Animal">
>      <label> Animal</label>
>      <comment> ... </comment>
> </Class>
> 
> <Class ID="Person">
>      <subclassOf resource=#Animal/>
> </Class>
> 
> <Property ID="parent">
>      <comment>
>          We would have to ensure that fromClasses
>          are in the same subclassOf hierarchy.
>          Similarly, we would have to ensure that
>          toClasses are in the same subclassOf hierarchy.
>      </comment>
>      <restrictedBy>
>          <Restriction>
>              <fromClass resource=#Animal/>
>              <fromCardinality>many</fromCardinality>
>              <toClass resource=#Animal/>
>              <toCardinality>2</toCardinality>
>          </Restriction>
>          <Restriction>
>              <fromClass resource=#Person/>
>              <fromCardinality>many</fromCardinality>
>              <toClass resource=#Person/>
>              <toCardinality>2</toCardinality>
>          </Restriction>
>      </restrictedBy>
> </Property>
> 
> <Property ID="child">
>      <inverseOf resource=#parent/>
> </Property>
> 
> The benefit of knowing the "fromClass" and "toClass"
> as well as their cardinalities up front from an
> intelligent query perspective manifests itself
> when there are a number of classes "strung together" by
> a number of properties. By analyzing the nature of the
> cardinalities of the properties, one can assume some
> semantics about the interrelationship of the classes.
> 
> 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

Received on Friday, 29 December 2000 09:10:22 UTC