Home : Current Projects : Darpa Markup Language : Scheduling Ontology
 

DAML Schedule Ontology

Description

1. Activity Ontology
2. Demand Ontology
3. Capacity Ontology
4. Resource Ontology
5. Instances

Lessons Learned

General Comment

The scheduling ontology was generated by translating the Ozone scheduling ontology developed by Carnegie Mellon Universty, and extending it with some additional concepts generated from Kestrel's on-going work on the Air Mobility Command CAMPS project. The time ontology was based on the time ontology currently available on Stanford's Ontoserver, and on some of the other time and date ontologies developed by other groups in the DAML program.

It was very difficult to express constraints on the intended meaning of the terminology using the available DAML language constructs. My general impression of the language is that, in its current stage, DAML does not seem to be an appropriate formalism for representing ontologies. This comment is based on my particualr view of the purpose an ontology should serve. One of the main criticisms I have about the development of several ontologies as generic knowledge representations is the lack of purpose inherent to the majority of these efforts. By definition, an ontology should express a shared understanding about a certain target domain. This shared understanding implies a mapping between different representations with the purpose of performing some useful computation. The ontology should facilitate knowledge interchange. Most of the ontologies published so far in the DAML site, and ours is no exception, are basically hard-to-read listings of terms commonly used by the ontology developer(s) to describe entities from selected domains.

DAML currently does not provide powerful language constructs to restrict the meaning of described entities to just what is strictly relevant to the expected use of the ontology, or to allow the precise mapping between different descriptions of the same conceptual entity. For example, from a transportation point of view, an airplane is an entity capable of moving a certain amount of cargo between two airports during a certain period of time. Any other information about this entity is irrelevant to the transportation airplane. From a manufacturing perspective, an airplane is an artifact that has a well defined internal volume, an engine with a certain capability described in terms of power and speed, and a number of other characteristics. When developing or importing an ontological description for the airplane entity, I would like to be able to specify exaclty what are the relevant aspects of the definition. Moreover, the ontology representation should provide mechanisms to allow, or at least facilitate, some level of inference. Still using the airplane example, one would probably like to be able to express that the amount of cargo the airplane can carry is related to its internal volume.

Questions and Comments on the Syntax and Use

Here is a list of the main problems and questions I had while developing the scheduling ontology.

1. Having to specify each property using the standard DAML syntax makes the ontology development process extremely painful. There should be a better syntax for collectively specifying properties for a given class.
2. The same comment is applicable to equivalent terminology. There should be a form to specify equivalent classes and properties without the need to define a new class, and inside the class or property definition use the sameClassAs or samePropertyAs construct. Constructs for variants and synonyms should also be provided. Maybe we could use the label element in the class definition for this purpose but its semantic is not clear.
3. The construct equivalentTo seems to overlap with sameClassAs or samePropertyAs. There is no specific rule when one or the other should be used.
4. It is not clear how constraints on the value of properties should be expressed. One solution it to define a new class and use this class as the range of the property. The other solution is to limit the value of the property in the definition of the class. The second solution seems to be the more appropriate choice. I would like to be able to impose a range constraint on a property value without having to define a new class. It is not possible, ot at least I do not know how to describe a class based on constraints on pairs or sets of property values. For example, I want to specify that a Time-Interval has two properties, start and end such that the value of property start is always less than the value of property end.
5. I did not understand the rationale for restricting the RDF collection types only to lists and not allowing the import of basic RDF types. Any reasonable ontology would need richer constructs to express collection of entitites. If I can import other rdf constructs, why are the collection types restricted?
6. In the DAML-Ont specification there is a confusion between meta-level and object-level constructs. For example, the class Disjoint is defined to be a sub-class of List, but according to the comments, it actually corresponds to a meta-class. From my understanding, an instance of a Disjoint class is a list of classes such that there exists no object that can be an simultaneous an instance of two of more of these classes.
7. Does importing an ontology adds the namespace defined by the imported ontology?
8. How should I specify the elements of a class by enumeration? For example, in the time ontology defined by CMU's group, instances of month are defined inside the definition of the class Month using the construct oneOf. I believe this construct is wrong. By defining the instances inside the class description using the oneOf construct, I would assume that there should be just one instance of the class Month and it should be one of the specified elements. Assuming that my interpretation is wrong, defining instances as part of the class description limits the number of instances to just those defined: the 12 english symbols or strings for months. No other instance of month can be created.
9. How to express relations between two property values or two different instances. The number ontology defined at http://www.daml.org/2000/10/daml-num.daml specifies lessThan and greaterThan properties for comparing two Integers. But this use of properties seems wrong since a property should map elements in its domain to element in its range. Therefore, lessThan should map a given integer to the entire set of integers greater than its value. The property definition specifies these constructs as maps from Integer to Integer. It should be defined as a mapping from a class defined as a pair or tuple of integers to boolean.
10. How can we perform calculations or computations in DAML? How do we specify behavior? How can we constrain the value of a certain instance property based on the value of another instance property? We need the capability of representing variables or some kind of place holder for temporary values.
11. Why the definitions of classes TransitiveProperty, UniqueProperty and UnambiguousProperty have not been formalized in terms of the DAML syntax? Formalizing these constructs would provide us with good example on the intended use of the DAML language to express constraint.

- Back to Top -

- Home - About Kestrel - Research Staff - Current Projects - Project Archive -
- Publications - Technology Transfer - Career Opportunities - Contact Kestrel -