[om-list] Re: Cyc example

[Mark Butler]

Hello everybody,

Has anyone taken a look at the Cyc KM yet?  It is a very good example of the
field in general, and of what we would be doing once we get to actually
building a unified knowledge model, rather than just the software to use it
with.

The Cyc KM is commercial and proprietary - I suggest that we build an "open
data" KM under an LGPL style license and develop some sort of collaborative
mechanism to accept contributions from other knowledge codifiers in much the
same way that Apache is developed.  I think we are likely to get more help
building a unified knowledge model than help in the development of the
software to process it with.

Naturally, we need to be very careful not to let the taxonomy of Cyc or any
other proprietary KM directly influence what we do in an open source / open
data KM.

One issue that Cyc demonstrates quite well is the utility of having a rigorous
global namespace for all of your classes and relationships.  Single namespaces
have scalability problems, so I suggest we adopt hierarchical namespaces much
like they have in C++.  We could have a standard core namespace with English
derived names for things, and independent namespaces for different subject
areas.

The big advantage of namespaces is that they allow a human readable/writable
representation of various components of the KM to be constructed.  I think
LISP, though easy to process and construct programmatically, is much too hard
to read (XML is even worse).  What I would like to do is construct a more
natural looking syntax similar to Prolog, but probably closer to the
declarative portion of Epic, a programming language design I have been
thinking about for several years.

Then we could have two primary methods of KM construction:  Source code and
graphical input. Any KM could either be edited graphically in a tool similar
to a good data modeller or exported to source and worked on in a text editor.

By the way, OneModel is a better name for the single unified model of
knowledge than for the open source software we construct.  The reason for this
is that presumably others will want to construct internal / proprietary
knowledge models in our format, and it is a mouthful to call them OneModel
models.

- Mark

-- 
Mark Butler	       ( butlerm at middle.net )
Software Engineer  
Epic Systems              
(801)-451-4583