Re: Does anybody here understand "Linked Data Fragments"?

2017-05-07 Thread james anderson
good evening;

> On 2017-05-07, at 14:56, sorok...@gmail.com wrote:
> 
> >
> > How do I activate this on Jena/Fuseki? Sounds useful to avoid returning too 
> > much data at once.
> >
> 
> In order to page, you will need to define an order for your results using 
> ORDER BY. Then you can use OFFSET and LIMIT to select pages out of those 
> results. Generally, this can be pretty expensive.

in general, for the sizes where one would bother to page, the order stage could 
be an issue.
but … is the order by actually required by fuseki?
this would be the case if the are results from one request to the next are not 
stable, but otherwise it would not be necessary.

> 
> ---
> A. Soroka
> 
> Laura Morales wrote on 5/7/17 4:55 AM:
>>> 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.
>> 
>> 
>> oh, I didn't expect this. From my understanding, LDF servers are supposed to 
>> return only simple subsets of their data, for example all values for a 
>> single subject " ?p ?o". So, for more complex queries I don't see 
>> how it's possible to answer the query without downloading huge chunks of the 
>> data and build some local graph.
>> 
>> 
>>> [..] one means which they introduce to govern server resource usage is 
>>> response paging, which is also available from a sparql endpoint.
>> 
>> 
>> How do I activate this on Jena/Fuseki? Sounds useful to avoid returning too 
>> much data at once.
>> 



---
james anderson | ja...@dydra.com | http://dydra.com







Re: Does anybody here understand "Linked Data Fragments"?

2017-05-07 Thread james anderson
good afternoon;

> On 2017-05-07, at 10:55, Laura Morales  wrote:
> 
>> 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.
> 
> 
> oh, I didn't expect this. From my understanding, LDF servers are supposed to 
> return only simple subsets of their data, for example all values for a single 
> subject " ?p ?o". So, for more complex queries I don't see how it's 
> possible to answer the query without downloading huge chunks of the data and 
> build some local graph.

that is what the client-side sparql processor does.
their papers go through the numbers and, as the saying goes, they’re also just 
cooking with water[1].
it's just that they have to carry theirs a bit further from the spring.

> 
> 
>> [..] one means which they introduce to govern server resource usage is 
>> response paging, which is also available from a sparql endpoint.
> 
> 
> How do I activate this on Jena/Fuseki? Sounds useful to avoid returning too 
> much data at once.

the language itself is limited in that limit/offset slices[2] are required to 
be in terms of constant values and it is unfortunate, that the sparql protocol 
does not standardize a way to carry those constraints in a request.

various implementations provide extensions for that.
- - -
[1] : https://en.wiktionary.org/wiki/auch_nur_mit_Wasser_kochen
[2] : https://www.w3.org/TR/2013/REC-sparql11-query-20130321/#solutionModifiers
---
james anderson | ja...@dydra.com | http://dydra.com







Re: Does anybody here understand "Linked Data Fragments"?

2017-05-07 Thread Laura Morales
> 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.


oh, I didn't expect this. From my understanding, LDF servers are supposed to 
return only simple subsets of their data, for example all values for a single 
subject " ?p ?o". So, for more complex queries I don't see how it's 
possible to answer the query without downloading huge chunks of the data and 
build some local graph.


> [..] one means which they introduce to govern server resource usage is 
> response paging, which is also available from a sparql endpoint.


How do I activate this on Jena/Fuseki? Sounds useful to avoid returning too 
much data at once.


Re: Does anybody here understand "Linked Data Fragments"?

2017-05-07 Thread james anderson
good morning;

> On 2017-05-07, at 07:02, Laura Morales  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







Re: Fwd: Does anybody here understand "Linked Data Fragments"?

2017-05-06 Thread Laura Morales
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 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.


> statistics on a wider range of such ldf servers - including the class parties 
> who ran the unreliable sparql endpoints, would be interesting.


yeah this would definitely need more benchmarks...


Fwd: Does anybody here understand "Linked Data Fragments"?

2017-05-06 Thread james anderson
good evening;

> Begin forwarded message:
> 
> From: "Laura Morales" <laure...@mail.com>
> Subject: Does anybody here understand "Linked Data Fragments"?
> Date: 2017-05-06 at 15:31:17 GMT+2
> To: jena-users-ml <users@jena.apache.org>
> Reply-To: users@jena.apache.org
> 
> As far as I understand them, clients are supposed to submit only simple 
> queries to servers in order to retrieve subsets of the data. Queries like 
> "?subject  ?object", and then download this snapshot (subset) of 
> the data; in this case the list of triples for the propery . The 
> data is downloaded locally, and then the client can issue SPARQL queries on 
> the local copy of the data just downloaded.

in ruben verborgh ’s approach - at the location you noted, the immediate 
“client” is itself a sparql processor - in the gent group’s case a javascript 
process, and the application uses that processor as in in-process sparql engine.

> Is this correct? Is this how "Linked Data Fragments" work?

the sparql aspect is layered on top of the ldf aspect.
that is one way they are used, but they are useful on their own - for example 
to back an object model.

> Doesn't this generate a lot of traffic, a lot of data moving around, and very 
> little improvement over using a local SPARQL endpoint?

it depends on ones goals.
last i read their papers, the numbers spoke for themselves, but the autonomy 
benefits outweighed the traffic and the performance
> 
> I really can't understand the benefits. Hlp!

they, years ago, recorded statistics which “demonstrated” the instability of 
sparql endpoints, suggest the conclusion that a sparql endpoint was too 
difficult, too resource intensive, too failure-prone, too (fill in the blank) 
to be relied on as a component in a robust semantic data processing stack and 
ventured off down the path of implementing their own sparql processor with 
linked data fragments as a remote protocol to accomplish the simple-entailment 
statement pattern matching which any sparql processor requires.

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)
statistics on a wider range of such ldf servers - including the class parties 
who ran the unreliable sparql endpoints, would be interesting.

> 
> For reference: http://linkeddatafragments.org

best regards, from berlin,



---
james anderson | ja...@dydra.com | http://dydra.com







Does anybody here understand "Linked Data Fragments"?

2017-05-06 Thread Laura Morales
As far as I understand them, clients are supposed to submit only simple queries 
to servers in order to retrieve subsets of the data. Queries like "?subject 
 ?object", and then download this snapshot (subset) of the data; 
in this case the list of triples for the propery . The data is 
downloaded locally, and then the client can issue SPARQL queries on the local 
copy of the data just downloaded.
Is this correct? Is this how "Linked Data Fragments" work? Doesn't this 
generate a lot of traffic, a lot of data moving around, and very little 
improvement over using a local SPARQL endpoint?

I really can't understand the benefits. Hlp!

For reference: http://linkeddatafragments.org