Re: [ontolog-forum] Two ontologies that are inconsistent but both needed

[Kathryn Blackmond Laskey <klaskey@xxxxxxx>]

> ...If one group, however, 
> believed Newton's laws would do the job
> for them, and the other group 
> believed the spirit of Napoleon moves the cars on schedule, it'd be
> unlikely they'd come to an
> agreement.

And if they agreed to disagree, and set about building systems, the ones who did it on the basis of Newton would get systems that worked, whereas the others would get systems that didn't work.  Natural selection would weed out the ones whose trains crashed because Napoleon didn't come through for them.

> I'll pose this question to the list as
> I've posed it before to many 
> others, most of whom have failed to give
> a satisfactory reply - if 
> ontology-building is an exercise in application-specific
> modeling 
> among a constrained group of users, then why is it not just a
> variant 
> on what we already do with UML which goes under the more
> pedestrian 
> name of data modeling?

I don't think that's what ontology-building is.  In yesterday's email, I said I wouldn't call the artifacts I've developed ontologies.

Here is a quote from Paulo Costa's dissertation about the differences between ontologies and database schemas:

Apart from the extra expressivity that is necessary to perform reasoning with the concepts represented in an ontology, the many similarities with database schemas makes it difficult to draw a clear distinction between ontologies and database schemas. Spyns, Meersman, and Jarrar (2002) provide an interesting discussion of how the two concepts differ. They regard data models (i.e. databases, XML schemas, etc) as specifications of the structure and integrity constraints of data sets. Thus, a database schema is developed to address the specific needs and tasks for which the data set is being used, which in turn depends heavily on the enterprise being modeled.
In contrast, ontologies are intended to be applied across a broad range of tasks within a domain, and usually contain a vocabulary (terms and labels), a definition of the concepts and their respective relationships within that domain. The main objective of an ontology is to provide a formal, agreed and shared resource, which forces it to be as generic and task-independent as possible. Although an ontology typically is developed to a focused task, it is desirable for an ontology to capture rich semantic content in a manner that could be reused across tasks.

In developing a database schema, the goal is different. Schema developers focus on organizing information in ways that optimize support for the types of queries that are expected to arise in specific applications for which the database is being designed. Achieving such goal typically requires a special application to be written on top of the database mechanism that (for a relational database) implements the principles of relational algebra. Furthermore, a database schema is typically developed under a closed world assumption, in which the only possible instances of a given relation are those implied by the objects existing in the database. (i.e. if something is not represented there then it doesn't exist).

Ontologies, on the other hand, do not necessarily carry the assumption that not being represented entails non-existence. Not having the closed world assumption means, for example, that queries about which there is insufficient information in an ontology to be proved cannot be assumed as being false. As a consequence, we should expect situations in which incomplete information within an ontology prevents a definitive answer to a query to be rather normal. This is a clear sign that uncertainty is an intrinsic component of ontology engineering, and therefore ontology languages must include sound and principled mechanisms for dealing with uncertainty.

One commonality between ontologies and database schemas is the need to provide for interoperability among systems based on different schemas and/or ontologies. In an increasingly interconnected world, the ability to exchange data as seamlessly as possible is one of the most desired features of a knowledge representation. Integrating systems created and managed by separate organizations, evolving in different scenarios, and geared to different needs and perspectives is a task that poses many challenges, even when dealing with apparently very similar structures.

Kathy

_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/  
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/  
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/ 
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx    (01)