- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Mon, 24 Nov 2014 15:15:42 +0100
- To: Kingsley Idehen <kidehen@openlinksw.com>
- Cc: public-hydra@w3.org
> are you inferring that SPARQL query solutions against your HDT based static datatet are faster than Virtuoso against the same static dataset? Of course not; I made this clear in my earlier mail; not to mention in the study we published before: http://linkeddatafragments.org/publications/iswc2014.pdf#page=13 I can't be more clear and honest than that, I'm afraid. >> We have measured that HDT performs the combination of >> “looking up data corresponding to a triple pattern” >> plus “give an estimate count of the number of matching triples” >> faster than Virtuoso or any other DBMS we tested. >> For numbers, see http://linkeddatafragments.org/publications/ldow2014.pdf#page=7. > > Why a PDF? You should have a collection of SPARQL Protocol URLs to backup up your claim. Actually, no—SPARQL Protocol URLs would not back up my claim at all, since it was not about SPARQL in the first place. > Then we have something that we can respond to, with ease :) There's nothing to respond to really; all that I'm saying is: We measured how fast triple pattern fragments can be generated using either a DBMS or the HDT format as backend. HDT was faster for that job. The experiment is reproducible: 1. Install https://github.com/LinkedDataFragments/Server.js/ and a DBMS on a machine; 2. Ingest a dataset into the DBMS and convert it to HDT. 3. Configure the server for the DBMS and for HDT. 4. Access triple pattern fragments and measure access times. So if you want to respond, please measure this and share your measurements, like I did. > BTW -- can you share with me, via a URL, an example of a multiple statement triple pattern fragment? By definition, a “multiple statement triple pattern fragment” does not exist. http://www.hydra-cg.com/spec/latest/triple-pattern-fragments/#definition Best, Ruben
Received on Monday, 24 November 2014 14:16:15 UTC