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