Scheduled Technical Discussion for February 24, 2005    (9IJ)

Discussion notes    (9IO)

1) language restriction (e.g., OWL-Full => OWL-DL => OWL-Lite)    (9IQ)

2) state everything & only use what is "relevant" to the reasoner    (9IR)

This can be done in two ways:    (9IS)

3) Integrity constraint    (9IW)

See: Robert Kant's work (describes how one ontology relates to another ontology) (part of IEEE SUMO)    (9J3)

involves information outside of that context.    (9J7)

The control of reasoning requires some form of context.    (9J8)

Pease's example in SUMO about RadiatingSound    (9JA)

Are the two ontologies aligned vs. the meaning of that term?    (9JC)

Pat's view: We need "usable ontologies" i.e.,: build tools to understand what the ontology does.    (9JO)

A focusing mechanism is necessary to prune:    (9JR)

Duane => Filter query mechanism EBXML registry repository specification    (9JW)

UN/ECE work defines a rich language for defining context.    (9JY)

symbolic processing of annotations associated with a concept. two logic (e.g., security, provenance, etc..) + another logic.    (9K0)

Dove Gabbay (logician) ==> book circa 1997.    (9K1)

synchronize syntax & semantics with rules.    (9K2)

semantic rule (e.g., implication) + an annotation in another domain (e.g. security, .....)    (9K3)

Analyze the annotations that one can find in the reasoning trace.    (9K4)

e.g:    (9KA)

Duane: a probabilistic view/interpretation of context.    (9KJ)

Andrew: Data management is a recognized problem at NASA. But I think big ontologies are difficult to create, manage, adapt, or sustain. To be successful we need to figure out how to have smaller, specialized ontologies, that can be trusted, joined and unjoined depending on the requirements and privlages of the applications.    (9KU)

NASA's customers are very broad.    (9KV)

Duane: NASA has an ontology, albeit implicitly defined. The problem is to put it into an explicit form that is actually usable by the NASA community.    (9KW)

Dean: TopQuadrant's work on NASA ontologies has been recently written up in a presentation that will be given at Semantic Technology Conference 2005. The presentation is described at and can be downloaded at    (9KX)

Background    (9KY)

Using the analogy associating an ontology as an analog to the concept of a reusable software library with its API, then we can look towards modern approaches of reusable software development practices as an inspiration for modular ontology development. The naive approach for modular, object-oriented software development relies heavily on subclassing as the mechanism to decouple a reusable module (i.e., the superclass) with a specific usage of that module in a given application context (i.e., the subclass that derives from the module's superclass). There is a growing body of evidence that this approach is inherently brittle in software engineering. (for more on this topic, see see Clemens Szyperski's Component Software book, chapters 5 & 6 --    (9KZ)

The analogy holds for formal ontologies as well. Here, "formal ontology" refers to an ontology that has rigorous formalization of some kind suitable for a reasoning process to make inferences based on the ontology's axioms, properties and rules. Well-known examples of formal ontologies include: SUMO, PSL, DOLCE. The OntoClean methodology is an excellent case explaining the pitfalls and limitations of subsumption for organizing extensible or modular ontologies. This has led to the notion of "meta-ontology", initially used as an ontology where the (meta) ontology provides a taxonomy of concepts and properties used for capturing the meaning of things in the application-specific ontology using annotations expressed in terms of the meta-ontology. This idea has been documented in the semantic web best practices group, e.g., with the "classes-as-values" pattern commonly used for annotation purposes.    (9L0)

Problems & questions for discussion    (9L1)

While adequate for documentation purposes, the use of a meta-ontology as an annotation language presents a number of practical problems for OWL ontologies.    (9L2)

Specifically, this means that an ontology may have:    (9LC)

These situations raise a number of questions about reasoning over the annotations of an ontology. In practice, this is not easily doable without a significant amount of tooling effort. Such efforts transform the status of an annotation from that of a comment to that of an logical element in an ontology of annotation attachments. This raises the prospect of shifting from a practice of ontology annotations to "meta-ontology" development, i.e., ontologies about ontologies.    (9LG)

This topic is particularly interesting to me as I am wrestling with practical strategies for applying OntoClean(*) in the context of engineering models, a culture with a large tradition of "attribute=value" parametric view on modeling. In this context, the risk of ontological error in alignming domain-specific vocabularies and taxonomies is very high.    (9LL)

Resources    (9LM)

Session Recording of this "Ontologies & Meta-Ontologies" Technical Discussion Session    (9LT)

 (Thanks to KurtConrad with getting the session recorded.  -ppy)    (9LU)