Ron, Pat, Doug, Matthew, Rob, and Ali, (01)
The responses sound very encouraging, and I hope we can finally work
on the details of a practical project that we could all contribute to,
build on, and use. I'll respond to the notes in roughly chronological
order, but I'd like to start with Ali's note: (02)
AH> I would also suggest that this effort seriously consider using
> COLORE as a container for the preliminary work. Aside from a desire
> to go on to identify a set of ontological primitives, I am having
> difficulty distinguishing the idea of the repository as sketched
> out on this list from that of COLORE. (03)
I agree. Although I've been promoting the lattice of theories for
a long time, I won't claim credit for the foundation, since Adolf
Lindenbaum formulated the basic principles about 80 years ago.
I also agreed in an earlier note that the COLORE relationships are
closely related and compatible with it. They should be included. (04)
AH> You can add OpenCyc to it if you like, and define a metalevel
> relation that indicates that it is somehow "foundational." COLORE
> on its own doesn't enforce such rigidity, rather allowing users
> to identify how ontologies in the repository relate / map to one
> another. You can then utilize / order these mappings in whatever
> way you see fit, i.e. perhaps by enforcing an ontological
> primitive hierarchy. (05)
I agree with the COLORE principles you just stated. (06)
I suggested OpenCyc because it's open source and it's based on 26 years
of practical experience in developing and using a very large formal
ontology. But I called it a *starting* ontology, not a foundation.
As we add more ontologies to the mix, we may find some common subset
that would more properly deserve the term 'foundational'. (07)
AH> Also, my note below isn't meant to suggest that descriptions in
> Common Logic or whatever formalism _captures entirely_ whatever it
> is we're representing in a formal ontology.... (08)
Yes, indeed. There will be a need for metadata that includes
commentary, reviews, and other information, which may be stated in
natural languages and/or more formal notations. Those are issues
that will need to be clarified in the guidelines. (09)
AH> Lastly, the idea of logical "primitives" isn't really new,
> though it hasn't quite been articulated or implemented in the
> way I sketched out below.... (010)
I agree. This is another issue that will have to be clarified
and explained in the guidelines. In fact, we might not have
a clear idea of what kind of primitives we should have until
somebody develops a clearly specified set of them and
demonstrates how they can be used to define other terms. (011)
RW> I think that the reviews and statements of compatibility between
> overlapping and complementary ontologies will be needed to provide
> users with the ability to pick components to incorporate into
> applications. (012)
Yes. And the best kind of reviews would come from practical
experience by people who used the ontologies to design and
implement applications that were actually deployed. (013)
RW> Once there is some evidence of progress, funding will flow to
> the project. This will grow as large organizations start to
> incorporate the ontologies into their critical processes... (014)
Yes. We need to build something that people can actually use.
That is one reason for choosing OpenCyc as a starting ontology:
it's useful right now, and the hierarchy of theories can
accommodate whatever additions/modifications anyone prefers. (015)
JFS>> The lingua franca for translations among all the logics would
>> require at least the expressive power of Common Logic and
>> preferably IKL. (016)
PC> Agreed that before it can support translations among ontologies,
> an FO needs to be expressed in FOL and preferably IKL. The immediate
> problem with that is the absence of free easy-to-use utilities such
> as are available for OWL. (017)
I agree that tools are needed. But note that KIF tools have been
developed and used for over 15 years, and they were used in many
projects, including SUMO. Adapting the KIF tools to CL can be
done, but people haven't had much incentive to do so as long as
this group has been a debating society. (018)
There are over 20+ years of tools for conceptual graphs, which
is the other dialect for CL. But without any visible momentum on
using CL, nobody had much incentive to include it. At VivoMind,
we translate CGIF to and from CLIF and other notations, and if
this project gets going we can donate some tools to the cause. (019)
But the first thing we have to do is to demonstrate that we are
serious about developing this project. (020)
PC> Once that has been decided, there are still other issues
> concerning the reasoning method, but those can wait. (021)
The word 'method' should be in the plural. Cyc has about 37
different reasoning engines, which are used for different kinds
of problems with different requirements for expressive power.
Even more generally, multiple reasoners that use induction,
abduction, and analogy in addition to deduction can be used: (022)
http://www.jfsowa.com/pubs/paradigm.pdf
Two Paradigms Are Better Than One,
And Multiple Paradigms Are Even Better (023)
DF> Rules stated for funded projects and reasoning using such rules
> is always carried out in narrowly defined microtheories. A project
> may have multiple contradictory theory microtheories which are used
> with the same data microtheory in differing reasoning microtheories,
> to explore the differences between different theories. (024)
I agree. (025)
RF>> If the entire list is willing to get behind a project which takes
>> as its grounding principle that there is no single complete theory,
>> that may be the best we can hope for at this stage, and I would like
>> to encourage that. (026)
DF> I am finding a lot of agreement with this. I hope we can all
> support John's proposal. (027)
Sounds good. But I'm not claiming ownership of the proposal, and
I hope we can all contribute. (028)
PC> But the principle that I had hoped would make the project more
> feasible is not to *include* every ontology element in the FO
> itself, but to leave them in the domain or linked ontologies. (029)
We can adopt some guidelines along those lines. (030)
PC> The effort on gaining agreement among the participants would focus
> only on those more basic elements that are needed for *translation*
> among the domain ontologies - those would prima facie be the elements
> needed for the FO. Now, John has suggested that the meaning of
> "Foundation Ontology" be expanded to include everything linked to
> the common base (I think there already is a name for that - the
> "lattice of theories"). (031)
The most important point is to get agreement on the principles and
not let the choice of names get in the way. As we continue, we may
find some components and terms more fundamental than others. They
could be renamed the Foundation Ontology. (032)
PC> Those are the elements that are in common among more than a few
> domains. I am not sure that there are more than 10,000 of those,
> and that was what I was referring to. (033)
RW> From recent discussions, it appears that there might be several
> cores that are equally valid and useful but not compatible.
> This is not particularly convenient but reality is not obliged
> to be convenient. (034)
MW> I have been talking about what I called "abstract theories"
> being theories that were independent of 3D/4D (for example) but
> could be combined with either, and of course 3D and 4D themselves.
> I think this is where your [PC's] ambition of a "Foundation Ontology"
> properly lies in terms of being the elements that other ontologies
> can be built out of. (035)
These are important issues that must be explored. What Matthew
calls "abstract theories" are underspecified general theories that
can be consistent with multiple specializations (e.g., 3D and 4D),
which may be inconsistent among themselves. For example, a term
labeled 'PointInTime' can be introduced in an underspecified
general theory and used in multiple incompatible specializations. (036)
PC> As John has presented it, there should be room within such a
> project for diverse goals and viewpoints. I am still concerned
> that the starting point needs to be comprehensible enough not
> to scare away potential participants. So, let us consider what,
> concretely will be the starting point: ontology, visualization
> tool, reasoner, and other things. (037)
We should develop an inventory of what is available now or with
a minimal amount of effort. Then we should develop guidelines
that put everything in perspective. There will need to be
tutorials that show how everything is related. (038)
PC> Does the intention to start with the whole OpenCyc mean that
> we should commit to using the whole OpenCyc system? (039)
It only implies that the OpenCyc ontology would be supported by
the framework. Therefore, anybody who uses OpenCyc today could
continue to use it, even though other ontologies will be added.
Some parts of OpenCyc might be put in general theories high up
in the hierarchy, and other parts might be in the more specialized
areas lower down. There may also other theories from various
sources that are inconsistent with some parts of OpenCyc. (But
the Cyc microtheories accommodate such possibilities.) (040)
As for the tools, I would assume an open-ended and growing
collection of tools of all kinds. Anything that is available
for OpenCyc could be used by anybody who likes it, but that
does not rule out the development of new tools from other
sources with different perspectives. (041)
AH> I would suggest the following things need to be considered: (042)
Before getting to the details, please note that 'hierarchy' refers
to the finite subset of implemented theories. There should always be
a mapping (homomorphism) from the hierarchy to the infinite lattice.
But it is not an isomorphism, it might not be a monomorphism, and
many relations implied by the hierarchy might not be indicated
until somebody (or some program) discovers them. (043)
AH> What is the granularity of a module that one would wish to allow?
> A single statement in logic is ostensibly a theory, and can be
> considered a module. However, this leads to an exponential
> proliferation of modules. Any repository should have some
> guidelines as to what constitutes a module. (044)
The lattice allows modules of any size. But the guidelines for the
hierarchy can distinguish preferred theories in a "core" or "FO"
from those that are outside the core. The guidelines might also
state recommendations such as "One-axiom subsets will not be stored
explicitly, unless there are strong reasons for doing so." (045)
AH> Allowing and capturing all different (but logically equivalent)
> axiomatizations of an intuition is laudable goal, but it introduces
> serious problems in terms of _possibly_ exponential growth for the
> repository... (046)
The lattice of all theories is infinite. It doesn't "grow" because
it is always as big as it can be. But the guidelines can specify
various rules, regulations, and restrictions on what is stored,
what is highlighted, what is deprecated, what has been contributed
but not vetted, what is archived, etc. (047)
AH> I humbly suggest there are two ways one can construct "upper
> ontologies" ... (048)
We shouldn't rule out anything. We might recommend some
methodologies and provide tools to support them. But anyone
who invents a better mousetrap or ontology trap should be
able to contribute it. (049)
We should accommodate all the approaches you mentioned, and
any others that anyone might invent. Note that SourceForge is
all inclusive in what it accepts. We can adapt similar rules
for what can be contributed. Before vetting, a contribution
could be listed as untested. Later, it could be highlighted,
recommended, suggested, neutral, deprecated, or rejected. (050)
AH> ... check out the forthcoming FOIS 2010 proceedings. There will be
> a paper there that will quite rigorously spell out many (though not
> all) of the possible connections / mappings between theories (both
> ontologically and logically). It would probably save a lot of effort
> in terms of reinventing wheels and should help clarify many of the
> issues that undertaking the creation of such a repository will entail. (051)
Sounds good. Please contribute those ideas to the guidelines. (052)
Ideally, we should consider the proposed ontology as the focus of
a growing collection of tools and applications. We could consider
Eclipse ( http://www.eclipse.org/ ) as an example of what a platform
for ontology development might become. Some tools may be open source
and free, but others could be proprietary. (053)
John (054)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: 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 join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
To Post: mailto:ontolog-forum@xxxxxxxxxxxxxxxx (055)
|