Re: Paging with SPARQL CONSTRUCT implementations

Well, I think there's a couple of things going on here.

> ... 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.

I think you have a false dichotomy here.  The triples you show above is 
exactly what I meant in my original reply when I said

> 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. 

"marking it as the last page" == adding the Page triples you showed.
It gives every client exactly one way to detect "last page"; no gratuitous 
variability (waves to Raul ;-) ).


> 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? 

As a generic LDP client who knows nothing (zero) about your server's URL 
construction rules, I either got that p=55 URL from a ldp:nextPage triple 
object (this discussion) or "somewhere else".  In the latter case, tell me 
where it came from and I'll you whether or not I think LDP constrains the 
answer.  In the former case, I expect exactly what LDP prescribes, and 
since it's a different resource there's very little in the way of 
MUST/MUSTNOT-constraints coming from LDP.  404/410 is perfectly allowable 
(not especially reasonable for the case you started with, but allowable in 
general).

If you tell me your client knows anything about the server's URI 
construction rules, you're outside of LDP already so you can't look to LDP 
for answers.


Best Regards, John

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