[Top] [All Lists]

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

To: ontolog-forum@xxxxxxxxxxxxxxxx
From: Mike Bergman <mike@xxxxxxxxxxxxx>
Date: Thu, 18 Feb 2010 08:53:37 -0600
Message-id: <4B7D5471.6010201@xxxxxxxxxxxxx>
Hi Patrick,    (01)

On 2/17/2010 10:29 PM, Patrick Cassidy wrote:
> 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?    (02)

*.owl files are merely OWL-compliant XML files with the *.owl 
extension (*.rdf works the same way). I think in the early days 
of OWL this approach was more common than it is today.  As long 
as the file is OWL language-compliant, you could use *.xyz as an 
extension for a OWL file, and no common tool (to our knowledge) 
would complain.    (03)

We use N3 [1] because it is easier to read. Nearly all tools 
ingest N3 that we use in our work: Protégé, *any* triple store 
(e.g., Virtuoso), ARC2, IsaViz, etc.    (04)

However, if for some reason you prefer RDF/XML as the 
serialization (and you want to give it a *.owl or *.rdf or 
*.cosmo extension or whatever), I can suggest two alternatives 
that can convert N3:    (05)

-- You can use the fine online service from Joshua Tauberer at 
RDFabout [2]
-- You can install CWM [3], and use these command lines for 
converting back and forth:    (06)

    N3 -> owl
    cwm -n3 xxx.n3 -rdf > xxx.owl    (07)

    owl/rdf -> N3
    cwm -n3 xxx.owl > xxx.n3    (08)

    (Note the owl reference above is to the XML serialization 
with an *.owl extension).    (09)

But these conversions should be unnecessary. In short, we know of 
no limitations to express any dialect of OWL in N3, and most 
modern tools will ingest the N3 serialization quite readily.    (010)

As for UMBEL, you should check out the documentation page [4], 
with specific attention to the technical documentation [5].    (011)

Thanks, Mike    (012)

[1] http://www.w3.org/DesignIssues/Notation3.html
[2] http://www.rdfabout.com/demo/validator/
[3] http://www.w3.org/2000/10/swap/doc/cwm
[4] http://umbel.org/documentation.html
[5] http://umbel.org/technical_documentation.html    (013)

> Pat
> Patrick Cassidy
> MICRA, Inc.
> 908-561-3416
> cell: 908-565-4053
> cassidy@xxxxxxxxx
>> -----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
>> _________________________________________________________________    (014)

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

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