You can have multiple TDB stores, each holding Quads. So in that sense you can have Quints. However to query across them you would have to do a federated query, which sounds overkill.
Unless you start mixing in permissions and privacy (which can also be achieved at graph level) then I don't see a big reason for needing Quints. For storing qualifying information, would a Nanopub structure work well? http://nanopub.org/wordpress/?page_id=65 In nanopublications you would have 4 graphs: In the main graph (or whatever is your graph of choice), we declare a Nanopublication: @prefix nanopub: <http://www.nanopub.org/nschema#> . <nanopub1> a nanopub:Nanopublication ; nanopub:hasAssertion <assertion1> ; nanopub:hasProvenance <provenance1> ; nanopub:hasPublicationInfo <publication1> . In the Assertion graph <assertion1> - the thing that has been stated/claimed: <http://dbpedia.org/resource/Coffee> :causes <http://dbpedia.org/resource/Thirst> . Obviously as a separate graph you can extend this to multiple triples. In the Provenance graph <provenance1>, you can say things like who made the claim, e.g. the provenance of <assertion1>: <assertion1> prov:wasAttributedTo <http://orcid.org/0000-0002-5711-4872> ; pav:createdAt "2014-12-02T15:00:00Z"^^xsd:dateTime . <http://orcid.org/0000-0002-5711-4872> foaf:name "Alasdair J G Gray" In this provenance it does not matter how <assertion1> was made, e.g. Alasdair could simply have said it out loud in a coffee shop. (prov:location to the rescue!) Nanopublications are commonly used to structure assertions in RDF that are otherwise not structured, e.g. from textual claims in a medical journal paper. In the Publication graph <publication1> you provide the metadata about the nanopublication itself, e.g. it could have been made by an automatic annotation software, and then curated by Stian. <nanopub1> pav:curatededBy <http://orcid.org/0000-0001-9842-9718> ; pav:createdWith <https://github.com/stain/superannnotator> ; pav:createdAt "2015-12-02T15:00:00Z"^^xsd:dateTime . <http://orcid.org/0000-0001-9842-9718> foaf:name "Stian Soiland-Reyes" . In this way it's clean separation of what was said, who said it where, and how this description as RDF was made. E.g. I won't claim that Alasdair said his name was "Alasdair J G Gray" - and we know the utterance was done in 2014 even though the RDF was made in 2015. Note that nanopub.org examples has not been updated in a while, and uses an outdated prefix for pav, the correct namespace should be <http://purl.org/pav/> On 1 September 2015 at 19:37, Patrick Hoeffel <[email protected]> wrote: > In looking at Jena source code it is clear that Jena natively supports > Triples and Quads throughout the persistence and query layers. I was recently > asked if Jena could support the notion of a Quint, and I didn't know the > answer. I do see some use of Node[] in various places in the source, > suggesting that "beyond-quads" might have been thought about, but it really > isn't something you hear much talk of, especially when a simple reification > can solve the problem. Really, the only reason to consider a quint over > reification is purely for raw performance, and that is precisely the use case > that is driving my question. I have a very large graph application with a > specific need to extend the triple to contain qualifying information, and > from what research I've been able to find, it seems to indicate that a quint > will perform better than a reified quad or triple. > > Thanks for any insight you may be able to offer, > > Patrick Hoeffel > Software Engineer > Intelligent Software Solutions (www.issinc.com<http://www.issinc.com>) > -- Stian Soiland-Reyes Apache Taverna (incubating), Apache Commons RDF (incubating) http://orcid.org/0000-0001-9842-9718
