Standardize client iterator about linkeddataeventstreams HOT 3 OPEN

To make this work efficiently, I think we would need a way to communicate to the client that the view uses a unidirectional linked list as pagination model between fragments.
If this is the case, the client can keep the last consumed fragment uri and the timestamp of the last processed member as state, and can continue from there on?

from linkeddataeventstreams.

Not convinced a unidirectional fragmentation is needed: the relations however do have to use the ldes:timestampPath as tree:path.

from linkeddataeventstreams.

If we go with this idea of 'profiles', that allow the client to discover how a view can be consumed, we could define the minimal relations that should be present in said profile?
e.g. tree:GreaterThanRelation is required in each fragment?
Having someting with even more simplistic semantics like nextOrderOfArrivalFragment would be nice to have, as in theory a fragment could contain multiple GreaterThanRelation relations?
If we want to keep the itterator logic as simple as possible, being able to have a explicit order beween fragments becomes important.

from linkeddataeventstreams.