Giving this some more thought from a theoretical perspective, it seems likely that each posit type should have its own hashing chain (rather than the whole anchors). Since each posit represents a fact in real life that a positor can have an opinion about, they become kind of atomic in the theory. This indivisible thing, an atom of information so to speak. Then assertions become opinions about these atoms.
Today we usually use some integer sequence from which we pick numbers as identities for posits. Since every part of a posit defines the posit itself, the chained hash could be used as a key instead. Let p1 be the first posit for a certain posit type, and p2 the second:
p1 = (<42>, , €2500, '2016-05-30')identified by
#p1 = #(42|price|€2500|2016-05-30|#lag(p1, 1))where # is a hashing function, | a concatenation operator, and lag(p1, 1) is null, since no posit has yet been memorised.
p2 = (<42>, , €2000, '2016-05-23')identified by
#p2 = #(42|price|€2000|2016-05-23|#lag(p2, 1))where lag(p2, 1) = p1.
Some assertions can then be made as:
[Lars, #p1, '2016-05-20', 0.9][Lars, #p2, '2016-05-20', 0.9]using the hashes as references to the posits.
Would there be any reason to hash the assertions? I don't see any right now.
This would still be implementable in the database. However, if we are to address the other missing functionalities, I believe we have to think about writing our own software based on posits and assertions, rather than an implementation of these in a traditional relational database. Still, this additional feature alone would surely be useful in the database as well, as long as it is optional when you generate the code.
Any comments so far? :)
