Trying to close ISSUE-14

Dear all,

This is an intent to close ISSUE-14 with a concrete proposal.

Focusing on how servers expose the sort order of a response, a server 
should allow a client to know:
.- According to which properties are the members sorted
.- For each property, the ascending or descending ordering

I can see scenarios where multiple properties and multiple ordering are 
used; e.g., I want to sort bugs according to their creation date 
(descending) and their priority (ascending).

The concrete proposal is the following:

An LDPC server can indicate to a client the ordering of members in a 
container page using an ldp:containerOrder property. This property has 
as range a list of resources with two properties:
.- ldp:containerSortPredicate, which defines the property used for sorting
.- ldp:containerSortOrder, which defines the ordering (ascending or 
descending) and is optional

Here is the spec example worked to include this proposal:

# The following is the ordered representation of
@prefix dcterms: <>.
@prefix ldp: <>.
@prefix o: <>.

     a ldp:Container;
     dcterms:title "The assets of JohnZSmith";
     ldp:membershipSubject <>;
     ldp:membershipPredicate o:asset.

     a ldp:Page;
     ldp:pageOf <>;
       ( [ldp:containerSortPredicate o:first. ]
         [ldp:containerSortPredicate o:second;
          ldp:containerSortOrder ldp:descending . ] ).

     a o:NetWorth;
     o:asset <>, <>, 

     a o:Stock;
     o:first 100.00;
     o:second 5.
     a o:Cash;
     o:first 50.00;
     o:second 17.
     a o:RealEstateHolding;
     o:first 300000.00;
     o:second 1355.

If the server wants to expose simple, it could just do:

<> ldp:containerOrder ( 
[ldp:containerSortPredicate o:first] ).

In summary, when a client asks for a paginated representation is because 
it needs to sequentially process the members of a container. It doesn't 
have any way of asking for a specific order, but the server already 
defines it in some way.

The point is that if the client doesn't know in which order the server 
is sorting members, it doesn't know the correct sequence to process 
(e.g., for visualization) them correctly. So, even if the client cannot 
specify ordering, it is useful for it to know the ordering details.

This proposal achieves the same goal as Richard's one of explicitly 
stating the ordered list of members. From my point of view both can be 
valid and both require clients and servers to agree on the meaning of 
how sort order is exposed.

For closing issue 14, this one is enough for me and simple to apply, 
since it builds upon the existing content in the specification.

Kind regards,


Dr. Raúl García Castro

Ontology Engineering Group
Departamento de Inteligencia Artificial
Universidad Politécnica de Madrid
Campus de Montegancedo, s/n - Boadilla del Monte - 28660 Madrid
Phone: +34 91 336 36 70 - Fax: +34 91 352 48 19

Received on Tuesday, 2 April 2013 08:51:27 UTC