Mike,
Thanks for the pointer.
Yes, I know that Protégé 4 (didn't try other versions) can read an N3
file, and can then save it in the OWL-XML format. That would be a
conversion of a sort. But the order of the terms gets scrambled that way.
I was just curious if there were actually an XML-format file available, as
it seemed as though you were suggesting that. I am used to the XML format
and find it easy enough to read. N3 works too, as you say. (01)
I did look at the Umbel topic file in Protégé. It's not the sort of
perspicuous hierarchical ontology I am accustomed to viewing. Is there an
open-source publicly available program that uses it? (02)
Pat (03)
Patrick Cassidy
MICRA, Inc.
908-561-3416
cell: 908-565-4053
cassidy@xxxxxxxxx (04)
> -----Original Message-----
> From: ontolog-forum-bounces@xxxxxxxxxxxxxxxx [mailto:ontolog-forum-
> bounces@xxxxxxxxxxxxxxxx] On Behalf Of Mike Bergman
> Sent: Thursday, February 18, 2010 9:54 AM
> To: ontolog-forum@xxxxxxxxxxxxxxxx
> Subject: Re: [ontolog-forum] Foundation ontology, CYC, and Mapping
>
> Hi Patrick,
>
> 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?
>
> *.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.
>
> 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.
>
> 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:
>
> -- 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:
>
> N3 -> owl
> ---------
> cwm -n3 xxx.n3 -rdf > xxx.owl
>
> owl/rdf -> N3
> -------------
> cwm -n3 xxx.owl > xxx.n3
>
> (Note the owl reference above is to the XML serialization
> with an *.owl extension).
>
> 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.
>
> As for UMBEL, you should check out the documentation page [4],
> with specific attention to the technical documentation [5].
>
> Thanks, Mike
>
> [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
>
> >
> > 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
> >>>
> >>
> >>
> >>
> >> _________________________________________________________________
>
>
> _________________________________________________________________
> 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)
_________________________________________________________________
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 (06)
|