--- a/ldp-ucr.html Fri Aug 23 11:55:12 2013 +0100
+++ b/ldp-ucr.html Fri Aug 23 12:14:12 2013 +0100
@@ -731,8 +731,8 @@
<li><a>NF1.1</a>: Provide "access guidance" (affordances) from user story, <a>Maintaining Social Contact Information</a>.</li>
</ul>
- <section>
- <h3 id="scen-create_container">Primary scenario: create a container</h3>
+ <section id="s1.1">
+ <h3>Primary scenario: create a container</h3>
<p>
Create a new container resource within the LDP server. In <a>Services Supporting the Process of Science</a>,
<a
@@ -760,8 +760,8 @@
</pre>
</section>
- <section>
- <h3 id="scen-create_a_nested_container">Alternative scenario: create a nested container</h3>
+ <section id="s1.2">
+ <h3>Alternative scenario: create a nested container</h3>
<p>
The motivation for nested containers comes from the <a>System and Software Development Tool Integration</a> user story. The
OSLC Change Management vocabulary allows bug reports to have
@@ -787,7 +787,7 @@
oslc_cm:attachment :attachment324, :attachment251.
</pre>
</section>
- <section>
+ <section id="s1.3">
<h3>Alternative scenario: Delete a container</h3>
If a container can be deleted, it seems natural that any contained resources and nested containers should also be deleted.
</section>
@@ -809,19 +809,19 @@
</p>
<ul>
<li><a>NF2.1</a>: Non-duplication of resources: "Eliminate multiple
- copies", representing resources in a single place (from <a>Maintaining Social Contact Information</a>).
+ copies", representing resources in a single place from <a>Maintaining Social Contact Information</a>.
</li>
<li><a>NF2.2</a>: Distribution of resources: Linked data "may be stored on
- separate servers" (from <a>Maintaining Social Contact Information</a>).
+ separate servers" from <a>Maintaining Social Contact Information</a>.
</li>
<li><a>NF2.3</a>: Consistent, global naming: Resources should be "linked to
consistently, ... instead of maintaining various identifiers in
- different formats" (from <a>Keeping Track of Personal and Business Relationships</a>).
+ different formats" from <a>Keeping Track of Personal and Business Relationships</a>.
</li>
</ul>
- <section>
- <h3 id="scen-create_resource">Primary scenario: create resource</h3>
+ <section id="s2.1">
+ <h3>Primary scenario: create resource</h3>
<p>
Resources begin life by being created within a container. From
user story, <a>Maintaining Social Contact Information</a>, It should be
@@ -865,8 +865,8 @@
</pre>
</section>
- <section>
- <h3 id="scen-delete_resource">Alternative scenario: delete resource</h3>
+ <section id="s2.2">
+ <h3>Alternative scenario: delete resource</h3>
<p>
Delete a resource and all it's properties. If the resource resides
within a container it will be removed from that container, however
@@ -880,8 +880,8 @@
</p>
</section>
- <section>
- <h3 id="scen-moving_contained_resources">Alternative scenario: moving contained resources</h3>
+ <section id="s2.3">
+ <h3>Alternative scenario: moving contained resources</h3>
<p>
Resources may have value beyond the life of their membership
in a container. This implies methods to add references to revise
@@ -907,14 +907,14 @@
they are being applied to the correct version.</p>
<ul>
<li><a>NF3.1</a>: Use standard vocabularies as appropriate to enable a
- "common understanding of the resource" (from <a>Maintaining Social Contact Information</a>).
+ "common understanding of the resource" from <a>Maintaining Social Contact Information</a>.
</li>
- <li><a>NF3.2</a>: A "scalable linking model is key" (from <a>Municipality Operational Monitoring</a>).
+ <li><a>NF3.2</a>: A "scalable linking model is key" from <a>Municipality Operational Monitoring</a>.
</li>
</ul>
- <section>
- <h3 id="scen-fetch">Primary scenario</h3>
+ <section id="s3.1">
+ <h3>Primary scenario</h3>
<p>
The user story <a
href="#story-project_data"
@@ -964,9 +964,8 @@
</pre>
</section>
- <section>
- <h3 id="scen-alt_non-document_resource">Alternative scenario: retrieve
- description of a non-document resource</h3>
+ <section id="s3.2">
+ <h3>Alternative scenario: retrieve description of a non-document resource</h3>
<p>In many cases, the things that are of interest are not
always the things that are resolvable. The example below
demonstrates how a FOAF profile may be used to distinguish between
@@ -999,12 +998,12 @@
</p>
<ul>
<li><a>NF4.1</a>: Unrestricted vocabulary: It should be possible be "able
- to add ... application-specific data" to resources (from <a>Maintaining Social Contact Information</a>).
+ to add ... application-specific data" to resources from <a>Maintaining Social Contact Information</a>.
</li>
</ul>
- <section>
- <h3 id="scen-update_enrichment">Primary scenario: enrichment</h3>
+ <section id="s4.1">
+ <h3>Primary scenario: enrichment</h3>
<p>
This relates to user story <a>Metadata Enrichment in Broadcasting</a> and is based on the <a
href="http://www.bbc.co.uk/ontologies/sport/"
@@ -1047,8 +1046,8 @@
</pre>
</section>
- <section>
- <h3 id="scen-alt_selective_update">Alternative scenario: selective
+ <section id="s4.2">
+ <h3>Alternative scenario: selective
update of a resource</h3>
<p>
This relates to user story <a>Data Catalogs</a>, based on the <a href="http://vocab.deri.ie/dcat"
@@ -1108,8 +1107,8 @@
unchanged.
</p>
- <section>
- <h3 id="scen-primary_has_changed">Primary scenario</h3>
+ <section id="s5.1">
+ <h3>Primary scenario</h3>
<p>
Based on the user story, <a>Constrained Devices and Networks</a>, an LDP server could be configured to
act as a proxy for a CoAP [[COAP]] based <a
@@ -1172,16 +1171,16 @@
</p>
<ul>
<li><a>NF6.1</a>: Resource descriptions are a "mix of simple data and
- collections" (from <a>Keeping Track of Personal and Business Relationships</a>).
+ collections" from <a>Keeping Track of Personal and Business Relationships</a>.
</li>
<li><a>NF6.2</a>: Relative URIs: It should be possible to "ship payloads of
RDF" for a collection as a whole without breaking internal links
- (from <a>Constrained Devices and Networks</a>).
+ from <a>Constrained Devices and Networks</a>.
</li>
</ul>
- <section>
- <h3 id="scen-add_a_resource_to_a_collection">Primary scenario: add a resource
+ <section id="s6.1">
+ <h3>Primary scenario: add a resource
to a collection</h3>
<p>
This example is from <a>Library Linked Data</a> and LLD-UC [[LLD-UC]], specifically <a
@@ -1208,8 +1207,8 @@
</pre>
</section>
- <section>
- <h3 id="scen-add_a_resource_to_multiple_collections">Alternative scenario: add a
+ <section id="s6.2">
+ <h3>Alternative scenario: add a
resource to multiple collections</h3>
<p>
Logically, a resource should not be owned by more than one
@@ -1253,9 +1252,8 @@
be able to read a collection, or item-level description that
excludes the container membership.</p>
- <section>
- <h3 id="scen-retrieve_collection-level_description">Primary scenario: retrieve
- collection-level description</h3>
+ <section id="s7.1">
+ <h3>Primary scenario: retrieve collection-level description</h3>
<p>
This scenario, based on <a>Library Linked Data</a>, uses the Dublin Core Metadata Initiative <a
href="http://dublincore.org/groups/collections/collection-application-profile/"
@@ -1283,9 +1281,8 @@
</pre>
</section>
- <section>
- <h3 id="scen-retrieve_item-level_description_of_a_collection">Alternative scenario: retrieve
- item-level description of a collection</h3>
+ <section id="s7.2">
+ <h3>Alternative scenario: retrieve item-level description of a collection</h3>
<p>
This use case scenario, also based on <a>Library Linked Data</a>,
focuses on obtaining an item-level description of the resources
@@ -1334,13 +1331,13 @@
<li>The next-page URL should be treated as opaque.</li>
</ul>
- <section>
- <h3 id="scen-access_media_resources">Primary scenario: large numbers of contacts</h3>
+ <section id="s8.1">
+ <h3>Primary scenario: Pagination</h3>
<p>In user story, <a>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.</p>
-<p>In this example the response to the first request includes a reference to the <i>next</i> resource in an ordered collection of resources. For the purposes of the example, we make use of the <i>next</i> property defined by the <a href="http://www.w3.org/1999/xhtml/vocab/">XHTML Metainformation Vocabulary</a>. There should be no presumption that the LDP specification will recommend the use of this vocabulary to support this use case.</p>
+<p>In this example the response to the first request includes a reference to the <i>next</i> resource in an ordered collection of resources. For the purposes of the example, we make use of the <i>next</i> property defined by the <a href="http://www.w3.org/1999/xhtml/vocab/">XHTML Metainformation Vocabulary</a>. There is no presumption that the LDP specification will recommend the use of this vocabulary.</p>
<pre class='example'>
@prefix : <http://example.com/people/>.
@prefix xhv: <http://www.w3.org/1999/xhtml/vocab#>.
@@ -1372,11 +1369,10 @@
to containers that accept them. Media resources may be updated and
removed during the lifecycle of the container.</p>
- <section>
- <h3 id="scen-access_media_resources">Primary scenario: access media
- resources</h3>
+ <section id="s9.1">
+ <h3>Primary scenario: access media resources</h3>
<p>
- From the User Story <a>Sharing Binary Resources and Metadata</a> it should be possible to
+ From the user story <a>Sharing Binary Resources and Metadata</a> it should be possible to
easily add non-RDF resources to containers that accept them.
Clients submit a non-RDF representation to a container in a media
type accepted by that container. The container creates a URI to
@@ -1402,9 +1398,8 @@
</pre>
</section>
- <section>
- <h3 id="scen-media_attachments">Alternative scenario:
- media-resource attachments</h3>
+ <section id="s9.2">
+ <h3>Alternative scenario: media-resource attachments</h3>
<p>
A resource may have multiple <i>renditions</i>; the idea that you
can have a PDF and a JPEG representing the same thing. A user is
@@ -1472,6 +1467,9 @@
<dt><dfn>F7.2</dfn>:</dt>
<dd>The system shall provide the ability to retrieve an item-level description of a composition or aggregation, from <a>UC7</a>.
</dd>
+ <dt><dfn>F8.1</dfn></dt>
+ <dd>The system shall provide the ability to retrieve a paginated description of a composition or aggregation, from <a>UC8</a>.
+ </dd>
<dt><dfn>F9.1</dfn>:</dt>
<dd>The system shall provide the ability to store and access media resources, from <a>UC9</a>
</dd>