Re: Paging with SPARQL CONSTRUCT implementations

Please set subjects.

It's not obvious how LDP can help with this, aside from ripping out paging 
entirely which is a baby/bathwater situation.... and you seem to like the 
baby too ;-)
Recall that the purpose of paging is to partition the resource's state 
into "manageable chunks" for transfer from server to client.
The server knows what the boundaries of the resource's state are, i.e. 
what's part of the resource state and what's not, therefore whether or not 
there is any more state (more pages/chunks) left.
The client's only indication of these boundaries are what it gets from the 
server; the client needs to know when the server has no more state to be 
transferred, which is something that only the server can tell it.

Is this a problem for every resource in such an implementation, or only 
for the case where the final page is exactly full?  One obvious solution 
is to always provide a next-page URL until your construct returns zero 
triples (which is still a valid page of content), and mark it as the last 
page.  That costs the client one extra GET; if that's only happening when 
"the last non-empty page" exactly fills, doesn't sound like a big problem 
on the surface.  Another might be to set LIMIT+1, clip the page's content 
at LIMIT, and set the next-page URL value based on whether or not the +1 
was actually returned.

I think we'd be open to proposals still, although Last Call is fast 
approaching so don't wait long to make one/them.

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario




From:   Elli Schwarz <eliezer_schwarz@yahoo.com>
To:     "public-ldp@w3.org" <public-ldp@w3.org>, 
Date:   06/07/2013 02:40 AM
Subject:        Re: 



LDP Working Group:

In section 5.1.3 Paging, and specifically in 5.3.6.3, you describe that 
for the last page of a container (or resource after adoption of ISSUE-33) 
should contain a value of rdf:nil for the ldp:nextPage attribute. By the 
way, thank you for allowing paging for LDPRs as well!

In my scenario, I have a set of SPARQL CONSTRUCT queries that I use to 
create the RDF data when the user does a GET on an LDPC or LDPR URL. (I 
use URL path parameters as parameters in my SPARQL query to get specific 
results.) Due to my use of SPARQL CONSTRUCT, I have no way of knowing 
whether I'm serving the last page or not. I use LIMIT and OFFSET with 
ORDER BY in my SPARQL query to get back a certain number of query solution 
sets per page, but there's no way to know if the next offset will produce 
more data. Because of this, there's no way for me to know the last page.

Since my system directly returns the SPARQL CONSTRUCT results, I would 
prefer that I wouldn't have the server perform other queries to determine 
if there's more data, nor would I want to cache a somewhat larger result 
set so I can see if there's more data. I understand that LDP isn't tied 
directly to using SPARQL, so the fact that I can't get this info from 
SPARQL isn't a problem for LDP per se. However, I would suspect that my 
case is a typical use case. I don't think people are storing ldp: 
predicates directly in their data, so one way to add it is to use SPARQL 
CONSTRUCT queries to return their data in a format conforming to the LDP 
spec. Is there something else we can do instead of requiring rdf:nil as a 
pointer to the last page?

Thank you,
Elli Schwarz