John,
I tend to prefer action to talk, so your suggestion is certainly welcome.
I do have a few questions: (01)
[JFS] > > Before getting to the details of your notes, I'd like to clarify
the
> term FO, which Pat introduced for a Foundation Ontology. I have no
> objection to using the term FO, but I would apply it to the totality
> of the theories (or microtheories) in an OOR. The Cyc example of an
> upper ontology with many specialized microtheories would be an example.
>
> However, I would broaden the idea to support multiple theories at the
> upper levels, which might be incompatible. For example, Matthew,
> Chris P, and Pat H have strongly supported a 4D ontology for the upper
> levels, but many other people prefer to use a 3D upper level. For
> many of the lower level microtheories, the differences between a 3D
> vs 4D foundation are irrelevant.
>
Do you envision this particular version of an oor as one in which all of
the ontologies are related to each other by subsumption from some "BaseKB"
as in CYC? Or would you include ontologies that do not have their relations
to the base starting ontology fully specified? Your later comment: "[JS] >
Yes. That is why I would prefer to use the name Foundation Ontology
for the full hierarchy of all the theories in the OOR." Suggests the
former. (02)
[JFS] > >
> 2. Therefore, I recommend that we adopt the OpenCyc terms together
> with the axioms available in OpenCyc as a "starter set" for
> developing the Foundation Ontology.
>
Did you have any particular version of OpenCyc in mind? I have been using
the v0.78 OWL version, but even that has 25,000 terms in it (later versions
have over 200,000 terms). About half the terms in my current COSMO (3400
out of 7500) have pointers to similar terms in the OpenCyc. The Umbel
project (http://umbel.org/) extracted 20,000 out of the 200,000+ terms in
OpenCyc to use as subject headings to help disambiguate web pages. Would
that be a better place to start than the full OpenCyc? (The Umbel files are
in N3 format - anyone know of a converter to OWL?). (03)
[JFS] >
> 3. But we would also welcome and encourage anybody with different
> preferences to contribute more terms and theories to the FO.
>
Do you anticipate including alternative representations of the same
entities, with translations?
I will provide an example: (04)
In CYC, attributes are generally represented as object-with-attribute rather
than as attributes per se. For example the concept "angry" is a kind of
person:
<owl:Class rdf:ID="Angry">
<rdfs:comment>A specialization of #$IntelligentAgent. Each
instance is an agent in the emotional state of being angry.
Use this constant with a #$GenericValueFunction to denote a
collection of agents that are in this emotional state to
some varying degree.</rdfs:comment>
<guid>15a46c42-42cd-11d6-8000-0002b38bcf96</guid>
<rdf:type rdf:resource="#AgentTypeByEmotionalState"/>
<rdfs:subClassOf rdf:resource="#Frustrated"/>
</owl:Class> (05)
Cyc used to have attributes separate, and they formed a hierarchy (they also
form a hierarchy in SUMO), but Cyc changed (a major change) to the current
view. I was told that this was done because it led to fewer errors in
representation. It may also be more computationally efficient. But since I
am quite concerned about the ontology being as close as possible to language
(English, specifically) to make development of an NL interface easier, I
would prefer to have attributes represented as such, rather than as objects
with that attribute.
No problem. Both of these views can be translated into each other, and
are logically consistent, so they can be represented in the same consistent
ontology. The bridging axioms would be simple (here I use ESKIF, a variant
of SKIF where the curly brace inverts the order of the first two arguments): (06)
(<=>
{"P hasAttribute Angry}
{?P isanInstanceOf AngryPerson}) (07)
Where 'AngryPerson' would be the term used for the CYC element 'Angry'. (08)
There are other alternations, such as CYC using object-made-of-substance
instead of an alternative more abstract view of substance that conforms more
closely to linguistic intuition; these can also be translated directly. (09)
I feel that this is very important because my appreciation of the biggest
problem with the IEEE-SUO project was that alternative views were
*excluded*. No criticism implied, the Teknowledge group had a deadline to
meet. But the result was that too many potential users did not find their
preferred representations, and stayed with their own ontologies. If this
project is intended to include all alternative logically consistent views of
the same object, it may well have better success than IEEE-SUO, because in
that way everybody can have everything they want. Things should only be
excluded if they are logically inconsistent with the core content. And Cyc
is a bit bizarre in some respects, so this could be a critical principle
that makes the project feasible. (010)
[JFS] > > 7. If and when a good set of primitives has been found useful,
> a methodology based on them could be promoted for simplifying
> further ontology development. However, older theories that
> use the older terms would remain available as long as anyone
> needs them.
>
I see no problem identifying a "core" set of primitives but using a larger
base set ('core' plus 'mid-level extension') for most purposes. For an NLP
interface, I do not expect the primitives alone to provide a convenient set
of terms. (011)
[JFS] > > I would expect the FO to be completely open-ended so that the
> number of useful terms would increase indefinitely. There could
> also be a small subset of recommended defining terms. (I wouldn't
> even object to calling them "primitives".)
>
[PC] ;-) (012)
[JFS] > But we do have to recognize that many "primitives" may be very
> underspecified. For example, the term PointInTime should be neutral
> with respect to a 3D or 4D ontology. (013)
[PC] Agreed.
For me it would also be important that the intended meanings of the base
terms (primitive or otherwise) be described with sufficient detail -logical
or linguistic - so that they are used consistently by all *human* users,
whether they are very vague ("object") or very specific. The machines, of
course only know what the logical relations tell them, but when a database
designer creating a data entry form decides where in the ontology those data
are to be represented, it is his/her understanding of the meanings of the
ontology elements that determines where it goes. That is one reason why I
continue to emphasize the need for clear and (if necessary) comprehensive
documentation of each element. (014)
> . . . .
> DF> If the context referred to is what Cyc calls a DataMicrotheory,
> > then the statements added are qualitatively different from those
> > in the basic theory.
> >
> > A context might close T's open world assumption, such that T2 has
> > a closed world assumption. T and T2, in such a case, would be
> > different types of theory.
> [JFS] > That's a good point. It illustrates an important advantage of
> starting with OpenCyc (or some subset of it). We can take advantage
> of the 26 years of experience in developing Cyc. We don't have to
> adopt every one of their decisions, but when we diverge, we should
> have a good reason for doing so.
>
[PC] I have a qualm about CYC, and I am not sure how important it is. In
looking at CYC one sees many relations that are fairly specific to the
details of the way CYC is organized and does its reasoning. If it turns out
that some very system-specific element in CYC is logically contradictory to
something that an application developer wants, I would prefer that the CYC
element be relegated to an extension (micro)theory (CYC operations?). This
may not happen, but I think if we take everything in CYC as unchangeable,
that may create problems. Let's face it, CYC is weird. It may work fine
with all its parts in place, but to accommodate the publicly available
OpenCyc to the way other ontologists view the world could be an intractable
problem. But we can burn that bridge when we come to it ;-) (015)
[JFS] >
> The goal of getting a useful FO ASAP implies that we should start
> with a much larger set of terms than Pat has in mind. But that may
> be an advantage. The goal of extracting a smaller number of defining
> terms can be guided by usage patterns. Those terms that are most
> widely used would be prime candidates. The other terms could be
> redefined in terms of them.
>
[PC] Good point, and that also emphasizes one of the goals that I had in
mind as a main goal for the FO project - the creation of real useful
applications that use the ontology. (016)
The overall project John has suggested is, IMHO, potentially quite useful.
The biggest problem I anticipate is simply that it is very complex and
time-consuming, and in the absence of funding will move very slowly.
Perhaps we can envision a first stage proof of concept, but even that could
be too complex for voluntary work. One principle I thought would advance
collaborative work was to keep the working ontology as small as possible.
Using all of OpenCyc - even 20,000 terms - could boggle any potential
contributor before the project begins. But this is still worth exploring. (017)
Pat (018)
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx (019)
_________________________________________________________________
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 (020)
|