Hans and Gary, (01)
I agree that we need a much clearer mission statement: (02)
HT> This uncertainty is mainly in the question whether you want
> to focus on natural language (in particular English) or also
> on lifecycle information representation, as we do. And will the
> focus be mainly on activity models, like John seems to address? (03)
I don't believe that the major interest of this group is directed
toward NLP, primarily because the focus is on practical results
that can be achieved in a relatively short time. On the other
hand, *if* we do a good job today, it will establish a de facto
standard that will be the foundation for the industry for the
next 20 years or more. During that time, I believe that NLP
software will become more practical and perhaps even the dominant
interface to computer systems sometime between 2015 and 2030. (04)
That is one reason why I have insisted on a *neutral* core that
is not biased toward or against any special approach or method
of reasoning. The core should support all of them equally well.
The detailed axioms belong in the problem-oriented modules. (05)
Re activity diagrams: We have to distinguish the framework from
the hubs and modules. From time to time, the focus of discussion
turns to one or another, but that should not obscure the basic
principle of maintaining a neutral core. My discussion of UML
activity diagrams was primarily to insist that the core should not
be biased *against* them. I would raise an equally loud protest
if anybody tried to bias the core in *favor* of them at the expense
of other approaches. I believe that time and process belong in
the core as *underspecified* categories and that detailed methods
for reasoning about them should be in problem-oriented modules. (06)
GBC> What are the methodologies for organizing the hubs and modules,
relating them to one another? (07)
The terminology of core, hubs, and optional modules is based on
the terms that have been suggested by various contributors to
this discussion. They're more familiar and less abstract than
the infinite lattice of theories that I have been discussing,
but I like them because they can relate that abstract framework
to the practical issues of how to develop ontologies: (08)
1. You can think of the core as a very general theory high up
in the lattice. (09)
2. The hubs are much larger and more specialized theories,
each of which is a specialization of the core. (010)
3. Each hub can be constructed by starting with the core and
adding more terminology and axioms, but still remaining
fairly general -- i.e., not too many problem-oriented
axioms, except those that are universally used within
a particular application domain. (011)
4. The problem-oriented modules are much more specialized
in terms of detailed axioms, but many of them can be
used across many different hubs. An example would be
axioms for 4D spacetime vs. 3+1 D space and time. (012)
My suggestion is to use the lattice as the underlying theory,
and to build the methodology on practical experience in the
software community. (013)
For reference, I'm repeating the statement of the proposal
for core, hubs, and optional modules below. After that is
the URL for the paper on theories. (014)
John
________________________________________________________________ (015)
Summary: The primary task for ONTAC WG is to design a framework
for interoperable systems that may be specialized for different
application domains. I would recommend the following approach: (016)
1. A core ontology that is mostly a neutral taxonomy with very
few detailed axioms, and those axioms should not make any
commitments that would conflict with any reasonable scientific
or engineering principles or techniques. (017)
2. Multiple hub ontologies, which include more detailed taxonomies
for special domains together with prepackaged axioms for the
common methods of talking and reasoning in each domain. (018)
3. An open-ended number of problem-oriented modules, some of which
may be bundled in the packages that are used in one or more hubs,
but any of which could be used independently in connection with
the ontologies of any hub. (019)
4. Methodologies for organizing the hubs and modules, relating
them to one another, registering them in a metadata registry,
and providing tools for assembling, verifying, and testing
modules and hubs. (020)
With this approach, a hub could include as many predefined and
prepackaged definitions and axioms as anyone working in any
specific application domain might desire. However, it would also
support methods for relating hubs and modules and for sprouting
new hubs for new application domains as they are needed. (021)
Following is paper about theories: (022)
http://www.jfsowa.com/logic/theories.htm (023)
I want to emphasize that the lattice of theories is *not* a
proposal. As soon as you adopt first-order logic or many
variations of it, the set of all possible theories that can
be expressed in that logic forms a lattice. My recommendation
is to use that lattice as a guideline for organizing and
relating the core, the hub, and the optional modules. (024)
_________________________________________________________________
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 (025)
|