lpg support in a triplestore

[nguyenm100]

Another item that is interesting to discuss, beyond rdf1.2 and some type of inferencing language support, is how we can better bridge the gap btwn lpg and 3s. At best there is confusion around which graphdb to use under which circumstances and at worst there's just pure animosity between the two camps. Invariably, it's just a bad outcome for the clients that often results in their frustration.

So what can exactly be done to bring us closer together to LPG?

rdf 1.2 is definitely a step in that direction with the ability to support the notion of "properties" on edges (we understand it's even more powerful than that). but what else?

Amazon is embarking on the OneGraph strategy (https://www.semantic-web-journal.net/content/onegraph-vision-challenges-breaking-graph-model-lock-0) which is fairly ambitious and arguably the correct thing to do but that seems a bit further away than what I'm hoping we can achieve for short term "wins"

should we consider supporting a vocabulary (and implementation) for graph functions like shortest path, centrality, etc?

stardog seems to have taken a SQL/SPARQL like approach (https://www.stardog.com/blog/a-path-of-our-own/) whereas I've seen others just use custom functions.

Curious what the community thinks about it?

[nguyenm100]

btw- i just realized these posts probably should be in the "ideas" section so @hmottestad or @kenwenzel can you please move (or let me know how I can do it?) tx

[Ostrzyciel]

Hi, yes, that all sounds very interesting and useful. For me some of the most important missing features from SPARQL is returning paths from queries and typical graph analytics algorithms, like those that you mentioned.

I'm not sure what are the WG's plans regarding new features in SPARQL, I haven't been following that closely.

I've used before the Blazegraph GAS API – it's a very clever thing: https://github.com/blazegraph/database/wiki/RDF_GAS_API
Basically, it's a paradigm similar to map-reduce that allows for implementing arbitrary parallelized graph analytics algorithms. You could implement a lot (if not all) of such algorithms on top of an API like this. Blazegraph had a few built-in algorithms (like BFS, PageRank...) that were accessible as SPARQL functions. You could also write your own algorithms in Java.

Maybe we could have something like this in RDF4J? I'm just throwing the idea out there, I have not looked into how complex would that be to implement and integrate with SAILs. But the nice part about GAS being parallelized by default is that it could work with distributed stores, funky GPU-accelerated stores and more... it opens up a lot of possibilities.

[JervenBolleman]

The graph algorithms would be a really appreciated contribution!
A second query language implementation is also welcome, but would be a lot of effort.

[nguyenm100]

can we get a list of algos that we would want to support?