--- 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 @@
<?firstPage>
a ldp:Page;
ldp:pageOf <>;
- ldp:containerSortPredicates (o:value).
+ ldp:ContainerSortCriteria (#SortValueAscending).
+
+<#SortValueAscending>
+ a ldp:ContainerSortCriterion;
+ ldp:containerSortOrder ldp:ascendingOrder;
+ ldp:containerSortPredicate o:value.
<http://example.org/netWorth/nw1>
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>