good morning; > On 2017-05-07, at 07:02, Laura Morales <laure...@mail.com> wrote: > > In layman terms it's a local SPARQL endpoint with the difference that instead > of me having to setup the whole server and load the datasets, the endpoint is > setup automatically and the data is also automatically downloaded (in chunks, > based on queries needs). Yes?
i do not understand the approach to be one which deploys a local sparql _endpoint_. the posted software (http://linkeddatafragments.org/software/) embeds the sparql processor in the application. whether the application turns around and acts as a sparql endpoint is a separate question. > > >> i enquired once, why the intention to have a reliable endpoint was not a >> dimension in the statistics which they collected and whether that would have >> changed the conclusion, but have never gotten a thorough answer. >> they have, instead, established a ldf source for datasets as their >> demonstration that such a source should be easier to field. (the lod >> laundromat) > > > Sorry I don't completely understand. Do you mean to say that they only > considered reliable SPARQL endpoints but didn't take this into consideration > in their "demonstration"? This sounds very naive and deceiving. they sampled the uptime of every sparql endpoint which was publicly available without including in their statistics the _intended_ availability. that is, they did not include in their analysis, whether the endpoint provider intended the endpoint be reliable in the first place. the other significant dimension of their analysis was the query complexity, by which measure they argued that a local control structure would afford more complete - or at least more controllable results from complex queries. note however, that one means which they introduce to govern server resource usage is response paging, which is also available from a sparql endpoint. best regards, from berlin, --- james anderson | ja...@dydra.com | http://dydra.com
