Patrick Cassidy <pat@xxxxxxxxx> wrote: (01)
> John,
> I tend to prefer action to talk, so your suggestion is certainly
> welcome.
> I do have a few questions:
> ...
> [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. (02)
[PC]> 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? (03)
OpenCyc 1.0 has around 60K classes (of which around 2000 are metaclasses).
It has around 15K predicates (about 4K of which are not binary) and 3600
functions. My copy has about 217K individuals (but i removed much in the
way of project-specific indiviuals (and classes)) so this is just a rough
estimate. (04)
I haven't looked at OpenCyc 2.0, but 1.0 could be a starting place. (05)
> [JFS] >
>> 3. But we would also welcome and encourage anybody with different
>> preferences to contribute more terms and theories to the FO. (06)
> Do you anticipate including alternative representations of the same
> entities, with translations? (07)
I would suggest mappings to terms in other ontologies. This is a major
purpose of the FO. (08)
I think the below critiques of Cyc should be considered. If we can
identify problematic areas, a quick pass could create the more generic
terms, and mappings to the Cyc terms would be different (or in a different
theory) in such cases. (09)
* attributes not necessarily as classes
+ theory A treats them as classes
+ theory B does not
* substance
+ theory C treats as object made of substance
+ theory D does not (010)
What else? (011)
> I will provide an example:
>
> In CYC, attributes are generally represented as object-with-attribute
> rather than as attributes per se. (012)
It might be useful to switch back. This conversion process seems to me
to have been faulty. Color is one attribute that seems quite problematic
to treat in this fashion. (013)
> For example the concept "angry" is a kind of person: (014)
More precisely, a kind of IntelligentAgent that can have an emotional
state. This prevents the attribute from being assigned to animals which
are not deemed intelligent -- event though anger is often attributed to
such animals. (015)
> <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> (016)
> 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. (017)
> 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):
>
> (<=>
> {"P hasAttribute Angry}
> {?P isanInstanceOf AngryPerson})
>
> Where 'AngryPerson' would be the term used for the CYC element 'Angry'. (018)
> 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. (019)
> 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. (020)
I agree. (021)
> [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. (022)
[PC]> 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.
>
> [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] ;-)
>
> [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.
>
> [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.
>
>> . . . .
>> 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. (023)
> [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 ;-)
>
> [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.
>
> 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. (024)
If a major point is to be able to map to any user ontology, we will need
more terms than that. (025)
-- doug (026)
> Pat
>
>
> Patrick Cassidy
> MICRA, Inc.
> 908-561-3416
> cell: 908-565-4053
> cassidy@xxxxxxxxx (027)
=============================================================
doug foxvog doug@xxxxxxxxxx http://ProgressiveAustin.org (028)
"I speak as an American to the leaders of my own nation. The great
initiative in this war is ours. The initiative to stop it must be ours."
- Dr. Martin Luther King Jr.
============================================================= (029)
_________________________________________________________________
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 (030)
|