-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why not DualLink ? #30
Comments
Unification is required because targets or sources can be patterns themselves not just grounded atoms. I'm closing as I don't think DualLink can be used here, and we already have a unification tool for that. |
Reopening, because the questions were not answered. This is not a request-for-code-changes, or a suggestion that the unification code be discarded. Rather, its a request-for-post-mortem: what made DualLink unusable for chaining? A subtext for this is "how do we design a general-purpose chainer?" because I still have the impression that the URE is not it (and yes, I have a glimmer of why DualLink is not it, either, but it is a glimmer, and not a full understanding). The meta-issue is that I've started writing yet-another-chainer, here: https://github.com/opencog/generate precisely because I don't believe that the URE can solve the problem that I actually have, and I don't believe that the URE can be fixed, either. Maybe I am wrong; maybe I can use the URE for this, maybe it can be fixed. Just right now, I just do not see how. These are important theoretical questions. As long as we are all confused about them, forward progress is hard or impossible. This is a request-for-clarification. What went wrong, what is going wrong, why did the patient die on the table? |
Merge opencog -> singnet
So .. DualLink is a link type that can be used to search through a collection of rules, to see which rules might be applied in some given situation. Thus, if you have some large number of rules, (say, tens of thousands, like the chatbots) the DualLink will narrow this set down to the half-dozen which can actually be run "right now". Then, some other algo decides which of the half-dozen could, should be applied.
DualLink was designed with the intention that it can provide the backbone for forward-chaining or backward-chaining, by finding which premises can be attached to which outputs. Yet, a quick grep through the URE codebase shows that the URE does not use DuaLink.
So the question is .. why? Did DualLink simply not work well enough? Did it have the wrong form or style? Was it buggy? Was it too hard to use? Clearly, the URE has some other way of discovering chains ...
Since presumably the DualLink is not good enough for chain discovery, maybe there is some variation on it that would work better?
The text was updated successfully, but these errors were encountered: