asami

Dave Mays 2024-05-07T14:34:28.770659Z

Does Asami make a distinction between system time and valid time like XTDB?

quoll 2024-05-07T15:11:02.947739Z

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

refset 2024-05-08T09:37:53.844439Z

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

🙏 1
Dave Mays 2024-05-08T11:19:12.606699Z

Thanks! Not saying it should work one way or another, just trying to see where the handful of similar databases differ.

quoll 2024-05-07T15:11:53.535859Z

Perhaps @taylor.jeremydavid could enlighten me on the specifics of XTDB 🙂

2024-05-07T17:49:03.754029Z

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

2024-05-07T17:49:41.768029Z

I think @dave554 was referring to bi-temporality

quoll 2024-05-07T17:55:17.283959Z

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.

2024-05-07T18:03:51.748959Z

I'm not familiar with property-graph, is it an alternative to a temporal model or are they orthogonal?

quoll 2024-05-07T18:08:41.045559Z

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)

quoll 2024-05-07T18:12:27.391079Z

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"

quoll 2024-05-07T18:12:44.241949Z

So… they’re orthogonal

2024-05-07T18:21:52.518709Z

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?

quoll 2024-05-07T22:55:39.105949Z

No, only by transaction

itaied 2024-05-08T06:42:41.673799Z

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)