Does Asami make a distinction between system time and valid time like XTDB?
No. The only time in Asami is the timestamp stored on transactions, and whatever is inserted in the data. I’m not actually familiar with all of the various time elements in XTDB, so I’d need to learn more about that, I’m reworking parts of Asami right now, and considering more metadata on each statement. I’m still trying to figure out what most people would consider useful
I skimmed this recently, might be enlightening: https://academicworks.cuny.edu/cgi/viewcontent.cgi?article=6041&context=gc_etds > BiTRDF: Extending RDF for BiTemporal Data It at least gives a comprehensive looking summary of the various approaches explored in the RDF landscape previously. However the approach the author actually proposes is more akin to XTDB's model, where the timestamps are universal and completely orthogonal to the domain
Thanks! Not saying it should work one way or another, just trying to see where the handful of similar databases differ.
Perhaps @taylor.jeremydavid could enlighten me on the specifics of XTDB 🙂
https://en.m.wikipedia.org/wiki/Temporal_database It's actually not specific to xtdb but rather a property of temporal databases: Uni-temporal Bi-temporal Tri-temporal
I think @dave554 was referring to bi-temporality
OK… I had a sense of this. While I know that each statement in XTDB contains each of these, I have been thinking that I’d rather use the property-graph approach.
I'm not familiar with property-graph, is it an alternative to a temporal model or are they orthogonal?
As of Asami 2.0 (I think), every statement receives its own ID internally. This is not currently exposed to users, but I want to do that. It will then be possible to make statements about individual statements. For instance, I could start with a transaction on 2024-01-01 that describes “Mary”:
:person/mary :first-name "Mary" #1
:person/mary :last-name "Jones" #2
:person/mary :dob "1990-06-05" #3
Then a new transaction on 2024-04-01:
:person/mary :last-name "Smith" #4
:person/mary :spouse :person/peter #5
Then I want to describe that Mary got married, and this is why those statements occurred:
:event/wedding-7856 :type :Wedding #7
:event/wedding-7856 :date "2024-02-29" #8
#5 :provenance :event/wedding-7856 #9
But her name change was a week later, so:
#4 :occurred "2024-03-07" #10
There are 3 types of dates here:
• Dates on the transactions (each statement is connected to a transaction - not shown here)
• date property on an entity (the date of the wedding event)
• date property on a statement (the date the name change occurred)Property graphs let you make statements (like dates) on statements. So, something like:
<< :mary :married :peter >> :date "2024-02-29"
<< :alice :married :bob >> :date "2020-05-06";
:location "500 Indiana Ave NW, Washington, DC"
So… they’re orthogonal
Sounds like bi-temporality (maybe even tri-temporaily I'm not entirely sure I understood all the details you conveyed in the example). I think one of the key features of a higher order temporal dbs is that you can utilize all the temporal tools (time travel, as if...) on time axis other than the transaction time. Is this also true for asami?
No, only by transaction
that's a bi-temporal example and the power of temporal dbs is as @lidorcg said, having the query engine work on a point in time version of the data, whatever time axis required (tx, occurrence, statement etc)