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)
[1]
http://www.mkbergman.com/441/the-role-of-umbel-stuck-in-the-middle-with-you/
; 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)
|