Skip to content

Stop using SetLink for search results! #1502

Closed
@linas

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions