Issue-14 Resolution: ascending or descending sort, with optional collations
authorJohn Arwe
Sat, 15 Jun 2013 12:00:47 -0400
changeset 126 e4ae46fd5294
parent 125 24853c53dae0
child 128 71da6619b0b8
Issue-14 Resolution: ascending or descending sort, with optional collations
ldp.html
ldp.ttl
--- a/ldp.html	Thu Jun 13 14:30:38 2013 -0400
+++ b/ldp.html	Sat Jun 15 12:00:47 2013 -0400
@@ -929,18 +929,25 @@
 		constructs like Seq and List for expressing order.
 	</p>
 	<p>
-		Order only becomes important for LDPC servers when containers are
+		Order becomes more important for LDPC servers when containers are
 		paginated. If the server does not respect ordering when constructing
-		pages, the client is forced to retrieve all pages before
-		sorting the members, which would defeat the purpose of pagination. In
-		cases where ordering is important, an LDPC server exposes all the
-		members on a page with a higher sort order than all members on the
-		previous page and lower sort order than all the members on the next
-		page. The LDPC specification provides a predicate - <code>ldp:containerSortPredicates</code>
-		- that the server may use to communicate to the client which
-		predicates were used for page ordering. Multiple predicate values may
-		have been used for sorting, so the value of this predicate is an
-		ordered list.
+		pages, the client would be forced to retrieve all pages before
+		sorting the members, which would defeat the purpose of pagination. 
+		In cases where ordering is important, an LDPC server exposes all the
+		members on a page with the proper sort order with relation to all 
+		members on the next and previous pages.
+		When the sort is ascending, all the members on a current page have a 
+		higher sort order than all members on the previous page and 
+		lower sort order than all the members on the next page. 
+		When the sort is descending, the opposite order is used. 
+		Since more than one value may be used to sort members, 
+		the LDPC specification allows servers to assert the ordered list
+		of sort criteria used to sort the members, using the 
+		<code>ldp:containerSortCriteria</code> relation.
+		Each member of the ordered list exposes one <code>ldp:containerSortCriterion</code>, 
+		consisting of a <code>ldp:containerSortPredicate</code>, 
+		<code>ldp:containerSortPredicate</code>, and 
+		optionally a <code>ldp:containerSortCollation</code>.
 	</p>
 	<p>Here is an example container described
 		previously, with representation for ordering of the assets:</p>
@@ -959,7 +966,12 @@
 &lt;?firstPage&gt;
    a ldp:Page;
    ldp:pageOf &lt;&gt;;
-   ldp:containerSortPredicates (o:value).
+   ldp:ContainerSortCriteria (#SortValueAscending).
+
+&lt;#SortValueAscending&gt;
+   a ldp:ContainerSortCriterion;
+   ldp:containerSortOrder ldp:ascendingOrder;
+   ldp:containerSortPredicate o:value.
 
 &lt;http://example.org/netWorth/nw1&gt;
    a o:NetWorth;
@@ -975,9 +987,9 @@
    a o:RealEstateHolding;
    o:value 300000.</pre>
 		<p>
-			As you can see by the addition of the <code>ldp:containerSortPredicates</code> 
+			As you can see by the addition of the <code>ldp:ContainerSortCriteria</code> 
 			predicate, the <code>o:value</code> predicate is used
-			to define the ordering of the results.  It is up to the domain model
+			to order the page members in ascending order.  It is up to the domain model
 			and server to determine the appropriate predicate to indicate the
 			resource’s order within a page, and up to the client receiving this 
 			representation to use that order in whatever way is appropriate, for 
@@ -1139,22 +1151,78 @@
 	</div>	
 	
 	<div id="ldpc-5_3_7" class="rule">5.3.7 LDPC servers MAY represent the members of a paged LDPC in a sequential
-		order.  The order MUST be specified using the <code>ldp:containerSortPredicates</code>
-		predicate whose subject is that of the page and object is a list of
-		LDPC ordinal predicates.  Ordering is only ascending. The only
-		ordinal predicate literal data types supported are those as defined
-		by SPARQL SELECT’s ORDER BY clause [[!SPARQL-QUERY]].
-		
-			<div class="ldp-issue-closed">
+		order.  If the server does so, it MUST be specify the order using a triple 
+		whose subject is the page URI, 
+		whose predicate is <code>ldp:containerSortCriteria</code>, 
+		and whose object is a <code>rdf:List</code> of
+		<code>ldp:containerSortCriterion</code> resources.  
+		The resulting order MUST be as defined by SPARQL SELECT’s ORDER BY clause 
+		[[!SPARQL-QUERY]].
+		Sorting criteria MUST be the same for all pages of a representation; if
+		the criteria were allowed to vary, the ordering among members of a container
+		across pages would be undefined. 
+		The first list entry provides the primary
+		sorting criterion, any second entry provides a secondary criterion used to order members considered
+		equal according to the primary criterion, and so on.
+		See section <a href="#ldpc-ordering">5.1.4 Ordering</a> for
+		an example.
+	</div>
+	
+	<div id="ldpc-5_3_8" class="rule">5.3.8 LDPC page representations 
+		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
+		in every <code>ldp:containerSortCriterion</code> list entry, 
+		a triple
+		whose subject is the sort criterion identifier, 
+		whose predicate is <code>ldp:containerSortPredicate</code> 
+		and whose object is 
+		the predicate whose value is used to order members within the page.
+		The only predicate data types whose behavior LDP constrains are those defined
+		by SPARQL SELECT’s ORDER BY clause [[!SPARQL-QUERY]].  Other data types
+		can be used, but LDP
+		assigns no meaning to them and interoperability will be limited.
+	</div>
+	
+	<div id="ldpc-5_3_9" class="rule">5.3.9 LDPC page representations 
+		ordered using <code>ldp:containerSortCriteria</code> MUST contain, 
+		in every <code>ldp:containerSortCriterion</code> list entry, 
+		a triple
+		whose subject is the sort criterion identifier, 
+		whose predicate is <code>ldp:containerSortOrder</code> 
+		and whose object describes the order used.  LDP defines two values,
+		<code>ldp:ascending</code> and <code>ldp:descending</code>, for use
+		as the object of this triple.  Other values can be used, but LDP
+		assigns no meaning to them and interoperability will be limited.
+	</div>
+
+	<div id="ldpc-5_3_10" class="rule">5.3.10 LDPC page representations 
+		ordered using <code>ldp:containerSortCriteria</code> MAY contain, 
+		in any <code>ldp:containerSortCriterion</code> list entry,
+		a triple
+		whose subject is the sort criterion identifier, 
+		whose predicate is <code>ldp:containerSortCollation</code> 
+		and whose object identifies the collation used.  LDP defines no values for use
+		as the object of this triple.  Any value can be used, but LDP
+		assigns no meaning to them and interoperability will be limited.
+		When the <code>ldp:containerSortCollation</code> triple is absent and the 
+		ordering values are strings or simple literals [[!SPARQL-QUERY]], the
+		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
+		[[!SPARQL-QUERY]] using two-argument <code>fn:compare</code>, that is, the implementation's 
+		default collation.
+		When the <code>ldp:containerSortCollation</code> triple is present and the 
+		ordering values are strings or simple literals [[!SPARQL-QUERY]], the
+		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
+		[[!SPARQL-QUERY]] using three-argument <code>fn:compare</code>, that is, the 
+		specified collation.
+		When the <code>ldp:containerSortCollation</code> triple is present for other
+		types of comparisons, LDP assigns no meaning to it.
+	</div>
+
+	<div class="ldp-issue-pending">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/14">ISSUE-14</a></div>
-	Include clarifications about ordering in LDPC representations
-	</div>
-	</div>
-	<div id="ldpc-5_3_7_1" class="rule">5.3.7.1 The object of <code>ldp:containerSortPredicates</code>,
-		the predicate used to indicate ordering, MUST NOT change between
-		subsequent pages. If it does, ordering among members of a container
-		across pages is undefined. See section <a href="#ldpc-ordering">5.1.4 Ordering</a> for
-		additional details.
+	Include clarifications about ordering in LDPC representations.
+	Do we need to say anything about strings in 5.3.8?
+	The ReSpec SPARQL QUERY link is http://www.w3.org/TR/rdf-sparql-query/ , which has highlighted text
+	referring readers to SPARQL 1.1.  Which normative reference do we want?
 	</div>
 </section>
 
@@ -1366,6 +1434,7 @@
 <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130701/">Third Public Working Draft</a></em></blockquote>
 -->
 <ul>
+	<li>2013-06-15 - ISSUE-14 End of 5.3 + example rewritten for ascending/descending sorts with optional collation (JA)</li>
 	<li>2013-06-13 - ISSUE-54 New 5.4.8.1 to set base URI on create for relative URI resolution (SS)</li>
 	<li>2013-06-10 - ISSUE-74 4.4.2 require 428 Condition Required status code when appropriate; SS adding 6585 to biblio (JA)</li>
 	<li>2013-06-05 - ISSUE-64 Remove ?non-member-properties; 5.1.2, 5.3.2, 5.5.2 (JA)</li>
@@ -1445,6 +1514,7 @@
 <p>Other than LDP <a href="http://www.w3.org/2012/ldp/track/actions">open actions</a> and <a href="http://www.w3.org/2012/ldp/track/issues">issues</a>, included here are transient tasks and notes
 editors use.  They have not meaning in final product of a published working draft and will be removed prior to publishing.</p>
 <ul>
+	<li>5.1.4 ordering example  - add example with >1 predicate, and collation sorting</li>
 	<li>Insert some additional examples</li>
 	<li>4.1.2: "the" subject ?= Request-URI  ... not always (hash URIs)
 	</li>
--- a/ldp.ttl	Thu Jun 13 14:30:38 2013 -0400
+++ b/ldp.ttl	Sat Jun 15 12:00:47 2013 -0400
@@ -35,15 +35,63 @@
 	rdfs:isDefinedBy :;
 	rdfs:label "Container".
 	
-:containerSortPredicates
+:containerSortCriteria
  	a rdf:Property;
-	rdfs:comment "List of predicates that indicate the ascending order of the members in a page.";
+	rdfs:comment "Link to the list of sorting criteria used by the server in a representation.";
 	vs:term_status "unstable";
 	rdfs:domain :Page;
 	rdfs:isDefinedBy :;
-	rdfs:label "containerSortPredicates";
+	rdfs:label "containerSortCriteria";
 	rdfs:range rdf:List.
 	
+:ContainerSortCriterion
+ 	a rdf:Class;
+	rdfs:comment "Element in the list of container sorting criteria used by the server in a representation.";
+	vs:term_status "unstable";
+	rdfs:label "ContainerSortCriterion";
+	rdfs:isDefinedBy :.
+	
+:containerSortPredicate
+ 	a rdf:Property;
+	rdfs:comment "Predicate used to determine the order of the members in a page.";
+	vs:term_status "unstable";
+	rdfs:domain :ContainerSortCriterion;
+	rdfs:isDefinedBy :;
+	rdfs:label "containerSortPredicate";
+	rdfs:range rdf:Property.
+	
+:containerSortOrder
+ 	a rdf:Property;
+	rdfs:comment "The ascending/descending/etc order used to order the members in a page.";
+	vs:term_status "unstable";
+	rdfs:domain :ContainerSortCriterion;
+	rdfs:isDefinedBy :;
+	rdfs:label "containerSortOrder";
+	rdfs:range rdf:Resource.
+	
+:containerSortCollation
+ 	a rdf:Property;
+	rdfs:comment "The collation used to order the members in a page when comparing strings.";
+	vs:term_status "unstable";
+	rdfs:domain :ContainerSortCriterion;
+	rdfs:isDefinedBy :;
+	rdfs:label "containerSortCollation";
+	rdfs:range rdf:Property.
+	
+:ascending
+ 	a rdf:Resource;		# individual
+	rdfs:comment "Ascending order.";
+	vs:term_status "unstable";
+	rdfs:isDefinedBy :;
+	rdfs:label "ascending".
+	
+:descending
+ 	a rdf:Resource;		# individual
+	rdfs:comment "Descending order.";
+	vs:term_status "unstable";
+	rdfs:isDefinedBy :;
+	rdfs:label "descending".
+	
 :membershipPredicate
 	a rdf:Property;
 	rdfs:comment "Indicates which predicate of the container should be used to determine the membership.";