RE: request for verification: paging in TPF

On 30 Okt 2015 at 00:05, Ruben Verborgh wrote:
>>   The page MUST contain a non-empty subset of data of the corresponding
>>   Triple Pattern Fragment
>> Why the MUST there? Wouldn't a SHOULD suffice? Think of cases where the
>> underlying data changes. What should happen in that case? 404 or empty
page?
> 
> Indeed, the MUST is wrong.
> The purpose of this statement was to avoid that clients unnecessarily
follow "next" links.
> What I really meant was:
> 
>     Any page other than the last page MUST NOT be empty.
> Would this make sense?

What would break if it would be empty? Nothing AFAICT. It would just become
less efficient. RFC2119 defines MUST NOT as

   This phrase, or the phrase "SHALL NOT", mean that the
   definition is an absolute prohibition of the specification.

I think that's to strong in this case. SHOULD NOT is a much better match IMO

   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.


>> This sounds exactly like what hydra:view was designed for. But I would
first
>> like to ask your for a simple example to ensure that we are on the same
page.
> 
> I'll continue the example from the gist:

[replaced with the corrected one]
On 30 Okt 2015 at 00:07, Ruben Verborgh wrote:
> Sorry, I got my example wrong. This should be:
> 
> <http://fragments.dbpedia.org/2015/en#dataset> a void:Dataset,
hydra:Collection;
>     void:subset
> <http://fragments.dbpedia.org/2015/en?subject=http%3A%2F%2Fdbpedia.org%2F
> resource %2FNikola_Tesla&predicate=&object=>.
> <http://fragments.dbpedia.org/2015/en?subject=http%3A%2F%2Fdbpedia.org%2F
> resource %2FNikola_Tesla&predicate=&object=>
>    hydra:view
> <http://fragments.dbpedia.org/2015/en?subject=http%3A%2F%2Fdbpedia.org%2F
> resource %2FNikola_Tesla&predicate=&object=&page=2>.
>
> Let me translate in English:
> - The dataset has the TPF as subset.
> - The TPF has the page as view.

Let me condense that even more to make it clear:

  <#dataset> a void:Dataset, hydra:Collection;
    void:subset <?subject=...Tesla> .

  <?subject=...Tesla> hydra:view <?subject=...Tesla&page=2> .

This seems fine to me. <?subject=...Tesla> is also a void:Dataset,
hydra:Collection. You need that to communicate the total number of items in
that subset, right? 


> Can I already use hydra:view?

Yes.


>> I guess adding an example directly to the spec would be good as well.
> 
> Yes; especially the "metadata controls" section, which is now
example-based, should:
> - first be explained without an example
> - then be exemplified together with all features
> 
>> Btw. have you considered that "fragment IRI" could be misinterpreted as
"IRI fragment"?
> 
> Not yet; we should probably talk about "IRI of the fragment".

Sounds clearer to me.


>> Seems to be inline but it's a bit hard to read a multi-page example.
> 
> Can I help?
> For instance, I could deploy a live instance somewhere.

I think having a super terse example in mabe 10 lines or so of Turtle would
clarify things.


>>> Current issue: hydra:itemsPerPage is gone. How to mitigate this?
>> 
>> Is it actually needed in this case?
> 
> a) Not needed for simple usage, but I want to replicate the human view,
> which has this.

Machines are quite good at counting :-P


> b) Needed for some of the existing TPF query algorithms
> that do predictions based on page size. (Those could also count the
> number of items per page, but not in all cases.)

That's a good point. Let's discuss it as part of the "Client-initiated
pagination (ISSUE-102)" thread. Feel free to add examples/explanations of
the use cases to the Wiki

  https://www.w3.org/community/hydra/wiki/Client-initiated_pagination


Cheers,
Markus


--
Markus Lanthaler
@markuslanthaler

Received on Sunday, 1 November 2015 15:41:56 UTC