Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

Re: SUO: RE: Foundations for ontology





I would like to add my support for a separate track to develop a White
Paper that would lay out foundational and other specifications appropriate
to or required of a reference ontology.  Such a background document could
be annexed to any reference object submitted to ANSI for ultimate
acceptance as a standard.  I fear that without this preliminary work we
shall have a series of products rather than a standard. 

I believe Matthew West has twice referred us to an anologous effort,
where a White paper and a reference object were developed concurrently.
Now that we may have as many as 5-6 candidate documents, this seems
increasingly necessary.  

The White Paper could be a reasoned list of specification categories, or
it could attempt also a more general survey of existing/best practices in
the field. This would depend on the resources available.  

Lee

Josiah Lee Auspitz
lee@textwise.com
17 Chapel Street
Somerville, MA 02144
617-628-6228
fax    -9441

Please send attachments pasted within text or in ASCII
Plain Text non-proprietary software.

On Mon, 13 Aug 2001 John.Velman@HSC.com wrote:

> 
> 
> I haven't had time yet to do more than glance at John's slides.
> Maybe they contain elements of ``a way ahead'' that we can use.
> I do believe that we need a defined process and some principles.
> 
> This latter statement is certainly vague, but rather than wait
> till I have time to sharpen it, I thought I'd at least raise my
> voice in favor of defining how we are going to get where we are
> going (and how we will know when we get there).
> 
> John V.
> 
> 
> 
> 
> "Horn, Graham" <graham.horn@aihw.gov.au>@majordomo.ieee.org on 08/12/2001
> 09:18:01 PM
> 
> Please respond to "Horn, Graham" <graham.horn@aihw.gov.au>
> 
> Sent by:  owner-standard-upper-ontology@majordomo.ieee.org
> 
> 
> To:    "'John F. Sowa'" <sowa@bestweb.net>,
>        standard-upper-ontology@ieee.org, cg@cs.uah.edu
> cc:    phayes@ai.uwf.edu
> 
> Subject:  SUO: RE: Foundations for ontology
> 
> 
> 
> John,
>      .    I wish I could spend time digesting the work you have done.
> It is evidently significant and perspicacious.
> 
>      .    Might I suggest you put a motion to the SUO group (or a
> modification to an existing one) for us to consider.
> 
>      .    I suspect you are bringing issues to the forum that
> transcend the considerations most of us have made to date.
> 
>      .    I believe we would be well served by considering our way
> ahead in terms of the issues you have raised, as well as considering your
> recommendations.
> 
>      .    What do others think?
> 
> 
> 
> Cheers                   Graham Horn
> National Data Standards Unit
> Australian Institute of Health and Welfare
> ================================================
> Phone:         02.6244.1094
> Fax:           02.6244.1199
> E­mail:        Graham.Horn@aihw.gov.au <mailto:graham.horn@aihw.gov.au>
> 
> 
> -----Original Message-----
> From:     John F. Sowa [mailto:sowa@bestweb.net]
> Sent:     Monday, 13 August 2001 13:42
> To:  standard-upper-ontology@ieee.org; cg@cs.uah.edu
> Cc:  phayes@ai.uwf.edu
> Subject:  SUO: Foundations for ontology
> 
> 
> As I have said in many notes to SUO list, I have some concerns about any
> ontology that is developed by hand.  In two recent talks, I presented my
> views of how ontologies should be developed.  The first talk, which I
> presented at ICCS on August 3, surveys the philosophical foundations.
> Following are the slides:
> 
>    http://www.jfsowa.com/pubs/signtalk.htm
> 
> The second talk, which I presented at an IJCAI workshop on knowledge
> discovery on August 6, suggests automated or semiautomated methods of
> aiding
> in ontology development.  Following are the slides for that talk:
> 
>    http://www.jfsowa.com/pubs/autotalk.htm
> 
> I had originally intended to make this one talk, but as it kept getting
> longer, I split it in two.  There will also be a paper, which I'll announce
> later (when it is finished).
> 
> At IJCAI, I also attended a talk by Stuart Shapiro.  The paper for that
> talk
> included some comments about Cyc, which are very relevant to ontology
> development by hand.  The problems with keeping Cyc consistent indicate why
> I believe that more autotmated and semiautomated tools are essential for
> ontology development. I scanned the paragraphs about Cyc from the paper and
> included them at the end of this note.
> 
> As I said at the SUO workshop at IJCAI, I believe that something along the
> lines that Robert Kent has been proposing for IFF is a necessary component
> of any ontology project.  I would prefer to see SUMO split up into multiple
> smaller theories that could be combined by belief revision methods.
> 
> John Sowa
> ________________________________________________________________________
> 
> 
>                       Some Observations about Cyc
> 
> [The following comments on Cyc have been extracted from a paper that was
> presented by Stuart Shapiro at an IJCAI Workshop (citation below). The
> evaluation of Cyc is based on Cycorp documentation and on experience by the
> first author (Frances Johnson) during a Cyc training course.]
> 
> Doug Lenat and Cycorp have developed Cyc [Cycorp, 200la] -- a large
> knowledge base and inferencing system that is built upon a core of over a
> million hand-entered assertions or rules about the world and how it works.
> This system attempts to perform commonsense reasoning with the help of this
> large corpus of beliefs (mostly default with some that are monotonic).  It
> divides its knowledge base into smaller contexts called micro­theories
> which
> contain specialized information regarding specific areas (such as troop
> movement, physics, movies, etc.).  Belief revision is performed within
> micro­theories or within a small group of micro­theories that are working
> together, and the system is only concerned with maintaining consistency
> within that small group (as opposed to across the entire belief space).
> For
> example:  in an everyday context, a table is solid, but within a physics
> context, it is mostly space  (between atoms).
> 
> A belief can have only one truth value, so no microtheory can contain both
> p
> and ~p.  For example, ~p could be expressed as the proposition p with a
> truth value of false.  The technique for maintaining consistency is to
> check
> for contradictory arguments whenever a proposition is derived or asserted
> into a microtheory.  When contradictions are found, their arguments are
> analyzed, and a decision is made regarding the truth value of the
> propositions involved.  Rankings of beliefs, however, is not a part of the
> system -- it uses specificity to determine the truth value of a default
> belief.  For example:  Opus the penguin does not fly, even though he is a
> bird, because penguins don't fly.  If there can be no decision based on
> specificity, the truth value of the default belief is unknown.  A default
> belief loses out to a monotonic one.  And, lastly, according to Cyc
> trainers
> and other contacts, contradictions that are purely monotonic bring the
> system to a halt until they are fixed.  During Cyc training, Johnson
> attempted to prove this last statement and failed -- revision was
> performed.
> The instructors were surprised, but thought the training interface might be
> the cause.  We plan to explore this further, but it is an example of a
> system behaving differently than it is described.
> 
> As mentioned [above], Cyc did not perform as described, and there must be
> some question as to other possible differences from design theory. Most
> specifically, Cyc literature [Cycorp, 2001b] claims to keep the
> micro­theories consistent, for lack of a better word.  When asked, contacts
> agreed that, in spite of a cursory check, it was possible that unknown
> contradictions might exist that had not, yet, been derived.  In this sense,
> Cyc can only guarantee that its microtheories are not known to be
> inconsistent (or KS-consistent).  Ideal terminology, such as consistent and
> derivable, is often not appropriate for use with a large or complex
> implemented system.
> 
> References
> 
> Cycorp [2001a] _Cycorp, Creators of the Cyc Knowledge Base_,
> http://cyc.com
> 
> Cycorp [2001b] _Features of CycL_, http://cyc.com/cycl.html
> 
> The original article from which these paragraphs were extracted:
> 
> Frances L. Johnson and Stuart C. Shapiro, "Redefining belief change
> terminology for implemented systems," _Inconsistency in Data and
> Knowledge_,
> Working Notes from IJCAI'01, Seattle, Washington, 6 August 2001, pp. 11-21
> 
> 
> 
>