Re: ACTION-43 Draft use case for ordering

hello steve.

On 2013-03-25 6:58 , "Steve Speicher" <sspeiche@gmail.com> wrote:
>Bug tracking tools often have thousands of bugs reported.  Making a
>request on these is often filtered down based on the state or
>project/timeline associated with, but often ordered based on some
>defined ordering: last modified, highest priority, status, creator,
>etc.  Since RDF is unordered and the response may be split across
>pages, there needs to be a way to indicate what the order is.
>Otherwise, the client will have to discover the intended order by
>other means and also if the response was split across pages responses,
>it would be preferred to have member resources on the current page
>based on ordering predicates that occur before those found on the next
>page.

this is an excellent use case and a very popular one, too. adding to this,
it often is equally important to be able to choose what to order on
(unless there is some implicit assumption somewhere, such as many feeds
being ordered by update time). going further, you might also want to
filter things, but that becomes pretty tough because of the potential
complexity of the filter expressions. neither ordering nor filters should
be based on the back-end processing of ordering/filtering requests in RDF;
they should simply identify exposed capabilities of the service, which
then can map them to whatever implementation it is based on. RDF-based LDP
services then internally map them to SPARQL, SQL-based LDP services
internally map them to SQL, and so forth.

regardless of how far we go down the line of ordering, exposing order
keys, and exposing filtering capabilities, all of this should be based on
the same general mechanics that we are going to use for the paging
mechanism: if these are fixed URIs, we should expose them as typed links
to fixed URIs; if these are parametrized URIs, we should expose them as
URI templates. and as for paging, we then would expect LDP to standardize
the relevant concepts (how to identify URI template variables for sort
order, order keys, or filter expressions).

cheers,

dret.

Received on Monday, 25 March 2013 17:35:38 UTC