SRI's Lessons Learned for DAML-ONT

closed available at http://www.ai.sri.com/daml/lessonslearned.html/ 2000-10-31 SRI DAML Team

SRI's Lessons Learned for DAML-ONT

Issues and Suggested Language Improvements

Greater flexibility in declaring domain and range

We'd like to be able to declare the range of a property as "list of such and such", but we find that the language is missing one extremely convenient way to do so. We do find 2 existing ways to get at this, both useful, but we'd also like to see a third way supported.

We illustrate the 2 ways that we're are aware of with the help of an example. We have a class "Researcher" and want to define the relation that holds between a researcher and her publications. We assume that we have "http://www.daml.org/2000/10/daml-ont#" imported so that we can refer to the class "List".

Rely on unlimited cardinality.
```
<Class ID="Researcher"/>

<Property ID="publication">
  <domain resource="#Researcher"/>
  <range resource="#Publication"/>
</Property>

<Class ID="Publication">
  <comment> The class of publications.</comment>
</Class>
```
With the above declarations, an instance of Researcher can contain any number of publication property instances, each referring to a different publication. This is okay for a small set of publications, but could be cumbersome for a large set. In addition, this approach doesn't allow for reuse of a particular set of publications by different contexts.

Reify the notion of "list of publications".

<Class ID="Researcher"/>

<Property ID="publications">
  <domain resource="#Researcher"/>
  <range resource="#Publication-list"/>
</Property>

<Class ID="Publication-list">
  <comment The class of lists of publications./>
  <subClassOf resource="#List"/>
  <item>
    <Restriction>
      <restrictedBy>
        <domain="#Publication">
      </restrictedBy>
    </Restriction>
  </item>
</Class>

<Class ID="Publication">
  <comment> The class of publications.</comment>
</Class>

This allows for instantiation of a list of publications, which can be named and reused. But it seems unfortunate to have to create a new list type for every such situation.

THE WAY WE WOULD LIKE TO HAVE IT SUPPORTED:
```
<Class ID="Researcher"/>

<Class ID="Publication">
  <comment> The class of publications.</comment>
</Class>

<Property ID="publications">
  <domain resource="#Researcher"/>
  <range resource="#List[#Publication]"/>
</Property>
```
This suggest a parameterized class constructor. Parameterization is one of the module operations (among others such as views of classes to support hiding) we would like to see supported. See below for more info on our ideas on module operations.

Functions and relations

There needs to be greater flexibility in using the notions of function and relation, in ontologies. Currently, you can declare that a particular Property is a function, by limiting its cardinality to 1, or by declaring it as UniqueProperty. But there's no way to say that some concept or thing is a function or relation.

In addition, there could be a more convenient way to specify relations of arity greater than 2.

Note: this is an area in which we would like to make a contribution, and would be interested in corporating/collaborating with other interested parties.

Semantics of subclassing

The <subClassOf> property allows to express some kind of inheritance. But it is not clear what exactly is the semantics of the property.

As one example, is it permitted for a subclass to redefine one of its inherited properties, say, by specifying a different range for the property?

As another example, what happens when multiple inheritance takes place as in

<Class ID="Father"/>
<Class ID="Parent"/>

<Class ID="Male">
  <subClassOf resource="#Father"/>
  <subClassOf resource="#Parent"/>
</Class>

Does this mean the class "Male" necessarily inherits all the properties from both "Father" and "Parent"? What if both classes have a property "name" defined? We understand that the two properties can readily be distinguished within the class "Male", using qualifiers and/or name spaces. But can one identify the properties in order to express that there is one name for a male person?

In addition, we would like to see some mechanism by which a subclass can elect to exclude certain properties of its parent from being inherited. Among other things, this will be an essential mechanism for addressing security concerns.

Declaration of capabilities

We anticipate a need -- indeed, a widespread need -- to be able to characterize capabilities/services/procedures provided by Web sites (not just information). For instance, for a WebSite providing travel services, there must be a way to say that one can get an airline ticket reservation using that WebSite. One can imagine characterizing services with various degrees of expressiveness and granularity. As a beginning, it will be useful to have a notion of Procedure, which can be subclass'ed and described in various ways.

We recognize that many services can be characterized as functions or relations. For instance, a travel WebSite might provide a function that maps from a city to a list of airports serving that city. A question that arises in this context is how can DAML express that a service provided on a webpage implements another, more abstract, specification of a function.

Moreover, one might want to distinguish between the axiomatic description of a service/capability/procedure and the actual implementation. We would like to see that DAML supports both, the annotation of the axiomatic description of such services as well as the annotation of the actual implementations.

It is clear that in order to axiomatize services/capabilities/procedures we need to support logical statements which are not currently part of DAML-ONT.

We are very interested in these topics and would like to cooperate with other project teams on these issues.

Views, roles, contexts

Though subclassing may be able to express a lot of things, we find it sometimes not appropriate. For instance, a person may play several roles in life, as a (medical) patient, a customer, an amazon-customer, an employee, a researcher, a head of household, etc. In the face of some specific task, it is tempting to specify each such role as a subclass of person (or perhaps as a descendant of person, involving multiple levels of subclassing).

But we often find the overuse of subclassing to be problematic. For one thing, you may have many overlapping subclasses of Person in the same application, and it's not clear how to enforce that their shared properties (such as name) should be the same across instances of these subclasses. That is, it's not clear how to indicate that these instances represent the same person. For another thing, a person might be an amazon-customer only for a specific time as for example during a transaction. Defining a subclass seems to be more than what we aim for, because subclassing is regarded as permanent.

We would be very interested in exploring this issue and would like to cooperate with other DAML teams that have similar interests.

Module operations

In general, we are very interested in "module operations" for classes, properties, ontologies.

