From OpenCog


Linas, in you last change you seem to say that AtTimeLink is deprecated. That's a weird statement. Sure in cases you just want to update the time associated to some event, and you don't care about remembering the previous time, a Value is better. But often you need to remember the time of all events, reason about it, etc. And if so then using an explicit AtTimeLink is the way to go, isn't it?

P.S: not sure it is the right place to discuss this, just trying...

Yes, this is the right place to discuss. It's easy to argue that AtTimeLink is needed. That's not the point. The point is that when you use the AtTimeLink, the atomspace gets polluted with junk. I'm looking for ways to cut down on the junk-pollution.
The key question to answer is this: How often do you really need to look at the incoming set of a TimeNode? I suppose that you do, if you are trying to answer the question: "what else happened on 22 November 1963?" This is very different than the problem of filling up the atomspace with 400 AtTimeLinks per second, to record things that the robot is seeing. Linas (talk) 21:55, 19 May 2018 (UTC)
Well, except that even the query for ""what else happened on 22 November 1963?" is problematic, because you need to have a 24-hours fuzz on the date. So, you could have two TimeNode's, just one second apart, and you have no practical way of discovering that they are only one second apart -- which essentially means that its more-or-less useless to try to look at their incoming set -- You'd have two different AtTimeLinks, but since they're connected to two different TimeNodes, there is no way to find them (viz by the pattern matcher, which traces through the incoming set, or the pattern miner, which also traces that way). So, if the incoming sets of a TimeNode are more-or-less useless, then why are we burning valuable CPU and RAM storing them, indexing them? This suggests that TimeNodes should not be Atoms, since there is little benefit to storing them as Atoms. Linas (talk) 22:03, 19 May 2018 (UTC)