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

Hi,

Am 22.10.2015 um 07:17 schrieb Thomas Hoppe:
> Hi Dietrich,
> 
> Am 21.10.2015 um 19:00 schrieb Dietrich Schulten:
>>
>>
>>
>> Proposal: "the client must not make assumptions which partial view it
>> receives as initial response, it has to rely on available navigation
>> controls".
>>
> +1
>>
>> 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 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 :-)

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.


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

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?

Best regards,
Dietrich

Received on Thursday, 22 October 2015 11:21:29 UTC