Re: Proposed redefinition of "Property"

At 01:46 PM 12/29/00 +0000, Ian Horrocks wrote:
>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.

I know full well that I was suggesting moving things around.
However, I was trying to neaten up the syntax somewhat. I agree
that my syntax is cumbersome when a property is defined for
a number of classes. But, I was trying to address some issues.

As you said before, the version of DAML that I was working from
is out of date. In the new version, are the resource definitions for
properties also local to class? In other words, are properties also
defined within a class? (I haven't been able to access daml.org for
a few days to check out the more recent version.) If so, then this is
more consistent with the OIL syntax. If not, then I see a number of issues
with defining a stand-alone property. First, if the property is associated
with a number of domain resources, how is this expressed? It seems
cumbersome to list all the domains that use the property in the definition
of the property. Rather, it would be cleaner to list the properties in the
definition of Class as is done in OIL. Second, as is done now, the
toClass specification is done in the Class definition. Given that
almost everything about a property is more cleanly defined in the
Class definition, why call property out separately? All that is really left
to define in property are things like equivalentTo (which anyway might
be dependent on the Class - e.g. 'calf' is equivalent to 'offspring' only
for Classes of cows and whales) and inverseOf (which might also
be dependent on the Class - e.g. 'kid' might be the inverse of
'parent' only for Classes of people and goats while 'puppy' might be
the inverse of 'parent' for the Class of cat). It seems that these also
should be treated like the toClass definition and placed within the
Class definition to be more consistent.

So under these circumstances, it is not clear to me the advantage of
defining property as a "first class" definition. It seems that each aspect
of the definition of a property can ultimately be class dependent. So, the
question is: where is the most convenient place to put this information
and what will yield the cleanest syntax? Should all the information about
a property be scattered, be contained in the Class definitions, or be
defined in the property itself? My suggestion was to put them into the
property. It would be equally fine to group them into the Class
definition. However, when it is scattered some information seems to
be not easily expressible like inverseOf, equivalentTo, and cardinality
(see later).

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

Global cardinality constraints may not be expressive enough. For
example, both loan-account and checking-account classes have an 'owner'
property that relates them to a customer class. The inverse of an 'owner'
property is defined to be 'owns.' However, the particular bank's policy is 
that
customers may only own one checking-account but many loan-accounts.
If so, it is not sufficient to express a global cardinality for the inverse
since the inverse really depends on the associated classes. In one case,
the inverse cardinality is one, and in the other case, the inverse cardinality
is many. Again, to be clearer, either this information should reside in the
property definition or in the class definition.

If the property definition is put in the class definition, which class should
it be defined with? (I don't think anyone would argue for both.) One
could be selected by the definer of the ontology, which is certainly
acceptable. However, someone else reading the ontology might look for
'owns' properties and search to find them buried within both the
checking-account and loan-account classes. Alternative, if properties are
defined as first class definitions, they can be found more readily in a
the list of property definitions. That's why I suggested that they be grouped
with property.

> > 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 10:58:57 UTC