Re: RDF* vs RDF vs named graphs

On 12/4/2020 8:33 PM, Pavel Klinov wrote:

> Disclaimer: YMMV, other vendors may have a different experience. I'm 
> not really willing to debate who's experience is the right or most 
> representative, just responding to Pierre-Antoine's call for vendor 
> comments.

As a vendor report from TopQuadrant, we had introduced reification based 
on long URIs a few versions ago, and several customers have it in 
routine use. We have introduced a light-weight SHACL extension to allow 
validation and to drive input forms, see 
http://datashapes.org/reification.html#reifiableBy - this solution seems 
popular and efficient for its use cases.

One customer (at least) had asked for backward-compatible converters on 
data import and export between the long URIs and rdf:Statements. I think 
this is understandable at least until some Turtle* syntax becomes widely 
accepted that would hide those complexities. And these customers have 
existing external systems that rely on standard reification. Not that 
there is a potential mismatch in that standard reification allows the 
same triple to be reified multiple times.

Technically, it would not be a complete show stopper for us to treat 
RDF* as a syntactic sugar for rdf:Statements, yet we would almost 
certainly require graph-level optimizations and special indexes. In 
particular it needs to be efficient to ask "get me all reifications for 
a given triple" for display purposes on a form, and to perform clean up 
if an asserted triple gets deleted. With the long-URI approach this can 
be answered in constant O(1) time, while a naive rdf:Statement 
implementation would require joins. And rdf:Statements may cause a 
maintenance nightmare (partial adds/deletes etc) and may cause 
misleading matches in the graph (e.g. incoming references that are 
really on the reification layer). The long URIs are however currently 
very memory hungry, so we are sitting at an unsatisfactory in-between state.

Introducing a new node type for triples is not viable because it breaks 
too much existing code. From what I can tell this option seems to be on 
its way out.

Holger

Received on Saturday, 5 December 2020 01:29:06 UTC