opencog-dev team mailing list archive

["Trent Waddington" <trent.waddington@xxxxxxxxx>]

All this recent discussion of handles hasn't be sitting right with me
and I think I understand why.

What is a handle?  The most common form of handles that programmers
are familiar with is file handles.  A file handle is a kind of pointer
that the file system maintains for you.  Lots of things are going on
during a typical file manipulation action that the application program
really isn't interested in.  e.g., the blocks that make up the file
could be moved around physically on disk by the filesystem to optimize
space (or whatever) and, as far as the application is concerned, the
file is unaffected.  The handle is an abstraction mechanism.

It is well known that this is the power of a filesystem.  Abstracting
away the lower-level implementation and demanding that applications
work with files allows the filesystem to be flexibly implemented to
achieve the best performance or whatever other goals are desired.

The majority of algorithms currently implemented in OpenCog have an
intimate knowledge of the layout of Atoms in an AtomSpace.  The use of
handles is not at all similar to the filesystem concept.  There's no
abstraction going on.  If the representation of an Atom was to change,
we would expect the use of handles to be of little value in mediating
the maintenance of these algorithms.  I think Linas knows where I'm
coming from here.. his use of for_each patterns is an attempt to
encapsulate the layout of Atoms in an AtomSpace and abstract away the
interface.. but I think we need more.

Consider moving the Query algorithm out into a separate server.  The
primary operation of the Query algorithm is to walk the nodes and
links of an AtomSpace and do isomorphic tree matching.  One may be
tempted to implement this by replicating the entire AtomSpace from the
primary server to the Query server and keeping the two in sync.  I
believe this would be unnecessary as the Query algorithm is primarily
a local one.. it is interested in walking trees from a given root.
Instead, we could have an api which abstracts the Atoms in an
AtomSpace, giving us handles, which can be used in operations to the
server to walk the links between nodes, retrieve the data contained in
nodes and perform complex searches.

I suggest that such an API can be written to make communication with
the Atom Server completely transparent.. just as communication via
system calls to an operating system's kernel is completely transparent
to glibc users.

On the other hand, some algorithms belong in the Atom Server.  For
example, attention allocation.  Although the exact strategy of
attention allocation may not.

Having such an abstract API to the AtomSpace will permit the easy
binding of other programming languages.  For example, the Relex code
(written in Java) could be completely ignorant of the XML format used
to communicate to the server.  This will attract more contributors as
everyone has their preferred language to develop in.  It will also
have pragmatic benefits as each language has its own strengths that we
can leverage.

Trent