Pluggable AtomSpace Indexes

From OpenCog
Jump to: navigation, search

Note from Joel: I really have to read about the current use of indexes in the AtomTable code further. These are just my thoughts about

Index Definitions

Currently thinking of a description class that can be passed to the planned Repository createIndex:

class IndexDefinition {
public
   typedef enum {
       HandleKey, NameKey, TypeKey, OutgoingKey,
       IncomingKey, STI, LTI, } IndexKey;

   typedef std::vector< boost::variant <
       Handle, const char *, Type, HandleSet,
       AttentionValue::sti_t, AttentionValue::lti_t > > IndexBinding;

   IndexDefinition (IndexKey index
                    std::map<IndexKey,IndexBinding> binds)
   IndexDefinition (std::vector<IndexKey> indexes
                    std::map<IndexKey,IndexBinding> binds)
   std::map<IndexKey,IndexBinding> binds;
   std::map<IndexKey,IndexBinding> indexes;
}

What's the point of this?

When we create an index, it can be either as part of the in-memory AtomTable or as an index in the Repository. Having a common definition between them could make it much easier to say something like: "I want an index by name in both the AtomTable and for the Repository":

std::map<IndexKey,IndexBinding> dummyBind; // No limitations to scope of index
IndexDefinition indexDef(NameKey, dummyBind);
repository.createIndex(indexDef); // Factory methods: these would create
atomTable.createIndex(indexDef);  // Index objects appropriate for key

This example is perhaps not that useful, but you could similarly make an index of PredicateNodes and GroundedPredicateNode (TypeKey: [PredicateNode, GroundedPredicateNode]) and base the index on their OutgoingSet.

Couldn't this be better?

Probably, it'd be nice to make arbitrary patterns limit the index with variables for the part that would be indexed. I.e.

Indexing the results of whether things are blue:

EvaluationLink
   PredicateNode "is_blue"
   X
   Y

This would index on the argument X to "is_blue" allowing us to quickly get the result Y.

Perhaps this could be achieved by adding a PatternKey value to the IndexKey enum - then the relevent item in the IndexBinding vector would be a Handle pointing to the BindLink of the pattern. Perhaps this could use Linas' PatternMatch code to find matching atoms at the start and filter additions/removals.