Future of Blazegraph

[mjordan]

@barmintor pointed out in a recent post to the fedora-tech list that Blazegraph hasn't been updated in over 2 years (and BTW the company's Press page's last entry was from around that time), and given #730, I wonder if we should be looking for and testing alternative triplestores.

[DiegoPino]

Well, time is advancing and nobody is getting younger! RDF/Semantic-web has proven to be an elusive technology for human interaction in real world/big data scenarios. I see a 'tiny', but important, decline in SPARQL as querying language, at least for normal human interaction, and new options emerging that are better suited for graph traversal are emerging. I'm now considering Gremlin (Tinkerpop 3) as an option, since its nature seems way better suited for interactive querying directed graphs from a programing language perspective but then again, how long will it survive?.I already had my share of interactive SPARQL building and it is not fun, AWS Neptune is based on a highly modified Blazegraph and allows Gremlin. That said, seems obvious (right?) that AWS has acquired Blazegraph, so yeah (sad), AWS Neptune super-seeded commercially Blazegraph. Still, Wikibase is using it and i don't see them going away soon.

whois blazegraph.com
...
Tech Name: Hostmaster, Amazon Legal Dept.
Tech Organization: Amazon Technologies, Inc.
....

There is always Fuzeki2 (1.x is dead) https://jena.apache.org/documentation/fuseki2/

So yeah, in my perspective this, in the global context, presents itself as larger issue for all our communities and watching individuals in-between since we are moving slower than the larger IT needs and their supported standards. Maybe that is good in some way too right? Deprecation is always context relative.

[whikloj]

While all the above concern is true, we are still a community that continues to stand up instances of Fedora 3. However this work could probably fall under #30

[mjordan]

@DiegoPino ++ to

Deprecation is always context relative.

At least the triplestore is swappable, so unless we bind Blazegraph too tightly to Islandora, we should be in relatively good shape. To what does extent the codebase already use SPARQL? Too bad Drupal's search API could't be leveraged here (maybe it can?). I agree with @whikloj, we should be testing different triplestores as part of #30.

[dannylamb]

@mjordan It's so decoupled there is practically no SPARQL in the codebase. No part of the code actually relies on querying the triplestore, and the only code that uses SPARQL is the code responsible for indexing the triples.

In theory, any SPARQL 1.1 compliant endpoint will do so swapping should be fairly painless, but I'm at a loss as for the best alternative. FWIW, at least Fuseki is an apache project, but I'd prefer to ship with the fastest free software out there. Whatever that may be -- it's all speculation without testing. And if folks want to use Neptune that should be easy to set up, too.

[mjordan]

@dannylamb that's great to hear. Given that we're not tied to SPARQL, and that the triplestore is swappable, risk is low if Blazegraph becomes problematic in the medium term. But, I think it would be prudent to test other triplestores in #30 if resources allow.

Closing this for now but if anyone has further thoughts, please post 'em.