Re: Call for consensus for the pagination design (ISSUE-42)

Hi,

Am 22.10.2015 um 13:20 schrieb Dietrich Schulten:
> But this poses a question. Currently we have only the page number to
> qualify the current view. Somehow I want to be able to recognize that
> I am back at the initial page. Can the initial page be No.  0, with
> positive and negative page numbers? Should the PartialCollectionView
> have an optional title which could give a human readable string like
> 'Today' , 'Yesterday' , 'Tomorrow' or so - or maybe even a predicate
> to say exactly which range I am looking at? The latter gets
> complicated fast ;)
>
>> To get to know whether you are on the first, page, why not just look at/
>> compare with the "first" link?
> Do you mean the initial view received or the first view in the series of
> views that together form the collection?
I mean the first view in the series of views.
The "hydra:first" link would point you to it.
The client would not need to understand the numbering scheme of the pages.
If the client would need to understand that page 0 means a value of 0 to 
some query param,
it would incur a subset of a querying specification and as outlined in 
my last mail I would stay away from that.
I know you already agreed that Hydra is not supposed to define this, I 
just wanted to make it clear.

>
> I would have expected hydra:first to be the first view in the series,
> but following Elf, the @id of the collection can point to any page in
> the series, as the server chooses. In that case looking at hydra:first
> won't tell me if I am in the initial view.
>
> I just realized that there is no hydra:pageNo where we could say that
> the initial page is always no. 0 :-)
Indeed that never existed.
It might make sense in some scenarios but in others it's not applicable,
e.g. if your collection has a "streamy" character and there is no such 
thing like a start and an end.

>
> We can postpone this question, it is not something that speaks against
> the hydra:view concept, especially if we do say that the client must not
> make assumptions which view it will receive initially.
yes.
>
>
>> Why not provide the title as dct:label or rdfs:label?
> I'd prefer hydra:title:
>
>      {
>        "@id": "hydra:title",
>        "@type": "rdf:Property",
>        "comment": "A title, often used along with a description.",
>        "label": "title",
>        "range": "xsd:string",
>        "subPropertyOf": [
>          "rdfs:label"
>        ],
>        "status": "testing"
>      }
>
> But this has nothing to do with the view construct - I can already add
> hydra:title there if I want to, that's enough for me.
>
>> I can well understand the latter problem you describe, it would be very
>> nice to make the client more aware of the semantics behind the paging
>> scheme
>> so that it can freely choose it according to it's own needs. This would
>> be very useful if a client
>> is looking only for data in a certain time frame for example.
>> The problem with this is that Hydra should not become an API querying
>> vocab I think;
> absolutely not. So many variations, and really orthogonal to Hydra Core.
>
>
> but this would effectively happen if we only start with a
>> single predicate like this
>> (ok, there is freetextQuery but this is very generic and for me a
>> compromise to have a very common concept in the vocab before there are
>> established alternatives).
>> Some approaches that can do a better job:
>>
>> - TPF
>> - OData  (not sure whether there is an RDF based vocab yet)
>> - SPARQL
> - OpenSearch. One could already add the IANA relation type 'search' to
> the collection and point to an Opensearch description document. Also has
> a scheme to allow clients to request a custom page.
Interesting. rels again. Some people also proposed to use rels for 
pagination/ views.
That would raise the question why we use rels here.
Maybe we need a generic construct to specify any rel.
Then people could just use them and sprinkle them on HATEOUS controls at 
will.
>
> How to integrate with such approaches in a Hydra service might be an
> issue for public-hydra-contrib later.
>
>> But we all know the issues associated with the latter two at least.
>>
> I don't :) Care to give me a pointer?

OData is not really a SemWeb standard. There is no RDF vocab to my 
knowledge.
SPARQL suffers from availability issues which is one of the reasons 
Ruben cam up with TPF [1].
>
> Best regards,
> Dietrich
>
>
>

[1] http://sw.deri.org/~aidanh/docs/epmonitorISWC.pdf

Received on Tuesday, 27 October 2015 09:22:30 UTC