[Top] [All Lists]

Re: [ontolog-forum] Foundation ontology, CYC, and Mapping

To: "[ontolog-forum]" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: Mike Bergman <mike@xxxxxxxxxxxxx>
Date: Wed, 17 Feb 2010 20:44:23 -0600
Message-id: <4B7CA987.5060700@xxxxxxxxxxxxx>
Hi Patrick,    (01)

On 2/17/2010 8:09 PM, Patrick Cassidy wrote:
> John,
>     I tend to prefer action to talk, so your suggestion is certainly welcome.
> I do have a few questions:
> [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.
> [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?).    (02)

N3 is merely a serialization, which we also have in other formats 
(e.g., RDF/XML). The current UMBEL version is in OWL Full; the 
next version (hopefully coming out *very* soon, will be in OWL 2 
DL). BTW, we and the Cycorp folks have been watching this 
discussion with some interest. :)    (03)

Though a bit dated, here is our view of UMBEL "in the middle" [1].    (04)

Mike    (05)

; also http://www.mkbergman.com/category/umbel/    (06)

> [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:
> 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>
> 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):
> (<=>
>    {"P hasAttribute Angry}
>    {?P isanInstanceOf AngryPerson})
> Where 'AngryPerson' would be the term used for the CYC element 'Angry'.
> 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.
> 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.
> [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.
> [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.
> [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.
> Pat
> Patrick Cassidy
> MICRA, Inc.
> 908-561-3416
> cell: 908-565-4053
> cassidy@xxxxxxxxx
>    (07)

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    (08)

<Prev in Thread] Current Thread [Next in Thread>