Temporal index support

Is there any chance that Stardog is considering adding support for temporal indexes? I know someone mentioned they were looking into bitemporal modeling but I've always thought it would be really nice to have an index over temporal literals similar to what Waldo offers for text.

I've looked into doing it myself and I know that it's theoretically possible but I think it's a bit too much for me to be able to glean all the mechanics of it from the outside.

In looking around I came across this excellent APL licensed library https://github.com/questdb/questdb which I'll just casually drop here. :slight_smile:

Another route I was thinking of that wouldn't be as closely integrated but might be simpler would be to write a transaction listener that wrote to a kafka topic and then loading it into an external datastore from there and using a virtual graph. Stardog doesn't specifically support QuestDB but it supports SQL and the Postgres wireline protocol so I'm guessing I could use the postgres jdbc driver. Any thoughts on doing something like that?

Hi Zach,

Coincidentally I'm working on a prototype for something like that for numerical datatypes so if that goes well, we may consider temporal literals next. Yes, architecturally it may work along the lines that you described but it's possible to experiment with an in-memory index first.

Thanks,
Pavel

Awesome. I really wish I understood what was required because I'd also like to integrate an approximate nearest neighbor search index https://github.com/jelmerk/hnswlib so that you could load images with BITES and add a bites extractor to compute feature vectors. Then you could use Stardog to do image retrieval. Stardog would also make a great backend for an image annotation service.

I get how the predicate function is transformed into a service call but complex part seems to be ConnectableConnection and the transaction handling. I'm also not sure how the connection gets registered so that it can listen for changes.

I remember someone saying something about expanding the user api, are you guys still working on that because I'm all over that when you do.

Right, there're two big parts:

Alternatively you can do a custom HTTP service and access your stuff via an HTTP API rather than queries.

Happy to explain in more details,
Pavel

Thanks. I'd love to understand it well enough to implement something like this. I keep forgetting that transaction listeners are implemented by registering a connectable. I'll give it a go and see if I can come up with more specific questions. I guess I'll start with getting more familiar with the transaction listener example and work out from there.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.