Added pagination use-case
authorsteve.battle <steve.battle@sysemia.co.uk>
Mon, 17 Jun 2013 17:07:40 +0100
changeset 127 98c62ed47e80
parent 119 28a06040491c
child 128 71da6619b0b8
Added pagination use-case
ldp-ucr.html
--- a/ldp-ucr.html	Tue Jun 04 19:10:09 2013 +0200
+++ b/ldp-ucr.html	Mon Jun 17 17:07:40 2013 +0100
@@ -1484,6 +1484,26 @@
 	</section>
 	
 	<section>
+		<h2 id="uc-pagination">Use case: Retrieve a large resource description in multiple parts</h2>
+
+This use case addresses a problem with the “resource-centric” approach to interacting with RDF data. The problem is that some resources participate in a very large number of triples, and therefore a “resource-centric” granularity leads to resource descriptions that are too large to be practically processed in a single HTTP request. This use-case applies to all resources, not just containers.
+
+		<ul>
+			<li>It's not really the resource description that's being paginated, but the values of a particular property.</li>
+			<li>The server is responsible for pagination, and may decide how large the pages are.</li>
+			<li>Pagination should apply symmetrically to both <emph>incoming</emph> and <emph>outgoing</emph> properties.</li>
+			<li>The next-page URL should be opaque.</li>
+		</ul>
+		
+		<section>
+		<h3 id="scen-access_media_resources">Primary scenario: large numbers of contacts</h3>
+
+In user-story, <a href="#story-social" title="Social Contacts">Maintaining Social Contact Information</a>, it is not uncommon for users to have a very large number of contacts.
+This leads to a very large resource description, especially if some basic information about the contacts is included as well. The size of this representation may be so large that retrieval in a single HTTP request is impractical. 
+		</section>
+	</section>
+	
+	<section>
 	<h2 id="uc-manage_media_resources">Use Case: Manage media resources</h2>
 	<p>It should be possible to easily add non-RDF media resources
 		to containers that accept them. Media resources may be updated and