ontolog-forum
[Top] [All Lists]

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

To: "'[ontolog-forum] '" <ontolog-forum@xxxxxxxxxxxxxxxx>
From: "Patrick Cassidy" <pat@xxxxxxxxx>
Date: Wed, 17 Feb 2010 23:29:07 -0500
Message-id: <070801cab052$e8d6d280$ba847780$@com>
Mike,
  Good to hear from you.
[Mike Bergman] > 
> 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. :)
>    
  I searched and couldn't find a .owl file. Could you provide a direct
pointer?    (01)

Pat    (02)

Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx    (03)


> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of Mike Bergman
> Sent: Wednesday, February 17, 2010 9:44 PM
> To: [ontolog-forum]
> Subject: Re: [ontolog-forum] Foundation ontology, CYC, and Mapping
> 
> Hi Patrick,
> 
> 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?).
> 
> 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. :)
> 
> Though a bit dated, here is our view of UMBEL "in the middle" [1].
> 
> Mike
> 
> [1]
> http://www.mkbergman.com/441/the-role-of-umbel-stuck-in-the-middle-
> with-you/
> ; also http://www.mkbergman.com/category/umbel/
> 
> >
> > [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
> >
> 
> 
> 
> _________________________________________________________________
> 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
>     (04)


_________________________________________________________________
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    (05)

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