{"action":"created","issue":{"url":"https://api.github.com/repos/opencog/opencog/issues/1742","labels_url":"https://api.github.com/repos/opencog/opencog/issues/1742/labels{/name}","comments_url":"https://api.github.com/repos/opencog/opencog/issues/1742/comments","events_url":"https://api.github.com/repos/opencog/opencog/issues/1742/events","html_url":"https://github.com/opencog/opencog/issues/1742","id":103290882,"number":1742,"title":"Loading VariableNodes from backing store ","user":{"login":"bgoertzel","id":5907804,"avatar_url":"https://avatars.githubusercontent.com/u/5907804?v=3","gravatar_id":"","url":"https://api.github.com/users/bgoertzel","html_url":"https://github.com/bgoertzel","followers_url":"https://api.github.com/users/bgoertzel/followers","following_url":"https://api.github.com/users/bgoertzel/following{/other_user}","gists_url":"https://api.github.com/users/bgoertzel/gists{/gist_id}","starred_url":"https://api.github.com/users/bgoertzel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bgoertzel/subscriptions","organizations_url":"https://api.github.com/users/bgoertzel/orgs","repos_url":"https://api.github.com/users/bgoertzel/repos","events_url":"https://api.github.com/users/bgoertzel/events{/privacy}","received_events_url":"https://api.github.com/users/bgoertzel/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":5,"created_at":"2015-08-26T15:02:41Z","updated_at":"2015-08-27T02:44:13Z","closed_at":null,"body":"Suppose the Atomspace already contains\r\n\r\nSatisfyingSetLink (VariableNode \"$X\") (EvaluationLink (PredicateNode \"humans\") (ListLink (ConceptNode \"eat\") (VariableNode \"$X\")))\r\n\r\nand then someone loads, from the backing store, the construct\r\n\r\nSatisfyingSetLink (VariableNode \"$Y\") (EvaluationLink (PredicateNode \"humans\") (ListLink (ConceptNode \"eat\") (VariableNode \"$Y\")))\r\n\r\nAccording to my understanding of the current code [please correct me if I'm wrong], these will look different because the VariableNodes have different names, so they won't be merged. But actually they are redundant; they  mean the same thing. \r\n\r\nOf course this is just a simple example, much more complex ones are possible.\r\n\r\nWithout VariableNodes, the basic merge rule is that two Nodes are the same if they have the same name and type; and two Links are the same if they have the same type and target-list\r\n\r\nWith VariableNodes, it's more complicated...\r\n\r\nLet's use the term Scoping Link to mean any link that can specify a variable binding, e.g. BindLink, LambdaLink, SatisfyingSet, ForAll, etc. etc. \r\n\r\nEach Scoping link can be viewed as the root of an Atom-dag: follow the outgoing set of the ScopingLink, and the outgoing set of everything you find that way, etc. ... and you get the Scoping link's Atom-dag..\r\n\r\nSo the basic merge rule for Scoping links is: Two Scoping links are the same if they are roots of Atom-dags that are the same up to a renaming of the VariableNodes that they scope....\r\n\r\nIn theory this could be expensive to check; in practice currently our Scoping links don't scope extremely large variable lists, so there's not a big compute-time issue here...\r\n\r\nThe issue is to implement this merge rule for Scoping links...\r\n\r\n(Of course, this would be relevant to any system for passing Atoms from one Atomspace to another (via ZMQ or whatever); it's just that with our current infrastructure it would only come up in the context of the backing store...)\r\n\r\n\r\n\r\n\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/opencog/opencog/issues/comments/135262723","html_url":"https://github.com/opencog/opencog/issues/1742#issuecomment-135262723","issue_url":"https://api.github.com/repos/opencog/opencog/issues/1742","id":135262723,"user":{"login":"bgoertzel","id":5907804,"avatar_url":"https://avatars.githubusercontent.com/u/5907804?v=3","gravatar_id":"","url":"https://api.github.com/users/bgoertzel","html_url":"https://github.com/bgoertzel","followers_url":"https://api.github.com/users/bgoertzel/followers","following_url":"https://api.github.com/users/bgoertzel/following{/other_user}","gists_url":"https://api.github.com/users/bgoertzel/gists{/gist_id}","starred_url":"https://api.github.com/users/bgoertzel/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/bgoertzel/subscriptions","organizations_url":"https://api.github.com/users/bgoertzel/orgs","repos_url":"https://api.github.com/users/bgoertzel/repos","events_url":"https://api.github.com/users/bgoertzel/events{/privacy}","received_events_url":"https://api.github.com/users/bgoertzel/received_events","type":"User","site_admin":false},"created_at":"2015-08-27T02:44:13Z","updated_at":"2015-08-27T02:44:13Z","body":"I agree with this...\n\nOn Thu, Aug 27, 2015 at 1:30 AM, Linas Vepštas <notifications@github.com>\nwrote:\n\n> I humbly suggest that the phrase \"merge rule\" is a dangerous software\n> architecture phrase, to be used with great caution, else you will get very\n> unsatisfactory results. There's a Zen koan called \"mechanism not policy\",\n> as old as software itself. It is rooted in the experience that, whenever\n> you place policy into software, you end up with an incomprehensible system\n> and unusable code.\n>\n> With this in mind, I was careful to remove all \"merge rules\" (aka merge\n> policies) from the atomspace, and from the backend. My goal is to have the\n> atomspace (plus backend) be very small and minimalistic, providing some\n> basic generic tools allowing you to do whatever, completely shorn of any\n> rules or merge policies at all.\n>\n> Policy is not bad; to get a high-quality user experience, you need good,\n> strong policies. But they need to be isolated into their own layer or\n> module, rather than infesting the system.\n>\n> So, any merge rules, data scrubbing, normalization, etc. needs to happen\n> in a different layer, some new layer. Nil previously talked about scrubbing\n> the atomspace, to make sure that all atoms have the correct types (type\n> checking); such a lyuer would be a good place to implement such things.\n>\n> —\n> Reply to this email directly or view it on GitHub\n> <https://github.com/opencog/opencog/issues/1742#issuecomment-135117239>.\n>\n\n\n\n-- \nBen Goertzel, PhD\nhttp://goertzel.org\n\n\"The reasonable man adapts himself to the world: the unreasonable one\npersists in trying to adapt the world to himself. Therefore all progress\ndepends on the unreasonable man.\" -- George Bernard Shaw\n"}}