Google Badwolf: Temporal graph store abstraction layer
github.com
github.com
I'd have to read more to know how they really compare.
But looks like this may be somewhat more oriented towards including temporal information in queries, which implies a slightly different indexing model to Datomic (where time is the last component of all the indexes the Datalog query system accesses).
> Covariant: Given two types A and B, A covariant B if B is a A. In other word, A covariant B if B is a prefix of A.
Taken from here: https://github.com/google/badwolf/blob/master/docs/temporal_...
Co(ntra)variance only makes sense if you define a subtype relation first. And I think that's what you wanted to define here.
After skimming through the docs I think what you want is: A is a subtype of B if B's path is a prefix of A's.
I've been doing graphs for a long time, and I'm not quite sure I get what a 'temporal triple' is exactly (or what its use case is) from the docs. But I'm willing to learn!
Also, considering that only in-memory storage is shipped here, is this an internal Google project that was only partially released? Or a work in progress?
Lots of SQL databases don't have good constructs for dealing with ranges, which make lots of operations you'd want to do with temporal data awkward (PostgreSQL since 9.2 has range types, and lots of useful features attached to them, that address this.)
Beyond that, pretty much all the normal SQL vs. NoSQL considerations would seem to apply without much change when you address temporal data, so the usual mix of ACID vs. scalability, schema enforcement vs. schemaless flexibility, etc., considerations apply.
If you want to know the advantages of triple stores, there's a lot out there.
One key strength is that triple stores have a "schema as data" approach, meaning that schemas can be made to follow rules on the fly based on the data contained within them. Nothing that application code can't do, of course, but the entire purpose of these kinds of databases is to find a way to have data be as self-descriptive as possible.
Schema as data is historically a fairly important element of the relational model.
Not really. You derive a schema from data already stored in a relational database by looking at multiple, non-data places. I'm not sure I would necessarily consider that "schema as data" especially since many of the things you would need to automatically derive a schema may not be present in an optimally performing RDMS. For instance you need foreign keys to understand relationships but I've seen many times where performance is improved through handling foreign key integrity through the application versus at the database level.
No, the schema is itself stored in tables; conceptually, while the structure of those control tables needs to be immutable (that is, the data in the control tables that also relates to the control tables needs to be protected against modification), in an ideal DB following the model, schema changes that can be done through DDL are logically equivalent to executing DML against the control tables and can be done that way, as well; in practice, several RDBMS's do allow this, though typically they only allow superusers to use DML against system tables, even though normal users may have permission to make equivalent changes through DDL.
... I only looked at the github for 20 seconds
your explanation wasn't good...
thanks for offering a productive contribution to the discussion!
edit: maybe a better description: is "relational" database with support for time attributes and time queries.