🥇What is happening now with RDF repositories?

The Semantic Web and Linked Data are akin to the nearby cosmos: there is no life there. To venture there for a more or less extended period... well, I don't know what you were told in childhood in response to "I want to be an astronaut." But one can observe what's happening even from Earth; becoming an amateur or even professional astronomer is much easier.

This article will discuss recent trends from the world of RDF stores, not older than a few months. The metaphor in the first paragraph was inspired by an epic-sized advertisement image below.

Epic image

I. GraphQL for RDF Access

They say, that GraphQL aims to become a universal language for database access. But how does access using GraphQL to RDF work?

"Out of the box," such an opportunity is provided by:

Stardog (blog, documentation);
TopQuadrant products (a webinar, documentation).

If the store does not provide such a capability, it can be implemented independently by writing a corresponding "resolver." This was done, for example, in the French project DataTourisme. Or one might not even need to write anything and simply use HyperGraphQL.

From the perspective of an orthodox believer in the Semantic Web and Linked Data, all this is, of course, sad, as it seems designed for integrations built around yet another data silo, rather than suitable for those platforms (of course, RDF stores).

The impressions from comparing GraphQL with SPARQL are mixed.

On one hand, GraphQL looks like a distant relative of SPARQL: it solves typical REST issues of over-fetching and multiple queries — without which, it seems, one could not consider it a query language, at least for the web;
On the other hand, the rigid structure of GraphQL is disappointing. Consequently, its "introspection" seems very limited compared to the full reflexivity of RDF. And there is no equivalent of property paths, so it's not quite clear why it's "Graph-."

II. Adapters for MongoDB

A trend complementary to the previous one.

in Stardog now is possible — in particular, using the same GraphQL — to configure the mapping of MongoDB data into virtual RDF graphs;
GraphDB has recently , rather than taking focus. allowed inserting MongoDB Query snippets into SPARQL.

Speaking more broadly about adapters to JSON sources that allow representing the stored JSON in these sources as RDF more or less "on the fly," one can recall the long-existing SPARQL Generate, which can be adapted, for example, to Apache Jena.

In summary of the first two trends, it can be said that RDF stores demonstrate full readiness for integrations and operation in conditions of "polyglot persistence." However, it is known that this latter trend has long been out of fashion, and in its place is coming multimodality. So how is multimodality faring in the world of RDF stores?

In short, not at all. The topic of multimodal databases deserves its own article, but for now, it can be noted that multimodal databases "based" on the graph model (of which RDF can be considered a variant) are currently nonexistent. Some minor multimodality—support for RDF stores for alternative graph models like LPG—will be discussed in Section V.

III. OLTP vs. OLAP

However, Gartner itself writes, that multimodality is a sine qua non condition primarily for operational databases. This is understandable: in a situation of "polyglot persistence," the main problems arise with transactions.

But where do RDF stores fall on the OLTP—OLAP scale? I would answer like this: neither here nor there. To denote what they are intended for, some third abbreviation is needed. As an option, I would suggest OLIP — Online Intellectual Processing.

However, still:

the integration mechanisms realized in GraphDB are not only intended to circumvent performance issues during writes;
Stardog goes even further and completely rewrites the engine, again with the aim of improving write performance.

And now, allow me to introduce a new player in the market. From the creators of IBM Netezza and Amazon Redshift — AnzoGraph. The product’s advertising image was placed at the beginning of the article. AnzoGraph positions itself as a GOLAP solution. How do you like SPARQL with window functions? —

SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE {  …  }

IV. RocksDB

Above, there was already a reference to the announcement of Stardog 7 Beta, where it was stated that Stardog plans to use RocksDB as its underlying storage system — a key-value store, a Facebook fork of Google’s LevelDB. Why is it already worth mentioning a trend?

Firstly, according to the Wikipedia article, not only RDF stores are switching to RocksDB. There are projects utilizing RocksDB as a storage engine in ArangoDB, MongoDB, MySQL and MariaDB, Cassandra.

Secondly, projects (i.e., not products) of the respective theme are being developed on RocksDB.

For example, eBay uses RocksDB in its platform for its 'knowledge graph'. By the way, it's amusing to read: the query language started as a home grown format, but more recently it has been transitioning to be much more like SPARQL. Like in the joke: no matter how many knowledge graphs we create, it always turns out to be RDF.

Another example is the recently launched Wikidata History Query Service. Before its introduction, historical information from Wikidata had to be accessed through MWAPI the standard Mediawiki API. Now, much is possible with plain SPARQL. 'Under the hood,' it also uses RocksDB. By the way, the WDHQS was apparently created by someone who worked on importing Freebase into Google Knowledge Graph.

V. Support for LPG

Let me remind you of the main difference between LPG graphs and RDF graphs.

