Description
SetLink
has a number of technical issues with respect to the core concept of atoms and how atoms should be used. Basically, SetLink is a bad citizen. The only answer I can find is to simply excommunicate, banish SetLink from the Kingdom. The correct solution is to use MemberLink
instead. (See however, other ideas below.)
Unfortunately, BindLink
and GetLink
, when executed, return SetLink
's containing the search results. This needs to be replaced by MemberLink
, and specifically, I think the following form might work best:
MemberLink
SomeSearchResultAtom
AnchorNode "pattern-9a30bd4cbdcd6"
and then have cog-execute!
return the AnchorNode
-- all search results can then be found, attached to this anchor.
Q: Why is SetLink bad?
A: See the wiki page for it. https://wiki.opencog.org/w/SetLink
Q: Why AnchorNode?
A: It seems like the best kind of node for this job.
Q: What other benefits (besides avoiding SetLink)?
A1: Search results can be reported incrementally, as the search proceeds, instead of waiting for one big glob to appear at the end.
A2: The SetLinks that get returned glom up the atomspace, and people usually forget to delete them. They are hard to delete - you have to actually have them in your hand to delete them - searching for them later on is really hard or impossible. By contrast, finding and deleting the AnchoreNodes is easy, and can be done at any time.
A3: Its a baby-step to converting the AtomSpace itself to a special kind of MemberLink and/or ContextLink. Having to pass the AtomSpace around in various methods is a real pain, and causes a lot of programming issues. It would be nice to just get rid of the atomspace entirely, and instead declare membership as:
AtomSpaceLink
AtomSpaceNode "primary atomspace"
SomeAtom
This or something like this could solve a lot of technical problems, and nuking SetLink
is a natural first step.
I believe that this will simplify creating a distributed atomspace. We could layer everything on top of (for example Redis or Riak and have that do all the work of distributing atoms. I don't believe this any longer. The StorageNode
is a superior solution for distributed atomspaces.
A4: If we do the above or something like it, we could merge MapLink/BindLink, since they both do almost the same thing, just that MapLink does it for its arguments, while BindLink does it for the entire atomspace. Similarly GetLink/FilterLink...
Q: Is this a lot of work?
A: You bet. BindLinks are used all over the place.
Activity