This accounting is a combination of input from a student doing markup for the DAML homework assignment, a programmer implementing translators, and two researchers (and their colleagues) running research projects using DAML-ONT. Note that multiple authors provided input on issues and when confusions were presented by people who had tried to read the appropriate documents, they have not been eliminated from the report even if the information may be present in some less obvious document.

A lot of the difficulties with the development of DAML-ONT ontologies arise not from the language itself but from the pragmatic issues of implementing a large ontology. When drawing concepts from large, heterogeneous ontologies and building ontologies with large sets of instances, it often becomes hard to keep track of the exact class, relation, and instance names resulting in misnamed objects. It is also difficult to manually keep track of constraints such as cardinality when many relations define these constraints and there is no automated method of verifying their mutual consistency. Therefore, it seems that there is a need for DAML-ONT editing and authoring tools in order for the language to truly become useful.

We were fortunate to have a general ontology editor (Ontolingua) supporting editing, browsing, and consistency checking, and automated translators (to and from the DAML-ONT specification) for the purposes of building and editing our ontology. We exploited Ontolingua's features of searching (via classes, relations, instances), input checking, and consistency checking. In this initial homework assignment, we did not use our more advanced Chimaera Ontology environment since we were focusing initially on simple ontology generation only. We will run the ontology through the current Chimaera diagnostics next since the person assigned to markup commented on the need for many of the features provided. The main needs sited were for analysis and diagnostics in combination with better search support. Additionally, the homework assignment has suggested some small modifications to Chimaera that would be useful in helping minimize some of the problems mentioned below by the person doing markup.

As a general preface to the problems below, it is obvious that it would be useful to leverage as much top-level ontology information as possible without redefining it for the purposes of a new ontology. So, for example, if you want to build an instance of a Publication, one should hope to have a predefined ontology with information relating to Publications, i.e. classes for the types (Journal Articles, Books, Proceedings) and appropriate relations (Has-Author, Has-Title, Has-Date-Of-Publication, etc...). However, the problem with top-level ontologies is that one wants to avoid redefining this information if it has already been defined, however when ontologies are developed independently by many different people, it often becomes hard to exactly match terms in a hypothesized ontology with their actual names. For example, one may be unable to find a relation for Has-Author if the equivalent relation were defined as Is-Authored-By. Humans can tell that these two terms are related if not equivalent but most editors would not provide this support. Small extensions to the merging suggestions found in Chimaera could be used to minimize this problem however. Additionally, classification methods found in reasoning systems such as description logics could also be used to identify relationships between terms.

Some pragmatic issues that we found to arise during the development of our DAML-ONT ontology in the homework assignment involved the following:

• The presence of redundant information (e.g. using both Has-Author and Is-Authored-By, perhaps used interchangeably)

• The presence of inconsistent information (e.g. using the relation Has-Title when it is in fact Has-Full-Title)

• The violation of constraints such as cardinality arising from non-automated DAML-ONT editing methods. (We managed to avoid a lot of these problems by using our Ontolingua system for ontology development but all problems still manifested themselves in some way or another, if in fact mitigated.)

Following are some issues that we encountered from our analysis of the language and the development of automated translators between DAML-ONT and our Ontolingua ontology development environment.

• DAML-ONT provides a number of ways of specifying properties such as disjointness. In the case of translation to DAML, this is not a problem because the most appropriate method(s) can be used. It may be beneficial in DAML-ONT to suggest a preferred method for disjointness representation (or a preferred method for representation of meanings that may be encoded in multiple ways). This may help naïve users learn faster and also puts less of a burden on simple DAML translators. Thus, it may be the case that more editing tools are generated for DAML core language that contains only the preferred methods for representing meanings. This might allow a broader user base to have more interface tools available (presumably in a number of different paradigms) so that they would never need to write in DAML directly.

• The List collection type should be specified in greater detail. The DAML-ONT specification states that the <li> syntax from RDF has been discarded for DAML, but it would be useful to include examples of specifications of members of a list. Also, the name "list" typically implies that its elements are ordered, but in daml-ex.daml, lists are used in situations where order is generally not required or desired.

• The parseType daml:collection feature would also benefit from additional documentation. Guidelines would be useful concerning what elements can be enclosed by a tag that has the parseType="daml:collection" attribute. It would also be instructive to include the motivation for the collection types used by RDF being discarded in favor of Lists.

• It is not clear if it is possible to extend DAML-ONT by having local constraints on a class other than those defined in the specification (hasValue, toValue, and toClass). I also do not understand the motivation behind having two different methods of specifying local constraints: Qualifications and Restrictions.

• For translator writers in particular, a semantics of DAML terms would be useful. Our translator designer and implementer felt as though there was more than one way to translate between terms in DAML and Ontolingua which resulted in slightly different meanings.

We are still in the very early stages of assessing DAML-ONT with respect to our other DAML project needs. The following are some preliminary comments regarding desired features for DAML-L. We anticipate updating this list as our needs crystallize.

• Negation (and Negation as Failure): We will need *a* semantics for "not" so we can be clear about how we are interpreting "not" and so that others will interpret it in the manner we intend. The word *a* semantics, rather than *the* semantics is stressed to acknowledge that there are many different ways of interpreting "not". Two examples are full negation and negation as failure. We anticipate the need for something akin to negation as failure (NAF) in one of our efforts. The web presents some interesting challenges to realizing NAF because we will conceive the web in its entirety as being our knowledge base (KB), but we will never be able to search the whole web KB in order to achieve conventional NAF. Consequently, the search, and hence the notion of NAF needs to be constrained, for example by a) a "time limit", or b) a "context". E.g.,

1. time limit: I couldn’t prove that a flight exists from San Jose to the North Pole in 5 minutes of search, therefore I assume there does not exist such a flight by (NAF 5min).
2. context: I couldn’t prove that a flight exists from San Jose to the North Pole by searching (expedia, travelocity, UAL, AA, and Alaska Air), therefore I assume there does not exist such a flight by (NAF (expedia, travelocity, UAL, AA, and Alaska Air)).

• Negation and open vs. closed world reasoning: Sometimes we expect to be reasoning in a closed world setting - i.e., if we do not know something, then it is false - and other times we expect to be reasoning in an open world setting - i.e., if I do not know something, then I do not know if it is true or false. Thus, negation as failure will not always be appropriate. Designers may need to use different notions of reasoning and thus potentially different semantics for negation or "not provable" in different settings.

• Defaults: For the sake of parsimony, we anticipate that it would be helpful to be able to specify default values for slots. The specification of defaults can be viewed as a simple shorthand for specifying knowledge about the world. There are a number of ways of handling defaults and some of them support methods for compiling what appears to be non-monotonic ontologies (containing default information) into ontologies containing only monotonic information. For example, completion semantics can be considered as a simple operational approach. DAML may specify a number of possible semantics for defaults ranging from a simple interpretation of defaults as not much more than comments to a full non-monotonic interpretation.

• Lists/bags/sets of elements with different type restrictions: This description will evolve as our services project evolves. Currently, it appears that there is a need for sets/bags/lists of objects with different type restrictions.