RE: Why the collection?

On Tuesday, March 10, 2015 9:08 AM, Andrew Hacking wrote:
> On 10 Mar 2015 08:34, "Markus Lanthaler" wrote:
>> On Sat, 7 Mar 2015 22:45:36, Andrew Hacking wrote:
[...]
>>>>> If you take the time to read all of the prior threads on collections
>>>>> and paging
>>>>
>>>> looking at the threads of this year, #1 and #3 largest are about
>>>> paging+collections:
>>>>
>>>> http://m.whats-your.name/address/org/w/w3/public-hydra/2015/?c=999&set=page
>>>>
>>>> will go do that, but LIMIT and OFFSET are definitely crucial
>>>>
>>>> maybe missed a memo about them being axed?
>>>
>>> Yep it was brushed aside when the original simple serial page based access
>>> proposal was reinstated 'as the discussion has got off track'.
>>
>> For the moment, I would prefer to focus on the simplest possible design, yes
>>
>>> That's fine, its a deliberate choice of the Hydra core authors to not
>>> address the use cases and scenarios that need solving for modern apps.
>>
>> ... you can implement all the uses cases you mentioned (infinite
>> scrolling) with this design AFAICT. If not, why not?
> 
> 1. RANDOM ACCESS TO COLLECTION MEMBERS BASED ON ORDINAL POSITION IN
> THE ORDERED SET.

I do understand that you want that but not why. What's the use case behind it? Why do you need to jump to an arbitrary position in a collection if you don't know what items will be there? Can't you just preload pages?


> 2. DYNAMIC RESPONSE/PAGE SIZE (AKA LIMIT) BASED ON VARIOUS FACTORS
> LIKE VIEWPORT SIZE/ORIENTATION, MEMORY PRESSURE, LATENCY.

OK.. that sounds reasonable but something like a Prefer header might be able to address this better. Will have to think more about this.


> 3. RETURNING RELATED RESOURCES IN RESPONSE PAYLOADS TO AVOID 1+N
> QUERIES.

The server is free to do so. I also don't think this is specifically related to collections.


>>>> http://m.whats-your.name/address/org/w/w3/public-hydra/2015/?set=grep&q=offset
>>>>
>>>> right off am seeing offset=10. ugh.. ive no idea how big my collections are..
>>>
>>> The original proposal uses integers for pages and page sizes. Offset and
>>> limit would similarly also be expressed as integers. Offset representing
>>> the ordinal position in the collection and limit being the limit on the
>>> number of items to return. It would be reasonable to return the total count
>>> in the collection meta data or a range limit in the template. I asked about
>>> how to express ranged values for templates but it seems that's also an open
>>> issue that has another naive proposal.
>>
>> Collaboration is much more efficient and fruitful if concrete
>> proposals are being made than calling designs other people came up
>> naïve without giving concrete reasons.
> 
> I believe I have said why the template/range proposal is naive above,
> which reiterates an observation stated previously.

We haven't even started discussing it. Furthermore, there's a related standardization effort going on at W3C whose outcomes we might be able to leverage (RDF Data Shapes WG).


>>>> Datetimes, strings, URIs, Integers could all be offsets
>>>>
>>>> LIMIT is what, Bytes of representation-size? resources? triples?
>>>
>>> No see explanation above.
>>
>> But you see where this is going, right? People will have quite
>> different requirements when it comes to offsets and limits. Relying
>> on integers alone is an oversimplification that will leave a lot of
>> potential users in the rain.
> 
> I disagree for the following reasons.
> 
> I interpret the notion of a collection which supports pages actually
> being mathematically described as an ordered set.  Your paged design
> implicitly requires an ordered set for the paging to be stable.  It
> makes sense at a fundamental level to be able to index/address
> pages/members in an ordered set by ordinal, not by some other
> property.

It's the same as the difference between linked lists and arrays. AFAICT linked lists are still actively used. That doesn't mean that arrays aren't needed. We just decided to start with the linked list model as it is in many regards much simpler. We *might* add support for other forms of collections in the future. Concrete proposals speed up discussions considerably. So, if you feel strongly about this I'd suggest you to sketch out a design and document it in our Wiki or in a GitHub issue.


> If you want a collection ordered on favoriteCat then that would be
> specified in the collection definition and members of that collection
> would be ordered and grouped into pages or accessible randomly via
> offset/limit using the natural order of the favoriteCat data type.
> Rach member has an ordinal position within the set.  If you want a
> collection ordered on different things then each of those collections
> are all distinct representations with their own stable ordering that
> supports navigation using page links or offset via ordinal.

Understood.


--
Markus Lanthaler
@markuslanthaler

Received on Friday, 13 March 2015 17:44:53 UTC