Data about the world is a funny thing. You can capture it in a hundred different ways, none of which is quite right. We do our best to forcefully map our never ending 4 dimensional time and space universe into low resolution, low fidelity models. This is a fools errand and a pointless task. One that I will soon undertake myself.
Objects in our world are related in time and space. The lamp that is in the kitchen. The sprinkler on the lawn. The car in the driveway before.
In all of these examples, the reference for where or when relies on/is in reference to another object in the world. Given some simple constructs such as “in” or “on” (prepositions) we can generate a path through an infinite number of real world objects to find our destination. That is origin + path = destination.
So now we have a graph traversal and a path planning problem. Luckily for me, these too are well studied problems which I can apply the pre-existing solutions to. A* for planning a path from the speaker to the destination object? Maybe!
But to come back to the subject of this post, how are we going to store and process our representation of the world? The early front runner is RedisGraph. The performance characteristics of Redis are well known and well documented and frankly are pretty freaking awesome. In the previous project I used Neo4j which in many ways is the grandfather of Graph Databases. Like many a happy old grandfather it’s a bit slow and pudgy around the midsection and the bite has gone out of it.
So we have our relationships, we have our database, we are missing one key element here. How will we store the properties of each object? OK, roll it back a second. Properties? OK, so for lack of a better term I’m calling the “attributes” or “states” of an object “properties” in this system. That means that a light will have the property of “on” which will have two possible values either “on” or “off”. A car will have a “colour” property which could be “green”.
I was consternated for quite a while as to whether or not to split properties into “states” (things that change often) and “attributes” (things that only change rarely and with great effort) but for now I have decided that the difference is arbitrary. I may revisit that in the future but for now everything is a property.
So we’re going with a graph database for our relationships (obviously) but what to do about our properties. Well there are document stores which we could map the world onto. Every object would be a document and the properties would be elements in that document. In Python parlance the properties would be keys and values in a Dictionary. A document database like MongoDB or Couchbase would fit the bill and allow us to do queries like “Give me all of the cars which are red”. Looking at this you may be wondering how often will that be useful? well I’m thinking the same thing, that’s why I’m going to shove JSON encoded dictionaries into a KV store and call it a day. Object_ID for the Key, JSON encoded dictionary for the Value. Thanks for playin. To keep it simple I’ll probably just use Redis for this as well.