We think that module operations such as views, parameterization, inheritance, etc, could enhance practicability and usability of DAML. For instance, if one wants to define a list or bag of things, one has to do this over and over again. We would like to see a way of defining basic data structures like list and sets defined once (together with their "rules") and using parameterization to instantiate the parameterized classes with different types for the elements (e.g., List[Person], List[Publication]).

"Module operations" may also include ways to combine, structure, restrict, project ontologies in order to receive new ontologies. How can ontologies be structured? Can an ontology have sub-ontologies?

We are very interested in cooperating on these issues.

Classes and sets

In http://www.daml.org/2000/10/daml-num.daml the following is defined:

<Property ID="min">
  <domain resource="http://www.daml.org/2000/10/daml-ont#Class"/>
  <range resource="#Integer"/>
  <comment>for min(S, x) read: x is the minimum of s; i.e.
        x is in S and every y in S is not less than x
  </comment>
</Property>

What does this mean? Why isn't the domain restricted to a set of integers? It would certainly be useful to be able to specify "set of integers" for domain. (See point Greater flexibility in declaring domain and range above.)

As stated, the above definition seems to be not well-defined, since not every class has a "less than" property defined, and thus, "min" might not make sense. (Take for instance the class person, min(Person,"Paul") is not defined, unless there is an order defined on persons).

A more fundamental question here is: does it makes sense to equate "Class X" with "set of all instances of X", as seems to be intended by the above example? Although this may be the practice in some mathematical settings, we don't think it will work well in the context of DAML. Here is one argument in favor of distinguishing between the two: it's natural to think of a class (say, "SRI employee") as something abstract and unchanging, whereas a set of something (say, the "set of all SRI employees") changes from time to time.

Namespace question

Here is a syntax-related question which might be due to our restricted knowledge of RDF.

Assume we defined xmlns:"time="http://www.ai.sri.com/ontologies/Time#" and in this ontology there is a class defined.

Can one use the reference "time" in a resource definition? E.g., if one wants to define a property of courses as follows:

<Class ID="Course"/>

<Property ID="course-time">
  <domain resource="#Course"/>
  <range resource=time:#Time/>  ? is this correct?
  <range resource="time:#Time"/>  ? or this ?
</Property>

Another syntax-related question

If a class has several properties defined, are those conjunctive or disjunctive by default? Is there a means to express both (because sometimes one needs conjunction and sometimes disjunction)? For instance, assume a class has several properties: Are they conjunctive or disjunctive?

Repeated properties

We want to define several disjoint subclasses of publications, e.g., book, article, series, paper, thesis etc.

We made an attempt in the following, but it looks really bulky because we have to repeat the disjointFrom properties again and again. Isn't there a better way?

<Class ID="Book">
  <subclassOf resource="#Publication"/>
  <comment> The class of books.</comment> 
  <disjointFrom resource="#Series">    <!-- Are the "disjointFrom" -->
  <disjointFrom resource="#Article">   <!-- properties of a class --> 
  <disjointFrom resource="#Paper">     <!-- conjunctive or disjunctive? -->
  <disjointFrom resource="#Thesis">
</Class>

<Class ID="Series">
  <subclassOf resource="#Publication"/>
  <comment> The class of series.</comment>
  <disjointFrom resource="#Book">
  <disjointFrom resource="#Article"> 
  <
disjointFrom resource="#Paper">
  <disjointFrom resource="#Thesis">
</Class>

<Class ID="Article">
  <subclassOf resource="#Publication"/>
  <comment> The class of journal articles.</comment>
  <disjointFrom resource="#Book">
  <disjointFrom resource="#Series"> 
  <disjointFrom resource="#Paper">
  <disjointFrom resource="#Thesis">
</Class>

and so forth for Paper, Thesis.

We tried the following alternative modelling using the "Disjoint" class from daml-ont.

<Class ID="Publication">
  <comment> The class of publications, given as a disjoint list of other 
            classes.
  </comment>
  <subClassOf resource="#Disjoint"/>
</Class>

<Class ID="Book">
  <subclassOf resource="#Publication"/>
  <comment> The class of books.</comment>
  <oneOf resource="#Publication">
</Class>

But as we understand DAML, this approach only allows for classes being in the list of publications when they are disjoint from all the others. We don't think that the first (lengthier) approach says the same, or? (In the first approach one could define a new subclass of Publication that is not disjoint from all the others. This is not possible in the second approach, right?)

Defining polymorphic properties

We search for a more efficient way to define polymorphic attributes. For instance, assume we have defined classes "Article" and "Booklet". We want to define the property "title" for both classes, but it is mandatory for Article whereas it is optional for Booklet. Can we do this in one shot, only defining one property that has as a domain either of the classes and for each domain describes whether the property is mandatory or not?

The way I have solved it, is as follows, but it is very inefficient and redundant:

<Class ID="Article"/>
<Class ID="Booklet"/>

<Property ID="title">
  <domain resource="Article"/>
  <cardinality>1</cardinality>
</Property>

<Property ID="title">
  <domain resource="Booklet"/>
</Property>

Distributed content

Are DAML annotations meant to refer always to one webpage? If no, that means that one could give a DAML annotation of content that is distributed over several web pages. I would conclude from that, that DAML is not meant to replace HTML at some point. Is that correct?

If yes, does that mean that a DAML document should not contain more information than the web page it refers to?

Clearinghouse for ontologies

There is a need for a mechanism for browsing and access setting the ontologies created by all DAML participants -- some sort of clearinghouse of ontologies.

Meaning of import

There is a need for a clearer explanation of the imports clause.

Final Note:

The ontologies we have submitted on 10/31 are regarded as preliminary. Especially, we expect to do significantly more work on core ontologies like date and time, and on description of actions and procedures.