Lessons Learned using DAML-ONT for Markup
General KSL KB Development Overview
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
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
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,
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
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
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
- The List collection type should be specified in greater detail.
The DAML-ONT specification states that the <li> syntax from RDF has
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
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
It would also be instructive to include the motivation for the
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
Suggested DAML-L Features
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.
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.,
- 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).
- 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
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
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
- 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.
Last modified: Sunday, 03-Jul-2005 06:07:02 PDT