Re: Paging with SPARQL CONSTRUCT implementations

Hi Elli,

I don't really understand what you're asking for. As John says the spec 
doesn't stop you from finishing with an empty page. Are you saying you 
don't want that page to be required to have ldp:nextPage rdf:nil either? 
What would nextPage point to then? Another empty page?

It seems to me that you're pushing the burden of figuring out whether you 
have an empty page or not to the client. Yet, you ought to be able to 
detect that your SPARQL query didn't return anything, right?

Regards.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group




From:   Elli Schwarz <eliezer_schwarz@yahoo.com>
To:     John Arwe/Poughkeepsie/IBM@IBMUS, 
Cc:     "public-ldp@w3.org" <public-ldp@w3.org>
Date:   06/07/2013 08:14 AM
Subject:        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