On Tue, Jul 28, 2020 at 11:41 PM Ben Goertzel <b...@goertzel.org> wrote:
>
>
> Hmm... you are right that OpenCog hypergraphs have natural chunks
> defined by recursive incoming sets. However, I think these chunks
> are going to be too small, in most real-life Atomspaces, to serve the
> purpose of chunking for a distributed Atomspace
>
> I.e. it is true that in most cases the recursive incoming set of an
> Atom should all be in the same chunk. But I think we will probably
> need to deal with chunks that are larger than the recursive incoming
> set of a single Atom, in very many cases.
>
I like the abstract to the Ja-be-ja paper, will read and ponder. It sounds
exciting.
But ... the properties of a chunk depends on what you want to do with it.
For example: if some peer wants to declare a list of everything it holds,
then clearly, creating a list of all of its atoms is self-defeating. But if
some user wants some specific chunk, well, how does the user ask for that?
How does the user know what to ask for? How does the user say "hey I want
that chunk which has these contents"? Should the user say "deliver to me
all chunks that contain Atom X"? If the user says this, then how does the
peer/server know if it has any checks with Atom X in it? Does the
peer/server keep a giant index of all atoms it has, and what chunks they
are in? Is every peer/server obliged to waste some CPU cycles to figure out
if it's holding Atom X? This gets yucky, fast.
This is where QueryLinks are marvelous: the Query clearly states "this is
what I want" and the query is just a single Atom, and it can be given an
unambiguous, locally-computable (easily-computable; we already do this)
80-bit or a 128-bit (or bigger) hash and that hash can be blasted out to
the network (I'm thinking Kademlia, again) in a compact way - its not a lot
of bytes. The request for the "query chunk" is completely unambiguous, and
the user does not have to make any guesses whatsoever about what may be
contained in that chunk. Whatever is in there, is in there. This solves
the naming problem above.
> What happens when the results for that (new) BindLink query are spread
> among multiple peers on the network in some complex way?
>
I'm going to avoid this question for now, because "it depends" and "not
sure" and "I have some ideas".
My gut impulse is that the problem splits into two parts: first, find the
peers that you want to work with, second, figure out how to work with those
peers.
The first part needs to be fairly static, where a peer can advertise "hey
this is the kind of data I hold, this is the kind of work I'm willing to
perform." Once a group of peers is located, many of the scaling issues go
away: groups of peers tend to be small. If they are not, you organize them
hierarchically, they way you might organize people, with specialists for
certain tasks.
I think it's a mistake to try to think of a distributed atomspace as one
super-giant, universe-filling uniform, undifferentiated blob of storage. I
think we'll run into all sorts of conceptual difficulties and design
problems if you try to do that. If nothing else, it starts smelling like
quorum-sensing in bacteria. Which is not an efficient way to communicate.
You don't want broadcast messages going out to the whole universe. Think
instead of atomspaces connecting to one-another like dendrites and axons: a
limited number, a small number of connections between atomspaces, but
point-to-point, sharing only the data that is relevant for that particular
peer-group.
-- Linas
--
Verbogeny is one of the pleasurettes of a creatific thinkerizer.
--Peter da Silva
--
You received this message because you are subscribed to the Google Groups
"opencog" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to opencog+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/opencog/CAHrUA35zN4aaSrZ2Dpu4qLUL1bYfjAF_rGiS_xxg2-E-SBqY3Q%40mail.gmail.com.
