NARS and OCP
Pei Wang
> in attempting to translate opencog.org's OpenCogPrime (OCP) from C++ to
> Java, i wondered if NARS could fit into the design. OCP uses a hypergraph
> data structure significantly, which seems sufficient for containing, among
> other things, NARS memory.
>
> http://launchpad.net/jcog
The relation between NARS and OCP (or Novamente, or PLN) is a
complicated one, and the key issues are more in the conceptual level,
not implementation level. I've commented in this topic several times,
such as http://www.mail-archive.com/a...@v2.listbox.com/msg02021.html ,
while Ben's point of view can be found in the book on PLN, as well as
in his posts.
As far as memory goes, Ben said OCP can include NARS as a module,
though I haven't checked the details.
> NARS module code:
>
> http://bazaar.launchpad.net/%7Eseh999/jcog/proto2/files/head%3A/cog.nars/org/opencog/
>
> i remember that someone had suggested or asked about merging OCP and NARS
> code-bases before. it would seem there are several points of
> incompatibility.
Yes, this possibility has been raised by the OCP side several times,
though haven't been carried out yet, though the PLN book contains some
comparison between the two systems, mostly in truth-value functions.
> one, for example, is the different meaning of OCP atom and NARS sentence's
> different kinds of "truth" values. so in this prototype JCog design, each
> atom can associate an arbitrary set of these kinds of tags, so that OCP,
> NARS, and other systems can potentially act upon and within the same data.
> these are differentiated as OCPAttention, OCPTruth, and NARSTruth, and are
> accessible through basic Atom.get(class) and Atom.set(class, value) methods.
Technically, it can be done, but given the difference between the
semantics of these two systems, I don't see the point of it --- if the
two systems interpret the same data differently, it will lead to
invalid result; if each of the two only works on its own data, then
why to merge them?
> i'm wondering, what other incompatibilities might be resolvable or
> transcended?
(1) The semantics: the two systems define "meaning" and "truth-value"
differently.
(2) Language: the two systems use different internal representation,
and there is no accurate one-to-one mapping between the sentences.
(3) Inference rules: because of (1) and (2), the two use different rules.
(4) Modules: NARS only uses inference, while OCP depends on other ways
to process information.
(5) Memory: the two systems have quite different memory structures.
(6) Control: the two have different control mechanism and strategy.
Sorry for being brief, but it may take several papers to fully compare
these two systems.
> so, i imported the current NARS code into JCog and began making
> modifications according to the refactoring and GUI suggestions in my
> previous e-mail.
I don't mind you to give it a try, but you may want to be familiar
with the previous discussions on this topic (Google the web). Also,
please keep in mind that the difference is mostly conceptual, not
implementational.
> refactoring the Memory, NARS, Parameters, and Center classes into "interface
> NAR" (instances of which would be "Non-Axiomatic Reasoners" with
> self-contained memory and executive control).
> removing all "static" references, so that a system can instantiate multiple
> reasoners rather than being restricted to one singleton. this is also
> necessary for a proper unit testing framework, or to compare multiple
> simultaneously running NAR's. this interestingly also might make it
> possible for a NAR memory to contain sub-NAR's within itself, recursively.
> making GUIs that would control, view, and edit OCP and NARS features. there
> are several GUI widgets that would serve both systems, for example, browsing
> a list containing both OCP atoms and NARS concepts.
Sounds fine.
> i thought it would be a good idea to ask for ideas or suggestions at this
> point. the NARS code commited in JCog is not presently functional - much
> work remains. though these initial refactorings are probably enough to
> motivate further architectural developments.
Keep us informed.
> maybe this could be facilitated by refactoring the Memory, NARS, Parameters,
> and Center classes into:
>
> interface NAR - "non-axiomatic reasoner", a specific instance of a NARS
> implementation, with self-contained memory and executive control
> specific implementations of "NAR" would utilize specific memory and
> inference components, through a common access interface accessed by a
> separate GUI layer
Sounds fine, but again, the key issues are not in this picture.
For example, OCP uses different memory and mechanism for declarative,
episodic, and procedural knowledge, while NARS handles them all
together (concretely, NAL1-6 is on declarative knowledge, NAL7 extends
the logic to episodic knowledge, and NAL8 to procedural knowledge).
When NARS is merged into OCP, which approach should be applied?
Pei