7 ms·

Are there any differences between a KV-store in the form of "Bob:Knows" — "John" and a triple store in the form of "Bob" — "Knows" — "John"? Redis, for example,

• xfhtjxfhj 7y ago
  you might want to search based on the predicate, or you might have versioned triples where the predicate changes in one version, you have these two ideas represented: [bob,likes,cake] [ann,suspects,[bob, likes, cake]] this may change in another version: [bob,likes,cake] [ann,knows,[bob,likes,cake]] a decent triple store will allow you to version these ideas and explore how they change over time, or maybe query by predicate
• coldtea 7y ago
  For one you could easily ask "what is the relationship between Bob and John?" --> Knows, which you can't without text manipulation in the KV format. Sounds contrived, but can be handy in many uses cases. Triple relationships like the above are the kind of queries a Prolog engine can answer well (and far more). Semantic Web's RDF is also like this.
  • kd5bjo 7y ago
    A slightly more plausible example is “Who knows John?”. I think about turning to triple stores when I’m still exploring an application domain and don’t know what data access patterns will look like yet. Something like a hexastore that maintains full indexes for all query orders seems like a reasonable compromise for read-heavy applications in the prototype stage.
• Someone 7y ago
  How you store your triples affects performance, but, conceptually, is only an implementation detail. But then, why stop at a KV-store? A set with entries “Bob:Knows:John” will work just as well, if you ignore performance. But then, why stop at a set? A string “Bob:Knows:John;Bob:Loves:John;John;Is;vegetarian” works just as well (conceptually!) IMO, a major real-life use case is as a means to produce PhD’s :-). The concept is enticing and easily grasped, but there are zillions of papers to write on query planning, automatic storage optimization, discovering heuristics, etc. It’s just like the early days of SQL: you don’t have to read decades of papers to move to the front of development.
  • kd5bjo 7y ago
    Unless I’m missing something, the in-memory backend here appears to actually use the set solution: all of the triple fields are concatenated together and used as a dictionary key. Queries iterate through the dictionary entries until a sufficient number of results have been located. On the other hand, I’m not really familiar with Go, so I may be reading it wrong.
• scoobyyabbadoo 7y ago
  >Are there any differences between a KV-store in the form of "Bob:Knows" — "John" and a triple store in the form of "Bob" — "Knows" — "John"? Redis, for example, can query the first one easily by scanning. A triple store can more quickly answer queries about triples. The reason to use triples is that it is what you naturally get when you try to store structured relational data where the schema changes quickly.
• PaulHoule 7y ago
  It is not unusual to implement a triple store with multiple indexes, so you could build k-v stores with s-p -> o p-o -> s s-o -> p and then you have indexes which are good for those triple patterns. Let's see. The core table in the salesforce.com system consists of triples, but salesforce.com will materialize whatever indexes and views are necessary to make things fast based on automatic run-time profiling. Their patent on this should run out just about now, so this feature may turn up in real-life triple stores where it would make a big difference in practicality. The NSA has been shopping around for a triple store which could ingest around 1 trillion triples per day. The BBC made a nice web site for the world cup which used forward chaining inference in a triple store to determine the consequences of each goal, so the tables would all adjust whenever anything happened.
  • mooreds 7y ago
    Do you have links for any of these lying around? Seems like some pretty cool examples.