- From: Ruben Verborgh <ruben.verborgh@ugent.be>
- Date: Tue, 15 Apr 2014 20:12:22 +0200
- To: Gregg Kellogg <gregg@greggkellogg.net>
- Cc: public-hydra@w3.org, Markus Lanthaler <markus.lanthaler@gmx.net>
>> I want to say that <http://data.linkeddatafragments.org/dbpedia> >> is the first page of the dataset <http://data.linkeddatafragments.org/dbpedia#dataset>. > > Wouldn't that be something like <http://data.linkeddatafragments.org/dbpedia#page1>? No; pages look like (when the next version will be deployed): - http://data.linkeddatafragments.org/dbpedia - http://data.linkeddatafragments.org/dbpedia?page=2 - http://data.linkeddatafragments.org/dbpedia?page=3 An equivalent URL for the first page would be - http://data.linkeddatafragments.org/dbpedia?page=1 > I think you're right about expressing the relationship this way. When asking for a Collection which needs to be paged, a server could return a Collection with the firstPage/nextPage/etc. properties but without schema:member and return a status 206 "Partial Content". Or, at the server's choice, simply redirect to the first page of the collection, although in this case, that page may also need to contain information about the Collection which it is part of, as there would be no other way to retrieve it. (206 has unfortunate semantics, as it really refers to byte ranges and requires a Range header). To complicate matters, I had originally this idea: the entire dataset is <http://data.linkeddatafragments.org/dbpedia>; but the representation at this URL only contains the triples in the first page. In other words, the representations of - http://data.linkeddatafragments.org/dbpedia and - http://data.linkeddatafragments.org/dbpedia?page=1 would be the same, even though the first identifies the entire dataset and the second only identifies the first page. But #dataset for the first sound simpler. > Removing firstPage/lastPage from each page has caching benefits, as when a new page is added, it doesn't invalidate previously generated page serializations. Unfortunately, adding totalItems does. I would love that Hydra has two properties for this: - totalItems, which is an approximation of the number of items - exactTotalItems, which is a subproperty of totalItems and has exact count That would still be okay for aching. In any case, totalItems is always an approximation for me. > Perhaps changing this to say that a PagedCollection is a subclass of Collection and represents a fragment (or page) of that Collection related as described above. I would be fine with that! > I like this direction quite a bit, and think we should update the spec to discuss the relationship between Collection and PagedCollection in such a way. +1 > I think sorting of members in either a Collection of PagedCollection is something that needs to be discussed further in any case. I briefly discussed that with Markus in Amsterdam; my suggestion was to stay away from expressing sorting in the main vocabulary. There's just too many variations. I agree that it should be specified on the page though. Best, Ruben
Received on Tuesday, 15 April 2014 18:12:56 UTC