Ontology

veryard projects > information management > ontology

ontology matters

requirements

on this page

on other pages

Ontology is a pretentious label for an important and much-misunderstood concept.

Veryard Projects deals with practical issues of communication and collaboration, and this requires a subtle grasp of the power of language to connect people and organizations with different ways of speaking and operating - and an alertness to the primary causes of communication failure.

The biggest reason why communication fails is because we're not talking about the same thing. Ontology is just a fancy way of referring to the things we're talking about - or to the things we imagine others are talking about.

In Information Systems, attention to Deep Ontology gives us ways of solving problems relating to Adaptive Systems, Legacy Systems, and System Integration, among others.

Surface
Ontology
(system)

System as
Designed

Deep
Ontology
(system)

System
in Use

Deep
Ontology
(domain)

Ideal
System

the negotiation of existence

the grain of existence

the denial of existence

the imposition of meaning

sources and resources

information management

information notions

information coordination

data translation & mapping

muggle ontology

from Surface Ontology to Deep Ontology

veryard projects > information management > ontology > surface / deep

Ontology	A model of a system that describes the things that the system references. In particular, this model describes how the identity and difference of these things is reflected in the system.
Surface / Espoused Ontology	An ontology (ontological model) of a system that can be constructed or derived by inspection of the specification and design of the system. In general, this is the ontology that is most easily visible from the development perspective.
Deep Ontology / Ontology "In Use"	An ontology (ontological model) of a system that explains the behaviour and/or content of a system. In general, this ontology differs from the "surface" ontology, and is derived through an "digging" or "archaeological" process.
Topological Metaphors	The terms "surface" and "deep" may be regarded as metaphorical labels. The processes connecting and separating "surface" and "deep" are interesting and worthy of study. However, we do not prejudge the nature of these processes.
Value Proposition	The surface ontology is inadequate for certain purposes. The deep ontology is worth having, among other things, because it reveals some essential characteristics of the system-in-use, especially over time. Furthermore, analysis of the differences between the surface ontology and the deep ontology provides both theoretical critique and practical feedback to the development process/perspective. Therefore the process of "digging" for the deep ontology is a worthwhile activity.

Surface
Ontology
(system)

System as
Designed

Deep
Ontology
(system)

System
in Use

Deep
Ontology
(domain)

Ideal
System

Tactics for Sharing Ontologies

veryard projects > information management > ontology > sharing tactics

	Seek agreement on vocabulary and behaviour
	Accept and accommodate differences in vocabulary and behaviour
	Tolerate uncertainty and surprise in communication and transaction

The Negotiation of Existence - Common Vocabulary and Behaviour

In the past, it was assumed that collaboration needed a shared ontology - a single unified domain model. We may now accept that collaboration merely needs a recognition of the other.

Ontology is always provisional. We act as if we can be sure what our collaborators mean/intend - but however careful the analysis, there is always scope for surprise and uncertainty.

Web Service Strategy

The Grain of Existence

veryard projects > information management > ontology > grain

When you are modelling something from a single perspective, granularity is often not very important. A single data item is modelled as a single attribute, with a defined granularity. Granularity is not seen as much of an issue for database design – although I think it should be – but it cannot be avoided as an issue for system integration.

Granularity becomes an important issue for data modelling when you are trying to map or merge information across multiple systems or data stores – because the likelihood is that the granularity doesn’t match. It is an issue for the flexibility of the data model and artefacts designed from it.

Granularity is also a problem with distributed systems, especially where web services are involved, since it may affect the number of service calls across a network, perhaps by an order of magnitude. It may also affect the burstiness of the distribution of service.

And when you are trying to merge data from several sources into a single data warehouse, there are significant technical performance implications of the granularity decision. Some data warehouse experts recommend storing everything into the data warehouse as atomic data – on the grounds that the atomic level is the most stable level, and also represents the highest common factor – but this approach is problematic in some domains. In any case, it places a great burden on the conceptual data modelling phase, to ensure that the atomic level has been correctly identified.

Simplistic data modelling assumes that there is a clear distinction between atomic data and derived (molecular) data – but it doesn’t work out as clearly as this in practice, and this issue may have sweeping implications for system architecture and design.

Granularity has several dimensions, including time granularity and space – such as the size of the geographical clusters into which customers may be classified.

Grain

Hauntology - The Denial of Existence

veryard projects > information management > ontology > hauntology

If ontology is a pretentious way of referring to what there is, hauntology is a tongue-in-cheek way of referring to what there
isn't.

Derrida invented the term ‘hauntology’ to refer to the logic of the ghost. In French, the word ‘hauntology’ sounds identical to
the word ‘ontology’, which it is part of Derrida’s purpose to critique.

Traditional data methodologies have been fairly naïve about ontology, and Derrida’s coinword provides us with clues for
deconstructing these methodologies and the systems that have resulted from them. But further, the word points to the fact that
data frequent organizations, like the traces of past events.

Data are spectral/imaginary. They provide a view/image/spectre of the organization and/or its environment. Data architecture, on
the other hand, is an attempt to impose a symbolic order/logic onto the raw data.

In the absence of daylight, we are haunted by ghosts and moths, which pass through walls and create holes in beloved fabrics.
In my 1994 book, following Christopher Alexander, I postulated the ethic of the data architect as an ethic of repair: on a
never-ending quest to mend the holes in the fabric. For the post-modern data architect, in contrast, the holes attract attention in
their own right.

Sources and Resources - References and Links

veryard projects > information management > ontology > sources and resources

	IT eBusiness	Hotlinks to some of the main sites: BizTalk, ebXML Ontology.Org Some excellent papers on the enablers for eBusiness.
	Philosophy General	Buffalo Ontology Website Descriptive and Formal Ontology (Raul Corrazon) University of Bremen
	Papers	"Ontology management in enterprises" by Z Cui, VAM Tamma and F Bellifemine. BT Technical Journal Vol 17 No 4, October 1999

veryard projects > information management > ontology