Re: Paging with SPARQL CONSTRUCT implementations

John,

Thanks for your feedback. 

I don't think this case is limited to case where the last page is exactly full. My understanding is that the definition of LIMIT in a SPARQL CONSTRUCT query isn't to limit the number of *statements" returned. Rather, it limits the number of *solutions* returned, so a limit of 1 can return more than one statement, but only one solution mapping. Therefore, I can't just count the number of statements returned to determine if I have a full page or not, so I have no way of knowing when I'm at the last page unless there's no data returned by the query.

I think your idea about returning a next-page URL on an empty page may work. However, it will be awkward to have an empty page for the sole purpose of just containing a next-page pointer to nil.

I was wondering if instead of requiring a pointer to nil for the last page, the client can infer from an empty page that there's no more data. Is there really a difference from the client's perspective between having next-page point to rdf:nil, or point to a page that contains no data? In my case, why require an empty page with a next-page pointer to rdf:nil? In other words, instead of 5.3.6.3 saying that "the last page representation MUST have ... object being rdf:nil" , can it be "the last page representation MUST have ... object being rdf:nil or point to an empty page"?

-Elli



>________________________________
> From: John Arwe <johnarwe@us.ibm.com>
>To: Elli Schwarz <eliezer_schwarz@yahoo.com> 
>Cc: "public-ldp@w3.org" <public-ldp@w3.org> 
>Sent: Friday, June 7, 2013 8:38 AM
>Subject: 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 
>
>
>