UniProt: attributed/evidenced triples

[JervenBolleman]

UniProt: attributed/evidenced triples

[ericprud]

<P26948> up:annotation <P26948#SIPDB6A831D8E2E2D2A> .
<#_kb.P26948_up.annotation_A144DC8D56EA0928> rdf:type rdf:Statement ;
  rdf:subject <P26948> ;
  rdf:predicate up:annotation ;
  rdf:object <P26948#SIPDB6A831D8E2E2D2A> ;
  up:attribution <P26948#attribution-89AC1B682EEB440D50C4AEBB24FCA860> .

Is a lot of bytes to type., and even worse the five joins are very expensive to perform.

I assume those joins are on query, and would probably be resolved out in the pre-processor if they have constant predicates and objects. How can you avoid those joins if you have variables in place of e.g. <P26948> and up:annotation above? Would the idea be that an embTriple index would allow the SPARQL parser to recognize A. reified statements or B. an <<>> encoding thereof and turn the three self-joiins into a crawl through an SPO index over your embedded triples?

[JervenBolleman]

@ericprud the assumption is that instead of the current quad tables we would see a "quad+(virtual) triple id column" making the the five fold join of the reification quad just a single join (given a syntax such as << >>). This is possible with the PG constraints, harder for the SA mode to implement. Converting a reification quad into a << >> style query is possible by query rewriting but not needed for our usecase.