Re: SUO Scope and Purpose: Call for discussions
Frank,
Moving KIF from the status of proposed draft to official standard sounds
like a good idea. I'd suggest that PAR #2 need not be a full fledged
discussion group as that functionality could be met by use of
McCarthy-style context mechanism. That mechanism could be specified as
part of an extension to the semantics of KIF. Item #3 I'd suggest has
little to do with the SUO. Different access protocols could be defined for
the SUO and not have any effect on its content or structure. OKBC already
exists as a model for frame-based ontologies. The Cyc interface is a
reasonable model for a logic-based interface. Item #3 might be effectively
addressed as part of an entirely separate effort to move OKBC through a
standardization process. Simply having the methods ask() and tell() would
be a sufficient interface for the SUO.
For items #2 and #3 I'd suggest that they might distract from the
original focus of the SUO on semantic content, and therefore should be part
of a different effort.
Adam
At 11:59 PM 7/6/2000 -0400, Frank Farance wrote:
>At 18:07 2000-06-20 -0400, you wrote:
> >
> > SUO,
> > Below is an updated strawman Scope & Purpose for the proposed SUO
> > standard.
> > I would now like to call for focused discussions on the Scope (what
> > we are proposing to develop, including the technical boundaries) and the
> > Purpose (why this standard needs to be developed and who will benefit).
> > Please understand this version is just a strawman, so nothing is carved in
> > stone. This is an open process, so all are welcome to actively
> participate.
>
>I am supportive of the SUO Scope and Purpose that has been submitted. I
>would like to proposed three more PARs *in addition* to the SUO PAR listed.
>In summary, there are three additional PARs:
>
> 1. Finishing something KIF-like as a standard in whatever form is
>necessary. I'm not saying that KIF should be standardized as is ... I'm
>saying that we need a standard like KIF and KIF is a good starting point to
>complete the work.
>
> 2. Standard for managing "buckets" of knowledge. Whatever we
>consider knowledge representation, it should be possible to take "bucket" X
>and "bucket" Y and "pour" them into an empty "bucket" Z. There might be
>some type of reverse operation, if that is possible. This type of standard
>would involve describing certain types of operations, which could be bound
>in a variety of ways, such as APIs, programming language operators, queries,
>commands, and so on. It is not clear whether or not the binding is
>necessary for the standard.
>
> 3. Asking "questions" or "reflecting" on a "bucket" of knowledge.
>It will be useful to ask questions ("is X true?", "what information do you
>have on Y?") which might return responses "true", "false", or "unknown"; or
>it might return a pointer (to some bucket). Again, the form of the standard
>would be describing certain types of operations, which could be bound in a
>variety of ways (just like #2 above).
>
>I've included PAR wording below for each of these three topics.
>
>Regarding the PARs,
>
> - some people will want to participate in all activities (projects)
> - some people will want to participate is some activities
> - some people will want to participate in one activity
> - some people will want to participate in no activities
>
>Please send your comments for improving the PARs. I know that some of the
>terms are lay terms, but I believe this kind of lay wording will help IEEE
>NesCom (New Standards Committee) understand and approve the PARs (of course,
>the standard won't be in lay terms). Please note that the KIF Scope and
>Purpose wording were taken from the KIF document.
>
>-FF
>---------------------------------------------------------------
>Topic #1: Knowledge Interchange Format
>
>Scope:
>
>Knowledge Interchange Format (KIF) is a language designed for use in the
>interchange of knowledge among disparate computer systems (created by
>different programmers, at different times, in different languages, and so
>forth).
>
>KIF is not intended as a primary language for interaction with human users
>(though it can be used for this purpose). Different computer systems can
>interact with their users in whatever forms are most appropriate to their
>applications (for example Prolog, conceptual graphs, natural language, and
>so forth).
>
>KIF is also not intended as an internal representation for knowledge within
>computer systems or within closely related sets of computer systems (though
>the language can be used for this purpose as well). Typically, when a
>computer system reads a knowledge base in KIF, it converts the data into its
>own internal form (specialized pointer structures, arrays, etc.). All
>computation is done using these internal forms. When the computer system
>needs to communicate with another computer system, it maps its internal data
>structures into KIF.
>
>Purpose:
>
>The purpose of KIF is roughly analogous to that of Postscript. Postscript is
>commonly used by text and graphics formatting systems in communicating
>information about documents to printers. Although it is not as efficient as
>a specialized representation for documents and not as perspicuous as a
>specialized wysiwyg display, Postscript is a programmer-readable
>representation that facilitates the independent development of formatting
>programs and printers. While KIF is not as efficient as a specialized
>representation for knowledge nor as perspicuous as a specialized display
>(when printed in its list form), it too is a programmer-readable language
>and thereby facilitates the independent development of
>knowledge-manipulation programs.
>
>---------------------------------------------------------------
>Topic #2: Knowledge Pool Management Services
>
>Scope:
>
>To describe the functions, operations, and services of managing pools of
>knowledge. These services would support the basic management services, such
>as merging, splitting, tagging, and packaging of knowledge pools. A binding
>shall be provided to at least two programming environments to demonstrate
>language independence.
>
>Purpose:
>
>When knowledge is represented, it should be possible to take "bucket" X and
>"bucket" Y and "pour" them into an empty "bucket" Z. There might be some
>type of reverse operation, if that is possible. This type of standard would
>involve describing certain types of operations, which could be bound in a
>variety of ways, such as APIs, programming language operators, queries,
>commands, and so on.
>
>---------------------------------------------------------------
>Topic #3: Knowledge Pool Queries
>
>Scope:
>
>To describe the functions, operations, and services of querying pools of
>knowledge. These services would permit applications or systems to pose
>questions about certain pools of knowledge. These services would permit
>applications or systems to inquire "what knowledge is available?" for
>topics. A binding shall be provided to at least two programming
>environments to demonstrate language independence.
>
>Purpose:
>
>It will be useful to ask questions ("is X true?", "what information do you
>have on Y?") which might return responses "true", "false", or "unknown"; or
>it might return a pointer (to some "bucket"). This type of standard would
>involve describing certain types of operations, which could be bound in a
>variety of ways, such as APIs, programming language operators, queries,
>commands, and so on.
>
>---------------------------------------------------------------
>
>-----------------------------------------------------------------------
>Frank Farance, Farance Inc. T: +1 212 486 4700 F: +1 212 759 1605
>mailto:frank@farance.com http://farance.com
>Standards, products, services for the Global Information Infrastructure
-----------------
Adam Pease
Teknowledge
(650) 424-0500 x571