In LPG, scalar properties can be attached to edge instances, whereas in RDF they can only be attached to 'types' of edges (though not only scalar properties but also regular relations). This limitation of RDF compared to LPG is overcome by various modeling techniques. The limitation of LPG compared to RDF is harder to address, but LPG graphs resemble images from Harari's textbook more than RDF graphs, which is why people prefer them.

Clearly, the task of 'supporting LPG' breaks down into two parts:

introducing changes into the RDF model that allow mimicking LPG constructs;
introducing changes into the RDF query language that allow querying data in this modified model, or alternatively, implementing the ability to query this model in popular LPG query languages.

V.1. Data Model

There are several possible approaches.

V.1.1. Singleton Property

The most literal approach to harmonizing RDF and LPG is probably the singleton property:

Instead of, for example, the predicate :isMarriedTo the predicates :isMarriedTo1, :isMarriedTo2 etc.
are used. Then these predicates become the subjects of new triplets: :isMarriedTo1 :since "2013-09-13"^^xsd:date and so on.
The connection of these predicate instances with the common predicate is established through triplets of the form :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
It is evident that rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, but think about why you shouldn't just write :isMarriedTo1 rdf:type :isMarriedTo.

The task of 'supporting LPG' is solved here at the RDFS level. This solution requires making appropriate modifications. the standardSome changes may be required from RDF stores that support conjunctions of consequences, and for now, the Singleton Property can simply be perceived as another modeling technique.

V.1.2. Reification Done Right

Less naive approaches stem from the realization that property instances can indeed be instantiated by triplets. By being able to say something about triplets, we gain the ability to speak about property instances.

The most solid of these approaches is RDF*, also known as RDR, which emerged from within Blazegraph. It has been chosen for itself and AnzoGraph from the very beginning. The solidity of the approach is defined by the fact that within its framework, for installation in WSL appropriate changes in RDF Semantics. The essence, however, is extremely simple. In Turtle serialization of RDF, it will now be possible to write something like this:

<> :since "2013-09-13"^^xsd:date .

V.1.3. Other approaches

One can disregard formal semantics and simply consider that triplets have certain identifiers, which are, of course, URIs, and create new triplets with these URIs. It will only remain to provide access to these URIs in SPARQL. This is how Stardog does. In Allegrograph,

by an intermediary route. It is known that identifiers of triplets in Allegrograph exist, but they do not manifest externally when implementing triple attributes. However, there is still a long way to go to formal semantics. Notably, the attributes of triplets are not URIs, and the values of these attributes can only be literals. LPG advocates get exactly what they wanted. In a specifically devised NQX format, an example similar to the one presented above for RDF* appears as follows: reached :bob :marriedTo :alice {"since" : "2013-09-13"} there areV.2. Query Languages

Having supported LPG in one way or another at the model level, it is necessary to enable queries against data in that model.

Blazegraph supports queries to RDF* using

SPARQL*.

A SPARQL* query looks like this: SELECT * { <> :since ?since } and GremlinAnzoGraph also supports

 and plans to support

Cypher SELECT * { <> :since ?since } , the query language in Neo4j. Stardog supports its ownSPARQL and
again, extension Gremlin. You can obtain the URI of a triplet and 'meta-information' in SPARQL using roughly the following construction: SELECT * { BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id) ?id :since ?since } Allegrograph also supports its own

SPARQL:

SELECT * { ("since" ?since) franz:attributesNameValue ( :bob :marriedTo ?wife ) } extension By the way, GraphDB once supported Tinkerpop/Gremlin without supporting LPG, but this ceased in versions 8.0 or 8.1.

 SELECT * { ("since" ?since)  franz:attributesNameValue  ( :bob :marriedTo ?wife ) }

Interestingly, GraphDB at one time supported Tinkerpop/Gremlin without supporting LPG, but this changed in version 8.0 or 8.1.

VI. Tightening of Licenses

There have been no additions recently in the overlap between the 'triplestore of choice' and 'open source triplestore'. New open-source RDF stores are far from being a good everyday option, and the source code for new RDF stores that one might want to use (such as AnzoGraph) is closed. It would be more accurate to say that there are even reductions...

Of course, open source is not being closed down, but some open-source repositories are gradually ceasing to be seen as worthy options. In my opinion, Virtuoso, which has an open-source edition, is drowning in bugs. Blazegraph was purchased by AWS and forms the basis of Amazon Neptune; it is now unclear whether there will be another release. Jena remains...

If open source is not that important, and you just want to try something, the situation is also less rosy than before. For example:

Stardog is stopping is distributing a free version (though the trial period for the regular version has doubled);
downward API support (simultaneously with this in GraphDB Cloud, where it was previously possible to choose a free basic plan, has suspended registration for new users.

Overall, for the average IT person, the cosmos is becoming more and more inaccessible, mastering it is becoming the domain of corporations.

Source: habr.com