Incremental SPARQL Compute/Caching

[jonrmayer]

Feldera looks pretty awesome.

Curious whether similar principles could be used in rdf-fusion.

Relevant (extended) Paper is
DBSP: automatic incremental view maintenance for rich query languages

The SQL to DBSP compiler is a tight integration between df and Apache Calcite.

Might have a closer look.

[tobixdev]

I see we have similar interests 😄 . It is on my TODO list to investigate this further. Do you have any particular use case in mind?

I think this work can be be relevant for continuous SPARQL extensions, such as C-SPARQL and SigSPARQL (disclaimer, I am one of the authors) in the context of RDF Fusion (which is also the reason why I've briefly looked into it).

[jonrmayer]

Also there is datafusion-materialized-views for a (probably) simpler version.

My current interest are Discrete Global Grid Systems for fast spatial joins/spatial data synthesis and analysis.

There are potentially trillions of indexes.

It's why I am obsessed with performance ;-)

GeoSPARQL already has a placeholder for them - hence my curiosity with SPARQL in general.

[tobixdev]

That seems very interesting!

There are potentially trillions of indexes.

What is exactly an index in this context?

Maybe we can collect some issues that we can track for supporting such type of experiments within RDF Fusion? From my perspective this could cover:

• Support custom access paths for certain patterns (e.g., use geospatial index for certain pattern + filter combination)
• Support "callbacks" when inserting some triples (to keep the index up-to-date)
• GeoSPARQL support in general (which I would find really cool!)

I don't have currently that much time to tackle these issues but they would be a great reminder for myself or someone else could become interested in implementing it.

[jonrmayer]

What is exactly an index in this context?

Sorry. It is a Cell Reference. They get used interchangeably..

Instead of using a coordinate to describe a location, we use a cell reference.

It helps us move from the navigation grid to the information grid - this makes it useful for KGs.

Resolution can get nasty - you can imagine how many 1*1m cells there are in the world ;-)

It all depends on the dataset.

Examples :

Level 1

Level 10 - (169*169m)

[tobixdev]

Ah now I get it. Thanks for the clarification! If I understand that correctly, that means that a regular Triple Index works well on these kind of data right? As you could simply state ?myThing <isIn> <MyCell> Where <isIn> is a predicate from GeoSPARQL.

[jonrmayer]

Pretty much. The hierarchies are important for calculating parent/child/sibling relationships.

GeoSPARQL - DGGS also offers the ability to calculate more traditional spatial relationships.