...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