|
John, We need to be very cautious about over-use of hierarchical structures, particularly when we're talking about inheritance behavior. It is important to separate faceted taxonomies and network taxonomies from hierarchies -- there is a significant risk of unintended consequences when we don't specify behavior clearly. There may be a hierarchy of 'types' of objects -- however, that characterization does not necessarily translate to a hierarchical architecture for a content object. And, a hierarchy of 'types' of objects may be only provide values for a single attribute in a faceted taxonomy. This is one reason why I think it is very important to ground ontology discussions in information architecture and to contextualize the discussions. Our 'ontology' is comprised of multiple reference sources, each of which has its own data structure, business logic and governance structures. The ontology is in fact realized when the reference structures are implemented in particular applications. And, the range of applications is potentially extensive. We have drafted a contextualization strategy which identifies several applications which would leverage all or parts of our ontology. Best regards, Denise Bedford World Bank -----ontac-forum-bounces@xxxxxxxxxxxxxx wrote: -----
To: ONTAC-WG General Discussion <ontac-forum@xxxxxxxxxxxxxx>
From: "John F. Sowa" <sowa@xxxxxxxxxxx>
Sent by: ontac-forum-bounces@xxxxxxxxxxxxxx
Date: 10/16/2005 02:13AM
Subject: [ontac-forum] Hierarchies of objects and theories
Eric,
That is true of most current ontologies:
EP> The only way that ontologies can form a lattice is when
> they depend and build upon one another like Ontolingua
> or Cyc microtheories. If we were to take the existing
> upper ontologies, they would form a *completely* flat
> lattice because they are not monotonic variants of one another.
But that is because they were not designed in a systematic way.
A lattice is nothing more nor less than a systematic
multiple inheritance hierarchy. In object-oriented systems,
such hierarchies have proved to be useful for defining
new objects and new types of objects by inheriting
structures and definitions from more general types.
Each object in an O-O hierarchy has an associated theory:
namely, the set of axioms that describe the structures
and properties of each object type or instance and the
preconditions and postconditions of the methods of each type.
Although such theories are not usually stated explicitly,
they could and would be stated, if there were any tools
that could make use of such statements effectively.
Whenever you define a new object as an instance of some
type, that object inherits a theory, which is the union of
all the axioms of all the theories associated with that
type and its supertypes. As soon as you make assignments
to any of the local variables of that new instance, you add
new information, which effectively creates a new theory,
which is the union of the theory from which it was created
together with the new information that distinguishes the
instance from its type and its other siblings.
In effect, an O-O library or collection of libraries is
hierarchy of objects defined by a hierarchy of theories
(explicit or implicit). A running program builds on that
hierarchy by creating new instances, each of which has
its own associated theory that specializes the theories
of the type from which it was created.
But if you look at the programs that were created before
O-O systems became available, you would have found a much
flatter system of theories, in which every program had its
own theory, which was not related in any systematic way to
the theories that describe any other program.
Today, ontology development is at roughly the same level
of sophistication as program development in the 1960s.
Each one is a monolithic lump, which does not take advantage
of the all the lessons learned by the programming community:
structured design, modular design, O-O design, etc.
The procedural methodologies don't carry over exactly to
the declarative, logic-based languages, but there are many
structural similarities. When I talk about a lattice of
theories, all I'm saying is that we should take advantage
of structured, modular, inheritance methodologies that have
proved to be useful in the programming community and adapt
them to ontology design, development, sharing, use, and reuse.
John Sowa
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-forum/
To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/ontac-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-forum/
To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/ontac-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG (01)
|