In response to three of John Sowa's comments: (01)
(1) [John Sowa] The major problem is that there is no document that
precisely
defines the "aim of this group":
> [Michael Gruninger] I do not think that it fits into the aim of this
group. (02)
1.1 The "aim of this group" is defined in the charter: (03)
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatin
gWG
1.2 The current status of existing ONTACWG projects was listed in
the message at:
http://colab.cim3.net/forum/ontac-forum/2005-12/msg00114.html (04)
You should note in both cases that the emphasis was on actual
construction of computational resources. At present this means: the web
site with pointers to resources and ongoing work; the effort to define
requirements for a registry that will allow precise specification of
relations among knowledge classifications: and the adoption of a Common
Semantic Model (an ontology or lattice of ontologies) that will serve
to provide the conceptual defining vocabulary for all of the ontologies
and terminologies that are of interest to ONTACWG members. Other
projects may be suggested by members. (05)
Although discussion of basic issues is certainly a necessary part of
preparing for concrete effort, the emphasis has to be on actual
building of the resources that may be useful. Just one of the nine
bullets in the charter (i.e. the "aim of this group") mentions
discussion. That is a reasonable guide: The ratio of work to
discussion could profitably be about 8:1. Thus far the ratio has been
considerably lower. At the initial phase this should not be
surprising. I hope we can get quickly beyond this initial phase. (06)
1.3 I would suggest that to keep the focus on constructive effort,
those who wish to comment on the efforts of this group first make a
concrete proposal regarding the structure of some computational
artifact that can help advance the goals of this group. If nothing
else comes to mind, by default, I would suggest that one provide a
specific comment on the structure or content of the merged TopLevel of
OpenCyc, SUMO, and DOLCE (with some elements of BFO and ISO15926) which
I placed on our site at:
http://colab.cim3.net/cgi-bin/wiki.pl?CosmoWG/TopLevel (07)
An OWL version of that hierarchy is at: (08)
http://colab.cim3.net/file/work/SICoP/ontac/reference/ProtegeOntologies
/COSMOtopOWL03.owl (09)
Specific comments on specific artifacts will help this group to learn
what its members believe will be useful. (010)
1.4 To date, among the more general comments have been the
suggestions;
1.4.1 That the COSMO should or may be a lattice of ontologies
rather than a single logically coherent ontology
1.4.2 That getting wide agreement will be facilitated by having a
small and sparsely axiomatized common ontology rather than something as
complex as one of the existing upper ontologies. (011)
As best I can tell there is little or no disagreement with 1.4.1.
As for 1.4.2, it is still not clear just how large or small the
common ontology can be and still function both as a commonly accepted
ontology and as a useful artifact that can promote interoperability. I
strongly suggest that we discover the answer to the unresolved size
question by building that ontology and learning in practice which
different views cannot be accommodated within a single logically
coherent ontology. From that point, we can discover what the structure
of the lattice would have to be to include a wider range of concepts. (012)
(2) [John Sowa] After spending their first 5 years with interpretation
#1, the
Cyc project abandoned it around 1990 in favor of interpretation #3.
I can't imagine that anybody seriously believes that the ONTAC WG
can accomplish what Cyc failed to do in anything less than the
21 years Cyc has already spent. (013)
I believe that OpenCyc in its current form would provide an adequate
technical basis for a Common Semantic Model that could specify meanings
and thereby relations among the different Knowledge Classification
Systems. So would SUMO. It is therefore not necessary to "accomplish
what Cyc failed to do" - technically. The problem at this stage is not
technical - indeed we are not trying to solve unresolved technical
problems, or to do anything technical that Cyc or SUMO has not already
done. Our problem in developing a COSMO is sociological - we are
trying to find out what ontology or subset can be agreed on by most of
the participants in ONTACWG as adequate for their purposes. To do
this, it will probably have to be a lot simpler than Cyc, whose
complexity is daunting. I have proposed a very simple merged hierarchy
as the barest starting point to try to discover the points of
agreement. To be useful, this bare outline will have to be expanded,
but the expansion should be done in stages that can be reviewed and
understood by our whole community at each step. I do not believe that
the solution to interoperability will become clear by further
discussion, but by building a community-satisfactory ontology (or
lattice) for that purpose and testing it, in increasingly complex
reasoning tasks. (014)
Semantic Interoperability merely means that systems using semantic
content be able to share their semantic content. Our common
representation does not have to be any more semantically rich or
technically complex than any existing system used for inferencing. It
just has to be adequate to express what they express, and agreed on by
the community that wants to interoperate. (015)
The problem is complex enough, please don't make it sound any more
complex than it is. (016)
(3) On the question of a defining vocabulary for predicates:
[John Sowa - characterizing Cyc's initial goal] 1. There shall be
*one* single consistent theory that defines *all* the predicates (or
concept & relation types) that are permissible in any message passed
between any two systems that claim to adhere to the ONTAC standards. (017)
This presents a very interesting question, and if anyone actually
have any data on the issue, it would be very enlightening for us.
Every OpenCyc microtheory uses the "BaseKB" as a common foundation. I
am aware of some microtheories that are logically inconsistent with
some other microtheories (not with the BaseKB), but many microtheories
seem to be created merely for computational efficiency purposes, not
because they are actually inconsistent with others. We are still left
with the question of whether any microtheories (which ones?) require
concepts in their axiomatic definition that are not already in the
BaseKB - either directly or by transitive closure of the definitions.
To answer that question we would have to agree on (a) what constitutes
a primitive not fully-axiomatized predicate; and (b) what axioms are
actually used for the predicate definitions. The latter is a problem,
since the axiomatic definitions of the predicates have not been made
public by Cyc. (018)
It will be extremely interesting and informative to discover which
of the predicates in the Cyc microtheories cannot be specified by the
conceptual elements of the BaseKB -- i.e., which of them are truly
primitive in the Cyc system. If anyone has any example of a
microtheory predicate which is known to be primitive -- not definable
via concepts used in the BaseKB, please provide us with that
information. Only concrete examples of logically incompatible axioms
will provide us with the information necessary to determine what the
structure of a lattice of ontologies will actually be. (019)
Unless we can get specific examples of concepts in the microtheories
that are not specified using concepts in the BaseKB, we cannot know if
Cyc BaseKB provides an example of successful use of a defining
vocabulary, or not. And if not, we would still need to know whether
the Cyc designers decided not to bother creating definitions out of
time pressure, convenience, or computational efficiency rather than
because of some principled logical requirement. We can anticipate that
there will in fact be some logical inconsistencies in some context
(microtheory) representations - whether in Cyc or any other large
ontology - that will require creating new nodes in a lattice of
ontologies. But we are interested in finding the maximal potential for
agreement, and for that we need to know which predicates in
microtheories are (1) logically incompatible, or (2) undefinable using
only BaseKB concepts. If Cyc is going to be cited as exemplifying some
principle, we need very specific details of how it illustrates that
principle. Saying that something can't be done because some individual
or company didn't do it is not only a logical non-sequitur, it
conflates multiple potential reasons for things not getting done. (020)
Rather than wondering or debating just what it is that Cyc has done
(without detailed inside information) I would think it more productive
to do as much as we can and see how far we can get. We don't have to
reinvent things already created, just decide which ones of them to use. (021)
Pat (022)
Patrick Cassidy
MITRE Corporation
260 Industrial Way
Eatontown, NJ 07724
Mail Stop: MNJE
Phone: 732-578-6340
Cell: 908-565-4053
Fax: 732-578-6012
Email: pcassidy@xxxxxxxxx (023)
-----Original Message-----
From: ontac-forum-bounces@xxxxxxxxxxxxxx
[mailto:ontac-forum-bounces@xxxxxxxxxxxxxx] On Behalf Of John F. Sowa
Sent: Wednesday, January 11, 2006 1:50 AM
To: Michael Gruninger
Cc: 'SUO WG'; CG; ONTAC-WG General Discussion
Subject: Re: [ontac-forum] Re: The world may fundamentally be
inexplicable (024)
Michael, (025)
The major problem is that there is no document that precisely
defines the "aim of this group": (026)
> I do not think that it fits into the aim of this group. (027)
Following are three possible interpretations of the ONTAC goals: (028)
1. There shall be *one* single consistent theory that defines
*all* the predicates (or concept & relation types) that are
permissible in any message passed between any two systems
that claim to adhere to the ONTAC standards. (029)
2. There shall be a *family* of theories, each registered in a
metadata registry as specified by ISO 11179, and any message
passed between any two systems that adhere to the ONTAC
standards shall specify which theory or theories are assumed
to define the predicates that occur in that message. (030)
3. The theories specified in #2 shall consist of one central
core theory that is required and a family of optional
theories, each of which is consistent with the central
core. Any message passed between any two systems that
adhere to the ONTAC standards shall specify which theory
or theories are assumed *in addition to* the required core. (031)
After spending their first 5 years with interpretation #1, the
Cyc project abandoned it around 1990 in favor of interpretation #3.
I can't imagine that anybody seriously believes that the ONTAC WG
can accomplish what Cyc failed to do in anything less than the
21 years Cyc has already spent. (032)
Therefore, I believe that interpretation #3 is the only one we can
seriously contemplate on any reasonable time frame (i.e., something
considerably less than 21 years). Given that assumption, the main
questions to address are (033)
1. How big is the central core? What axioms shall be required? (034)
2. How do we relate the optional theories to one another and
to the central core? (035)
3. How do we handle messages passed between systems that use
different (and possibly inconsistent) optional theories? (036)
4. And most importantly, how will legacy systems communicate
with the new systems -- despite the fact that *none* of them
can be assumed to be consistent with the axioms of the core,
let alone the far more detailed axioms of the other theories? (037)
The point that I have been trying to make for the past five years
of the SUO project and the past 3 months of the ONTAC WG is that
unless these questions are addressed, there is no hope that any
of this effort will be of any value whatever to the people who
have day jobs working for managers who expect results. (038)
> ... we should at least agree on the language for specifying the
> ontologies. Common Logic seems a reasonable candidate for this
> purpose. (039)
I'm happy with that choice, but I also realize that the overwhelming
majority of the developers who will be expected to use the ONTAC WG
ontology are far more familiar with UML than with any CL dialect.
Even RDF and OWL are unfamiliar to most of them. (040)
> I was asking for a set of axioms in the language of FOL whose
> models are isomorphic to the model theory of pi calculus. (041)
You can represent pi calculus in FOL. Some axiomatizations may
use more exotic languages, but they're not required. (042)
In any case, I don't expect the programmers to master pi calculus.
But there are very widely used subsets of pi calculus that have
been used for years -- examples include PERT charts, UML activity
diagrams, Petri nets, etc. A major reason why the business
process modeling people have adopted pi calculus is that it is
the natural next step beyond what most programmers already know
-- namely PERT charts and UML activity diagrams (both of which
can easily be axiomatized in Common Logic). (043)
> But that's sort of my point -- how can pi calculus be a module
> if it is not specified as a set of axioms in the same language
> as every other module? (044)
I assume that there will be a *family* of theories of various levels
of detail, all of which can be axiomatized in some dialect of CL.
Translating PERT charts and UML activity diagrams into CL is trivial
compared to the task of teaching programmers PSL and situation
calculus. (045)
> ... There are many queries about processes that do not require
> explicitly using time, and you may want to answer queries about
> time without committing to all assumptions of a particular
> process ontology. If these two are too tightly coupled, you
> lose modularity, sharability and reusability. (046)
You are preaching to the choir. I have been trying to make the
point that the number of axioms required in the core should be
very small. In fact, the only consensus view about time is that
any notation should be translatable to UTC format. (047)
I would put all methods for reasoning about interactions between
time and processes into the optional modules -- that includes PSL,
PERT charts (as translated to some dialect of CL) and many other
versions that assume pi calculus or situation calculus or whatever. (048)
> Again, how can different modules be compared if they are written
> in different languages with different model theories. (049)
Excellent question. First, we could assume that all modules are
written in some dialect of Common Logic. Then we proceed as follows: (050)
http://www.jfsowa.com/logic/theories.htm
Theories, Models, Reasoning, Language, and Truth (051)
> ... but I thought that our objective here was to build some common
> ontologies, not reproduce the semantic integration problem. (052)
If a common ontology would magically solve all the problems, we could
just recommend Cyc and declare a victory. Cyc has been trying to do
that for 21 years without having anything that can pay the rent --
they still depend on government handouts for their continued existence. (053)
Unless we can provide a migration path for legacy systems, we have
done *nothing* that anybody would actually use. People are not going
to flip a switch tomorrow and magically have trillions of dollars of
software that conforms to whatever axioms the ONTAC WG proposes. (054)
> Given two first-order ontologies that intuitively cover the same
> concepts, you can try to find a weaker common theory such that both
> of the initial ontologies are consistent extension of the common
> theory. (055)
Yes, that is the recommendation of the theories.htm paper. (056)
> How do you hope to do this between pi calculus and any other
> first-order ontology of process? (057)
Some theories, such as PERT charts and Petri nets, are already
subsets of pi calculus. Others may have more complex mappings,
and the only common assumption might be that all times can be
translated to UTC format -- but that's not necessarily bad. (058)
For 99.97% of the databases in the world, the times recorded
in the DB do not include any information about how those times
were derived. That means, we can assume that messages that
assert event E happened at time T can be passed among systems
with no assumptions beyond the common core (i.e., that the
times can be translated to UTC format). (059)
Of course, more can and should be done, but version 1.0 must
be able to accommodate legacy systems before we can add new
features that really take advantage of the ontology. (060)
John (061)
_________________________________________________________________
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/OntologyTaxonomyCoordinatin
gWG (062)
_________________________________________________________________
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 (063)
|