Arrrrgh, switching to lunr-mutable-indexes (https://github.com/hoelzro/lunr-mutable-indexes) because lunr 2.x index is immutable. ;D
The lunr guy takes decisions, like... he knows what's good better than the library users do.
Back to work.
I need to think out loud now. Say, we're in the middle of a cycle. We just got a search running, and we have results like this JSON:
[
{
id: 'module1.f5',
relation: 'EvaluationLink beautiful $X',
score: 1.5308861812688752
},
{
id: 'test.module2.f5',
relation: 'EvaluationLink beautiful $X',
score: 1.5308861812688752
},
{
id: 'module1.f3',
relation: 'EvaluationLink boring $X',
score: 0.45325544674057694
},
{
id: 'module1.f4',
relation: 'EvaluationLink young $X',
score: 0.45325544674057694
},
{
id: 'test.module2.f3',
relation: 'EvaluationLink boring $X',
score: 0.45325544674057694
},
{
id: 'test.module2.f4',
relation: 'EvaluationLink young $X',
score: 0.45325544674057694
}
]
We have the scores and the relations. Now we want to know what to do next. The obvious idea is: pattern-match it to find the relevant piece of code you're gonna execute in front of this. But we don't want over-complicated pattern definition.
Seneca uses key-value patterns, like "role:math,cmd:sum". Here, we have lists, but these lists are ordered, which means they're like key-value pairs with keys being "first item, second item, ...".
A list like "ImplicationLink f2 f3" can be translated to
{
"type": "ImplicationLink",
"rest": "f2 f3",
"i1": "f2",
"i2": "f3"
}
which Seneca can handle. the "rest" key is here to reward "full hits" more than just the sum of partial matches.
That's a simple solution. However, maybe it lacks flexibility.
And it doesn't take multiple input into account anyway, with scores and all.
There's the other solution. If relations have fixed arity, for example, AndLink always have 2 arguments, then we can rewrite the search results as a list of trees, replacing ids by the relations they identify.
f1: ImplicationLink f2 f3
f2: AndLink f4 f5
f3: is $X boring
f4: is $X beautiful
f5: is $X young
gets resumed as ImplicationLink AndLink is $X beautiful is $X young is $X boring
We obtain prefix-notation code, which can be run through... a chatbot! Yep, again.
Maybe mixing the 2 solutions can bring out interesting possibilities. Chatbots are good at replying, so they could provide the next search query. And Seneca could provide local execution of thought.
Or... we can remove ambiguity by using opening/closing tags, like
ImplicationLink AndLink Is $X beautiful EndIs Is $X young EndIs EndAndLink Is $X boring EndIs EndImplicationLink
All candy.
Listening to this: https://www.radio.fr/s/synthwaveretrowave (https://www.radio.fr/s/synthwaveretrowave)
Also, switching back to lunr, because mutable-lunr just rebuilds the index every now and then, which I can do by myself (and... lunr is beautiful while mutable-lunr is ugly). Rivescript brains would need to be rebuilt too, when the system learns something.
Learning is sooo overrated in AI world...
I do have my "overview function" now.
function overview(results) {
var ref = {};
results.forEach(result => { ref[result.id] = result; });
results.forEach(result => {
var takenTokens = [];
var tokenCount = -1;
result.expandedScore = result.score;
while (tokenCount != takenTokens.length) {
tokenCount = takenTokens.length;
result.relation = result.relation.split(' ');
result.expandedRelation = result.relation.map(token => {
if (ref[token]) {
if (!takenTokens.includes(token)) {
takenTokens.push(token);
result.expandedScore += ref[token].score;
}
return ref[token].relation;
}
else
return token;
}).join(' ');
result.relation = result.expandedRelation;
}
});
return results;
}