Re: Paging with SPARQL CONSTRUCT implementations

Arnaud,

Thank you for your response. Yes, I can tell if my query returns no results. Maybe your answer to the following question will help clarify things for me:

What do you expect to happen currently if a user tries to access the URL <http://example.org/netWorth/nw1/assetContainer/?p=55> and page 2 is the last page? Do you expect an empty page to be returned? Or do you also expect this response:

<http://example.org/netWorth/nw1/assetContainer/?p=55>
  a ldp:Page;
   ldp:pageOf <http://example.org/netWorth/nw1/assetContainer/>;
   ldp:nextPage rdf:nil. 

If the former is true, then that is what I would like to see in my case - you can try to access any page you want, and if it is the last page (or "after" the last page), then it will be empty, and there would be no requirement for any page to have a nextPage pointer to rdf:nil. 

If the latter is true, i.e., you always return a nextPage pointer to rdf:nil, regardless of whether this is actually the last page or 20 pages after the last page, then I have no problems having my system do the same, and everything would be OK with me.

Thank you for your consideration,
Elli



>________________________________
> From: Arnaud Le Hors <lehors@us.ibm.com>
>To: Elli Schwarz <eliezer_schwarz@yahoo.com> 
>Cc: "public-ldp@w3.org" <public-ldp@w3.org> 
>Sent: Friday, June 7, 2013 11:41 AM
>Subject: 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 
>
> 
>
>
>