generated version
authorYves Lafon <>
Thu, 24 Jan 2013 22:51:44 +0100
changeset 44 ae2c3bbfadeb
parent 43 6d2805d7c6bf
child 45 eb4c45eb9bd2
generated version
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/TR/ldp-ucr.html	Thu Jan 24 22:51:44 2013 +0100
@@ -0,0 +1,1743 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" prefix="bibo:" typeof="bibo:Document">
+    <title>Linked Data Platform Use Cases and Requirements</title>
+    <meta http-equiv="Content-Type" content="text/html;charset=utf-8">
+    <!-- 
+      === NOTA BENE ===
+      For the three scripts below, if your spec resides on dev.w3 you can check them
+      out in the same tree and use relative links so that they'll work offline,
+     -->
+    <style type="text/css">
+    	div.rule {padding-top: 1em;}
+    	div.ldp-issue {
+	    	border-color: #E05252;
+			background: #FBE9E9;
+			padding: 0.5em;
+			margin: 1em 0;
+			position: relative;
+			clear: both;
+			border-left-width: .5em;
+			border-left-style: solid;
+    	}
+    	div.ldp-issue-title {
+    	    color: #E05252;
+    	    padding-right: 1em;
+            min-width: 7.5em;
+    	}
+    </style>
+  <style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon -
+ *****************************************************************/
+/* --- INLINES --- */
+em.rfc2119 { 
+    text-transform:     lowercase;
+    font-variant:       small-caps;
+    font-style:         normal;
+    color:              #900;
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+    border: none;
+dfn {
+    font-weight:    bold;
+a.internalDFN {
+    color:  inherit;
+    border-bottom:  1px solid #99c;
+    text-decoration:    none;
+a.externalDFN {
+    color:  inherit;
+    border-bottom:  1px dotted #ccc;
+    text-decoration:    none;
+a.bibref {
+    text-decoration:    none;
+cite .bibref {
+    font-style: normal;
+code {
+    color:  #ff4500;
+/* --- --- */
+ol.algorithm { counter-reset:numsection; list-style-type: none; }
+ol.algorithm li { margin: 0.5em 0; }
+ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; }
+/* --- TOC --- */
+.toc a, .tof a {
+    text-decoration:    none;
+a .secno, a .figno {
+    color:  #000;
+ul.tof, ol.tof {
+    list-style: none outside none;
+.caption {
+    margin-top: 0.5em;
+    font-style:   italic;
+/* --- TABLE --- */
+table.simple {
+    border-spacing: 0;
+    border-collapse:    collapse;
+    border-bottom:  3px solid #005a9c;
+.simple th {
+    background: #005a9c;
+    color:  #fff;
+    padding:    3px 5px;
+    text-align: left;
+.simple th[scope="row"] {
+    background: inherit;
+    color:  inherit;
+    border-top: 1px solid #ddd;
+.simple td {
+    padding:    3px 10px;
+    border-top: 1px solid #ddd;
+.simple tr:nth-child(even) {
+    background: #f0f6ff;
+/* --- DL --- */
+.section dd > p:first-child {
+    margin-top: 0;
+.section dd > p:last-child {
+    margin-bottom: 0;
+.section dd {
+    margin-bottom:  1em;
+.section dl.attrs dd, .section dl.eldef dd {
+    margin-bottom:  0;
+</style><style>/* --- EXAMPLES --- */
+div.example-title {
+    min-width: 7.5em;
+    color: #b9ab2d;
+div.example-title span {
+    text-transform: uppercase;   
+aside.example, div.example, div.illegal-example {
+    padding: 0.5em;
+    margin: 1em 0;
+    position: relative;
+    clear: both;
+div.illegal-example { color: red }
+div.illegal-example p { color: black }
+aside.example, div.example {
+    padding: .5em;
+    border-left-width: .5em;
+    border-left-style: solid;
+    border-color: #e0cb52;
+    background: #fcfaee;    
+aside.example div.example {
+    border-left-width: .1em;
+    border-color: #999;
+    background: #fff;
+aside.example div.example div.example-title {
+    color: #999;
+</style><link href="" rel="stylesheet"><!--[if lt IE 9]><script src=''></script><![endif]--></head>
+<body><div class="head">
+  <p>
+      <a href=""><img src="" alt="W3C" height="48" width="72"></a>
+  </p>
+  <h1 class="title" id="title">Linked Data Platform Use Cases and Requirements</h1>
+  <h2 id="w3c-working-draft-29-january-2013"><abbr title="World Wide Web Consortium">W3C</abbr> Working Draft 29 January 2013</h2>
+  <dl>
+      <dt>This version:</dt>
+      <dd><a href=""></a></dd>
+      <dt>Latest published version:</dt>
+      <dd><a href=""></a></dd>
+      <dt>Latest editor's draft:</dt>
+      <dd><a href=""></a></dd>
+      <dt>Previous version:</dt>
+      <dd><a href=""></a></dd>
+    <dt>Editors:</dt>
+    <dd rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" content="Steve Battle" href="">Steve Battle</a>, <a rel="foaf:workplaceHomepage" href="">Sysemia Limited</a></span>
+<dd rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a rel="foaf:homepage" property="foaf:name" content="Steve Speicher" href="">Steve Speicher</a>, <a rel="foaf:workplaceHomepage" href="">IBM Corporation</a></span>
+  </dl>
+      <p class="copyright">
+        <a href="">Copyright</a> © 
+        2013
+        <a href=""><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> 
+        (<a href=""><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+        <a href=""><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+        <a href="">Keio</a>), All Rights Reserved.
+        <abbr title="World Wide Web Consortium">W3C</abbr> <a href="">liability</a>,
+        <a href="">trademark</a> and
+        <a href="">document use</a> rules apply.
+      </p>
+  <hr>
+<section rel="bibo:chapter" resource="#abstract" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2>Abstract</h2><p>
+A set of user stories, use cases, scenarios and requirements that motivate a simple 
+read-write Linked Data architecture, based on HTTP access to web 
+resources that describe their state using RDF.
+</p></section><section rel="bibo:chapter" resource="#sotd" typeof="bibo:Chapter" id="sotd" class="introductory"><h2>Status of This Document</h2>
+        <p>
+          <em>This section describes the status of this document at the time of its publication. Other
+          documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision
+          of this technical report can be found in the <a href=""><abbr title="World Wide Web Consortium">W3C</abbr> technical reports
+          index</a> at</em>
+        </p>
+        <p>
+          This document was published by the <a href="">Linked Data Platform Working Group</a> as a <a href="">First Public Working Draft</a>.
+            This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.
+          If you wish to make comments regarding this document, please send them to 
+          <a href="mailto:[email protected]">[email protected]</a> 
+          (<a href="mailto:[email protected]?subject=subscribe">subscribe</a>,
+          <a href="">archives</a>).
+        All comments are welcome.
+          </p><p>
+            Publication as a Working Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership.
+            This is a draft document and may be updated, replaced or obsoleted by other documents at 
+            any time. It is inappropriate to cite this document as other than work in progress.
+          </p>
+        <p>
+            This document was produced by a group operating under the 
+            <a href="">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+              <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="" rel="disclosure">public list of any patent disclosures</a> 
+            made in connection with the deliverables of the group; that page also includes instructions for 
+            disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains
+            <a href="">Essential Claim(s)</a> must disclose the
+            information in accordance with <a href="">section
+            6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+        </p>
+</section><section id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a class="tocxref" href="#scope-and-motivation"><span class="secno">1. </span>Scope and Motivation</a></li><li class="tocline"><a class="tocxref" href="#organization-of-this-document"><span class="secno">2. </span>Organization of this Document</a></li><li class="tocline"><a class="tocxref" href="#user-stories"><span class="secno">3. </span>User Stories</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#maintaining-social-contact-information"><span class="secno">3.1 </span>Maintaining Social Contact Information</a></li><li class="tocline"><a class="tocxref" href="#keeping-track-of-personal-and-business-relationships"><span class="secno">3.2 </span>Keeping Track of Personal and
+			Business Relationships</a></li><li class="tocline"><a class="tocxref" href="#system-and-software-development-tool-integration"><span class="secno">3.3 </span>System and Software Development
+			Tool Integration</a></li><li class="tocline"><a class="tocxref" href="#library-linked-data"><span class="secno">3.4 </span>Library Linked Data</a></li><li class="tocline"><a class="tocxref" href="#municipality-operational-monitoring"><span class="secno">3.5 </span>Municipality Operational
+			Monitoring</a></li><li class="tocline"><a class="tocxref" href="#healthcare"><span class="secno">3.6 </span>Healthcare</a></li><li class="tocline"><a class="tocxref" href="#metadata-enrichment-in-broadcasting"><span class="secno">3.7 </span>Metadata Enrichment in Broadcasting</a></li><li class="tocline"><a class="tocxref" href="#aggregation-and-mashups-of-infrastructure-data"><span class="secno">3.8 </span>Aggregation and Mashups of Infrastructure Data</a></li><li class="tocline"><a class="tocxref" href="#sharing-payload-of-rdf-data-among-low-end-devices"><span class="secno">3.9 </span>Sharing payload of RDF data among low-end devices</a></li><li class="tocline"><a class="tocxref" href="#sharing-binary-resources-and-metadata"><span class="secno">3.10 </span>Sharing Binary Resources and Metadata</a></li><li class="tocline"><a class="tocxref" href="#data-catalogs"><span class="secno">3.11 </span>Data Catalogs</a></li><li class="tocline"><a class="tocxref" href="#constrained-devices-and-networks"><span class="secno">3.12 </span>Constrained Devices and Networks</a></li><li class="tocline"><a class="tocxref" href="#services-supporting-the-process-of-science"><span class="secno">3.13 </span>Services Supporting the Process
+			of Science</a></li><li class="tocline"><a class="tocxref" href="#project-membership-information-information-evolution"><span class="secno">3.14 </span>Project Membership Information: Information Evolution</a></li><li class="tocline"><a class="tocxref" href="#cloud-infrastructure-management"><span class="secno">3.15 </span>Cloud Infrastructure Management</a></li></ul></li><li class="tocline"><a class="tocxref" href="#use-cases"><span class="secno">4. </span>Use Cases</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#use-case-manage-containers"><span class="secno">4.1 </span>Use Case: Manage containers</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#primary-scenario-create-container"><span class="secno">4.1.1 </span>Primary scenario: create
+			container</a></li><li class="tocline"><a class="tocxref" href="#alternative-scenario-create-a-nested-container"><span class="secno">4.1.2 </span>Alternative scenario: create a
+			nested container</a></li></ul></li><li class="tocline"><a class="tocxref" href="#use-case-manage-resources"><span class="secno">4.2 </span>Use Case: Manage resources</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#primary-scenario-create-resource"><span class="secno">4.2.1 </span>Primary scenario: create resource</a></li><li class="tocline"><a class="tocxref" href="#alternative-scenario-delete-resource"><span class="secno">4.2.2 </span>Alternative scenario: delete
+			resource</a></li><li class="tocline"><a class="tocxref" href="#alternative-scenario-moving-contained-resources"><span class="secno">4.2.3 </span>Alternative scenario: moving
+			contained resources</a></li></ul></li><li class="tocline"><a class="tocxref" href="#use-case-retrieve-resource-description"><span class="secno">4.3 </span>Use Case: Retrieve resource
+			description</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#primary-scenario"><span class="secno">4.3.1 </span>Primary scenario</a></li><li class="tocline"><a class="tocxref" href="#alternative-scenario-retrieve-description-of-a-non-document-resource"><span class="secno">4.3.2 </span>Alternative scenario: retrieve
+			description of a non-document resource</a></li></ul></li><li class="tocline"><a class="tocxref" href="#use-case-update-existing-resource"><span class="secno">4.4 </span>Use Case: Update existing resource</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#primary-scenario-enrichment"><span class="secno">4.4.1 </span>Primary scenario: enrichment</a></li><li class="tocline"><a class="tocxref" href="#alternative-scenario-selective-update-of-a-resource"><span class="secno">4.4.2 </span>Alternative scenario: selective
+			update of a resource</a></li></ul></li><li class="tocline"><a class="tocxref" href="#use-case-determine-if-a-resource-has-changed"><span class="secno">4.5 </span>Use Case: Determine if a resource has
+			changed</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#primary-scenario-1"><span class="secno">4.5.1 </span>Primary scenario</a></li></ul></li><li class="tocline"><a class="tocxref" href="#use-case-aggregate-resources"><span class="secno">4.6 </span>Use Case: Aggregate resources</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#primary-scenario-add-a-resource-to-a-collection"><span class="secno">4.6.1 </span>Primary scenario: add a resource
+			to a collection</a></li><li class="tocline"><a class="tocxref" href="#alternative-scenario-add-a-resource-to-multiple-collections"><span class="secno">4.6.2 </span>Alternative scenario: add a
+			resource to multiple collections</a></li></ul></li><li class="tocline"><a class="tocxref" href="#use-case-filter-resource-description"><span class="secno">4.7 </span>Use Case: Filter resource description</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#primary-scenario-retrieve-collection-level-description"><span class="secno">4.7.1 </span>Primary scenario: retrieve
+			collection-level description</a></li><li class="tocline"><a class="tocxref" href="#alternative-scenario-retrieve-item-level-description-of-a-collection"><span class="secno">4.7.2 </span>Alternative scenario: retrieve
+			item-level description of a collection</a></li></ul></li><li class="tocline"><a class="tocxref" href="#use-case-manage-media-resources"><span class="secno">4.8 </span>Use Case: Manage media resources</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#primary-scenario-access-media-resources"><span class="secno">4.8.1 </span>Primary scenario: access media
+			resources</a></li><li class="tocline"><a class="tocxref" href="#alternative-scenario-media-resource-attachments"><span class="secno">4.8.2 </span>Alternative scenario:
+			media-resource attachments</a></li></ul></li></ul></li><li class="tocline"><a class="tocxref" href="#requirements"><span class="secno">5. </span>Requirements</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#functional-requirements"><span class="secno">5.1 </span>Functional Requirements</a></li><li class="tocline"><a class="tocxref" href="#non-functional-requirements"><span class="secno">5.2 </span>Non-Functional Requirements</a></li></ul></li><li class="tocline"><a class="tocxref" href="#acknowledgements"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#history"><span class="secno">B. </span>Change History</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">C.1 </span>Informative references</a></li></ul></li></ul></section>
+<section rel="bibo:chapter" resource="#status" typeof="bibo:Chapter" id="status">
+<section id="scope-and-motivation" rel="bibo:chapter" resource="#scope" typeof="bibo:Chapter">
+<!--OddPage--><h2 id="scope"><span class="secno">1. </span>Scope and Motivation</h2>
+	<p>
+		Linked Data was defined by Tim Berners-Lee with the following
+		guidelines [<cite><a href="#bib-LINKED-DATA" class="bibref">LINKED-DATA</a></cite>]:
+	</p>
+	<ol>
+		<li>Use URIs as names for things</li>
+		<li>Use HTTP URIs so that people can look up those names</li>
+		<li>When someone looks up a URI, provide useful information,
+			using the standards (RDF*, SPARQL)</li>
+		<li>Include links to other URIs. so that they can discover
+			more things</li>
+	</ol>
+	<p>These four rules have proven very effective in guiding and
+		inspiring people to publish Linked Data on the web. The amount of
+		data, especially public data, available on the web has grown
+		rapidly, and an impressive number of extremely creative and useful
+		“mashups” have been created using this data as result.</p>
+	<p>There has been much less focus on the potential of Linked
+		Data as a model for managing data on the web - the majority of the
+		Application Programming Interfaces (APIs) available on the
+		Internet for creating and updating data follow a Remote Procedure
+		Call (RPC) model rather than a Linked Data model.</p>
+	<p>If Linked Data were just another model for doing something
+		that RPC models can already do, it would be of only marginal
+		interest. Interest in Linked Data arises from the fact that
+		applications with an interface defined using Linked Data can be
+		much more easily and seamlessly integrated with each other than
+		applications that offer an RPC interface. In many problem domains,
+		the most important problems and the greatest value are found not
+		in the implementation of new applications, but in the successful
+		integration of multiple applications into larger systems.</p>
+	<p>Some of the features that make Linked Data exceptionally
+		well suited for integration include:</p>
+	<ul>
+		<li>A single interface – defined by a common set of HTTP
+			methods – that is universally understood and is constant across
+			all applications. This is in contrast with the RPC architecture
+			where each application has a unique interface that has to be
+			learned and coded to.</li>
+		<li>A universal addressing scheme – provided by HTTP URLs –
+			for both identifying and accessing all “entities”. This is in
+			contrast with the RPC architecture where there is no uniform way
+			to either identify or access data.</li>
+		<li>A simple yet extensible data model – provided by RDF –
+			for describing data about a resource in a way which doesn’t
+			require prior knowledge of vocabulary being used.</li>
+	</ul>
+	<p>Experience implementing applications and integrating them
+		using Linked Data has shown very promising results, but has also
+		demonstrated that the original four rules defined by Tim
+		Berners-Lee for Linked Data are not sufficient to guide and
+		constrain a writable Linked Data API. As was the case with the
+		original four rules, the need generally is not for the invention
+		of fundamental new technologies, but rather for a series of
+		additional rules and patterns that guide and constrain the use of
+		existing technologies in the construction of a 
+		[<cite><a href="#bib-LINKED-DATA-PLATFORM" class="bibref">LINKED-DATA-PLATFORM</a></cite>] to achieve interoperability.</p>
+	<p>The following list illustrates a few of the issues that
+		require additional rules and patterns:</p>
+	<ul>
+		<li>What URLs do I post to in order to create new resources?
+		</li>
+		<li>How do I get lists of existing resources, and how do I
+			get basic information about them without having to access each
+			one?</li>
+		<li>How should I detect and deal with race conditions on
+			write?</li>
+		<li>What media-types/representations should I use?</li>
+		<li>What standard vocabularies should I use?</li>
+		<li>What primitive data types should I use?</li>
+	</ul>
+	<p>A good goal for the [<cite><a href="#bib-LINKED-DATA-PLATFORM" class="bibref">LINKED-DATA-PLATFORM</a></cite>] would be
+		to define a specification required to allow the definition of a
+		writable Linked Data API equivalent to the simple application APIs
+		that are often written on the web today using the Atom Publishing
+		Protocol (APP). APP shares some characteristics with Linked Data,
+		such as the use of HTTP and URLs. One difference is that Linked
+		Data relies on a flexible data model with RDF, which allows for
+		multiple representations.</p>
+<section id="organization-of-this-document" rel="bibo:chapter" resource="#org" typeof="bibo:Chapter">
+<!--OddPage--><h2 id="org"><span class="secno">2. </span>Organization of this Document</h2>
+ Use-cases are captured in a narrative style that describes a
+ behavior, or set of behaviors drawn from user-stories. They are embellished with concrete examples drawn 
+ from representative user-stories. The aim throughout has been to avoid details of protocol (specifically 
+ the HTTP protocol), and use of any specific vocabulary that might be introduced by the 
+ <abbr title="Linked Data Platform">LDP</abbr> specification.
+	<p>This document is organized as follows:</p>
+	<ul>
+		<li><b><a href="#userstories" title="User Stories">User Stories</a></b>
+			capture statements about system requirements written from a user
+			or application perspective. They are typically lightweight and
+			informal and can run from one line to a paragraph or two
+			(sometimes described as an 'epic') <a href="" class="external autonumber" title="" rel="nofollow">[2]</a>. Analysis of each user story will reveal a
+			number of (functional) use-cases and other non-functional
+			requirements. See Device
+				API Access Control Use Cases and Requirements [<cite><a href="#bib-DAP-REQS" class="bibref">DAP-REQS</a></cite>] for a good example
+			of user stories and their analysis.</li>
+	</ul>
+	<ul>
+		<li><b><a href="#use-cases" title="Use Cases">Use Cases</a></b> are
+			used to capture and model functional requirements. Use cases
+			describe the system’s behavior under various conditions <a href="" class="external autonumber" title="" rel="nofollow">[3]</a>,
+			cataloging who does what with the system, for what purpose, but
+			without concern for system design or implementation <a href="" class="external autonumber" title="" rel="nofollow">[4]</a>. Each use case is identified by a
+			reference number to aid cross-reference from other documentation;
+			use-case indexing in this document is based on rdb2rdf
+			use-cases [<cite><a href="#bib-RDB2RDF-UC" class="bibref">RDB2RDF-UC</a></cite>]. A variety of styles may be used to capture use-cases,
+			from a simple narrative to a structured description with actors,
+			pre/post conditions, and step-by-step behaviors as in POWDER:
+			Use Cases and Requirements [<cite><a href="#bib-POWDER-USE-CASES" class="bibref">POWDER-USE-CASES</a></cite>], and non-functional requirements
+			raised by the use-case. Use cases act like the hub of a wheel,
+			with spokes supporting requirements analysis, scenario-based
+			evaluation, testing, and integration with non-functional, or
+			quality requirements.</li>
+	</ul>
+	<ul>
+		<li><b>Scenarios</b> are more focused still, representing a
+			single instance of a use case in action. Scenarios may range from
+			lightweight narratives as seen in Use
+			cases and requirements for Media Fragments [<cite><a href="#bib-MEDIA-FRAGMENTS-REQS" class="bibref">MEDIA-FRAGMENTS-REQS</a></cite>], to being formally
+			modeled as interaction diagrams. Each use-case should include at
+			least a primary scenario, and possibly other alternative
+			scenarios.</li>
+	</ul>
+	<ul>
+		<li><b><a href="#reqs" title="Requirements">Requirements</a></b>
+			lists non-functional or quality requirements, and the use cases
+			they may be derived from. This approach is exemplified in the Use Cases and Requirements for the Data
+			Catalog Vocabulary [<cite><a href="#bib-DCAT-UCR" class="bibref">DCAT-UCR</a></cite>]. It also lists functional requirements that
+			stem from use-cases. It is also possible at this stage to
+			explicitly identify some use-cases as non-requirements.</li>
+	</ul>
+<section id="user-stories" rel="bibo:chapter" resource="#userstories" typeof="bibo:Chapter">
+<!--OddPage--><h2 id="userstories"><span class="secno">3. </span>User Stories</h2>
+	<section id="maintaining-social-contact-information" rel="bibo:chapter" resource="#story-social" typeof="bibo:Chapter">
+	<h3 id="story-social"><span class="secno">3.1 </span>Maintaining Social Contact Information</h3>
+	<p>Many of us have multiple email accounts that include
+		information about the people and organizations we interact with –
+		names, email addresses, telephone numbers, instant messenger
+		identities and so on. When someone’s email address or telephone
+		number changes (or they acquire a new one), our lives would be
+		much simpler if we could update that information in one spot and
+		all copies of it would automatically be updated. In other words,
+		those copies would all be linked to some definition of “the
+		contact.” There might also be good reasons (like off-line email
+		addressing) to maintain a local copy of the contact, but ideally
+		any copies would still be linked to some central “master.”</p>
+	<p>Agreeing on a format for “the contact” is not enough,
+		however. Even if all our email providers agreed on the format of a
+		contact, we would still need to use each provider’s custom
+		interface to update or replace the provider’s copy, or we would
+		have to agree on a way for each email provider to link to the
+		“master”. If we look outside our own personal interests, it would
+		be even more useful if the person or organization exposed their
+		own contact information so we could link to it.</p>
+	<p>
+		What would work in either case is a common understanding of the
+		resource, a few formats needed, and access guidance for these
+		resources. This would support how to acquire a link to a contact,
+		and how to use those links to interact with a contact (including <a href="#uc-retrieve_resource_description" title="">reading</a>,
+		<a href="#uc-update_existing" title="">updating</a>,
+		and <a href="#scen-delete_resource" title="">deleting</a>
+		it), as well as how to easily <a href="#scen-create_resource" title="">create a
+			new contact</a>, add it to my contacts, and when deleting a
+		contact, how it would be removed from my list of contacts. It
+		would also be good to be able to add some application-specific
+		data about my contacts that the original design didn’t consider.
+		Ideally we’d like to eliminate multiple copies of contacts, there
+		would be additional valuable information about my contacts that
+		may be stored on separate servers and need a simple way to link
+		this information back to the contacts. Regardless of whether a
+		contact collection is my own, shared by an organization, or all
+		contacts known to an email provider (or to a single email account
+		at an email provider), it would be nice if they all worked pretty
+		much the same way.
+	</p>
+	</section>
+	<section id="keeping-track-of-personal-and-business-relationships" rel="bibo:chapter" resource="#story-tracking_relationships" typeof="bibo:Chapter">
+	<h3 id="story-tracking_relationships"><span class="secno">3.2 </span>Keeping Track of Personal and
+			Business Relationships</h3>
+	<p>In our daily lives, we deal with many different
+		organizations in many different relationships, and they each have
+		data about us. However, it is unlikely that any one organization
+		has all the information about us. Each of them typically gives us
+		access to the information (at least some of it), many through
+		websites where we are uniquely identified by some string – an
+		account number, user ID, and so on. We have to use their
+		applications to interact with the data about us, however, and we
+		have to use their identifier(s) for us. If we want to build any
+		semblance of a holistic picture of ourselves (more accurately,
+		collect all the data about us that they externalize), we as humans
+		must use their custom applications to find the data, copy it, and
+		organize it to suit our needs.</p>
+	<p>
+		Would it not be simpler if at least the Web-addressable portion of
+		that data could be linked to consistently, so that instead of
+		maintaining various identifiers in different formats and instead
+		of having to manually supply those identifiers to each one’s
+		corresponding custom application, we could essentially build a set
+		of bookmarks to it all? When we want to <a href="#uc-retrieve_resource_description" title="">examine</a>
+		or <a href="#uc-update_existing" title="">change</a>
+		their contents, would it not be simpler if there were a single
+		consistent application interface that they all supported? Of
+		course it would.
+	</p>
+	<p>
+		Our set of links would probably be a <a href="#uc-aggregate_resources" title="">simple collection</a>.
+		The information held by any single organization might be a mix of
+		simple data and <a href="#uc-aggregate_resources" title="">collections
+			of other data</a>, for example, a bank account balance and a
+		collection of historical transactions. Our bank might easily have
+		<a href="#scen-create_a_nested_container" title="">a collection of accounts for each member of its collection
+			of customers</a>.
+	</p>
+	</section>
+	<section id="system-and-software-development-tool-integration" rel="bibo:chapter" resource="#story-oslc" typeof="bibo:Chapter">
+	<h3 id="story-oslc"><span class="secno">3.3 </span>System and Software Development
+			Tool Integration</h3>
+	<p>System and software development tools typically come from a
+		diverse set of vendors and are built on various architectures and
+		technologies. These tools are purpose built to meet the needs for
+		a specific domain scenario (modeling, design, requirements and so
+		on.) Often tool vendors view integrations with other tools as a
+		necessary evil rather than providing additional value to their
+		end-users. Even more of an afterthought is how these tools’ data
+		-- such as people, projects, customer-reported problems and needs
+		-- integrate and relate to corporate and external applications
+		that manage data such as customers, business priorities and market
+		trends. The problem can be isolated by standardizing on a small
+		set of tools or a set of tools from a single vendor, but this
+		rarely occurs and if does it usually does so only within small
+		organizations. As these organizations grow both in size and
+		complexity, they have needs to work with outsourced development
+		and diverse internal other organizations with their own set of
+		tools and processes. There is a need for better support of more
+		complete business processes (system and software development
+		processes) that span the roles, tasks, and data addressed by
+		multiple tools. This demand has existed for many years, and the
+		tools vendor industry has tried several different architectural
+		approaches to address the problem. Here are a few:</p>
+	<ul>
+		<li>Implement an API for each application, and then, in each
+			application, implement “glue code” that exploits the APIs of
+			other applications to link them together.</li>
+		<li>Design a single database to store the data of multiple
+			applications, and implement each of the applications against this
+			database. In the software development tools business, these
+			databases are often called “repositories.”</li>
+		<li>Implement a central “hub” or “bus” that orchestrates the
+			broader business process by exploiting the APIs described
+			previously.</li>
+	</ul>
+	<p>
+		It is fair to say that although each of those approaches has its
+		adherents and can point to some successes, none of them is wholly
+		satisfactory. The use of Linked Data as an application integration
+		technology has a strong appeal <a href="" class="external text" title="" rel="nofollow">OSLC</a>.
+	</p>
+	</section>
+	<section id="library-linked-data" rel="bibo:chapter" resource="#story-lld" typeof="bibo:Chapter">
+	<h3 id="story-lld"><span class="secno">3.4 </span>Library Linked Data</h3>
+	<p>
+		The <abbr title="World Wide Web Consortium">W3C</abbr> Library Linked Data working group has a number of use
+		cases cited in their Use Case Report [<cite><a href="#bib-LLD-UC" class="bibref">LLD-UC</a></cite>]. These referenced use cases focus on the
+		need to extract and correlate library data from disparate sources.
+		Variants of these use cases that can provide consistent formats,
+		as well as ways to improve or update the data, would enable
+		simplified methods for both efficiently sharing this data as well
+		as producing incremental updates without the need for repeated
+		full extractions and import of data.
+	</p>
+	<p>The 'Digital Objects Cluster' contains a number of relevant
+		use-cases:</p>
+	<ul>
+		<li>Grouping: This should "Allow the end-users to define <a href="#uc-aggregate_resources" title="">groups of resources</a>
+			on the web that for some reason belong together. The relationship
+			that exists between the resources is often left unspecified. Some
+			of the resources in a group may not be under control of the
+			institution that defines the groups."
+		</li>
+	</ul>
+	<ul>
+		<li>Enrichment: "Enable end-users to <a href="#uc-update_existing" title="">link resources
+				together</a>."
+		</li>
+	</ul>
+	<ul>
+		<li>Browsing: "<a href="#uc-Filter_resource_description" title="">Support end-user browsing through groups</a> and
+			resources that belong to the groups."
+		</li>
+	</ul>
+	<ul>
+		<li>Re-use: "Users should have the capability to re-use all
+			or parts of a collection, with all or part of its metadata,
+			elsewhere on the linked Web."</li>
+	</ul>
+	<p>The 'Collections' cluster also contains a number of relevant
+		use-cases:</p>
+	<ul>
+		<li>Collection-level description: "Provide <a href="#uc-filter_resource_description" title="">metadata
+				pertaining to a collection as a whole</a>, in contrast to item-level
+			description."
+		</li>
+	</ul>
+	<ul>
+		<li>Collections discovery: "Enable innovative collection
+			discovery such as identification of nearest location of a
+			physical collection where a specific information resource is
+			found or mobile device applications ... based on collection-level
+			descriptions."</li>
+	</ul>
+	<ul>
+		<li>Community information services: Identify and classify
+			collections of special interest to the community.</li>
+	</ul>
+	</section>
+	<section id="municipality-operational-monitoring" rel="bibo:chapter" resource="#story-meter_monitoring" typeof="bibo:Chapter">
+	<h3 id="story-meter_monitoring"><span class="secno">3.5 </span>Municipality Operational
+			Monitoring</h3>
+	<p>
+		Across various cities, towns, counties, and various municipalities
+		there is a growing number of services managed and run by
+		municipalities that produce and consume a vast amount of
+		information. This information is used to help monitor services,
+		predict problems, and handle logistics. In order to effectively
+		and efficiently collect, produce, and analyze all this data, a
+		fundamental set of loosely coupled standard data sources are
+		needed. A simple, low-cost way to <a href="#uc-retrieve_resource_description" title="">expose
+			data</a> from the diverse set of monitored services is needed, one
+		that can easily integrate into the municipalities of other systems
+		that inspect and analyze the data. All these services have links
+		and dependencies on other data and services, so having a simple
+		and scalable linking model is key.
+	</p>
+	</section>
+	<section id="healthcare" rel="bibo:chapter" resource="#story-healthcare" typeof="bibo:Chapter">
+	<h3 id="story-healthcare"><span class="secno">3.6 </span>Healthcare</h3>
+	<p>For physicians to analyze, diagnose, and propose treatment
+		for patients requires a vast amount of complex, changing and
+		growing knowledge. This knowledge needs to come from a number of
+		sources, including physicians’ own subject knowledge, consultation
+		with their network of other healthcare professionals, public
+		health sources, food and drug regulators, and other repositories
+		of medical research and recommendations.</p>
+	<p>To diagnose a patient’s condition requires current data on
+		the patient’s medications and medical history. In addition, recent
+		pharmaceutical advisories about these medications are linked into
+		the patient’s data. If the patient experiences adverse affects
+		from medications, these physicians need to publish information
+		about this to an appropriate regulatory source. Other medical
+		professionals require access to both validated and emerging
+		effects of the medication. Similarly, if there are geographical
+		patterns around outbreaks that allow both the awareness of new
+		symptoms and treatments, this information needs to quickly reach a
+		very distributed and diverse set of medical information systems.
+		Also, reporting back to these regulatory agencies regarding new
+		occurrences of an outbreak, including additional details of
+		symptoms and causes, is critical in producing the most effective
+		treatment for future incidents.</p>
+	</section>	
+	<section id="metadata-enrichment-in-broadcasting" rel="bibo:chapter" resource="#story-media" typeof="bibo:Chapter">
+	<h3 id="story-media"><span class="secno">3.7 </span>Metadata Enrichment in Broadcasting</h3>
+	<p>
+		There are many different use cases when broadcasters show interest
+		in metadata <a href="#uc-pdate_existing" title="">
+			enrichment</a>:
+	</p>
+	<ul>
+		<li>enrich archive or news metadata by linking facts, events,
+			locations and personalities</li>
+		<li>enrich metadata generated by automatic extraction tools
+			such as person identification, etc.</li>
+		<li>enrich definitions of terms in classification schemes or
+			enumeration lists</li>
+	</ul>
+	<p>This comes in support of more effective information
+		management and data/content mining (if you can't find your
+		content, it's like you don't have it and must either recreate or
+		acquire it again, which is not financially effective).</p>
+	<p>However, there is a need for solutions facilitating linkage
+		to other data sources and taking care of the issues such as
+		discovery, automation, disambiguation, etc. Other important issues
+		that broadcasters would face are the editorial quality of the
+		linked data, its persistence, and usage rights.</p>
+	</section>
+	<section id="aggregation-and-mashups-of-infrastructure-data" rel="bibo:chapter" resource="#story-mashup" typeof="bibo:Chapter">
+	<h3 id="story-mashup"><span class="secno">3.8 </span>Aggregation and Mashups of Infrastructure Data</h3>
+	<p>
+		For infrastructure management (such as storage systems, virtual
+		machine environments, and similar IaaS and PaaS concepts), it is
+		important to provide an environment in which information from
+		different sources can be <a href="#uc-aggregate_resources" title="">aggregated</a>, <a href="#uc-filter_resource_description" title="">filtered</a>,
+		and visualized effectively. Specifically, the following use cases
+		need to be taken into account:
+	</p>
+	<ul>
+		<li>While some data sources are based on Linked Data, others
+			are not, and aggregation and mashups must work across these
+			different sources.</li>
+		<li>Consumers of the data sources and aggregated/filtered
+			data streams are not necessarily implementing Linked Data
+			themselves, they may be off-the-shelf components such as
+			dashboard frameworks for composing visualizations.</li>
+		<li>Simple versions of this scenario are pull-based, where
+			the data is requested from data sources. In more advanced
+			settings, without a major change in architecture it should be
+			possible to move to a push-based interaction model, where data
+			sources push notifications to subscribers, and data sources
+			provide different services that consumers can subscribe to (such
+			as "informational messages" or "critical alerts only").</li>
+	</ul>
+	<p>In this scenario, the important factors are to have
+		abstractions that allow easy aggregation and filtering, are
+		independent from the internal data model of the sources that are
+		being combined, and can be used for pull-based interactions as
+		well as for push-based interactions.</p>
+	</section>
+	<section id="sharing-payload-of-rdf-data-among-low-end-devices" rel="bibo:chapter" resource="#story-low-end_devices" typeof="bibo:Chapter">
+	<h3 id="story-low-end_devices"><span class="secno">3.9 </span>Sharing payload of RDF data among low-end devices</h3>
+	<p>
+		Several projects around the idea of <a href="" title="" rel="nofollow">downscaling
+			the Semantic Web</a> need to be able to ship payloads of RDF across
+		the nodes member of a given network. The transfers are done in a
+		constrained context in terms of bandwidth, scope of the local
+		semantics employed by the nodes and computing capabilities of the
+		nodes. In a P2P style, every node has the capability to act either
+		as a data consumer or a data provider, serving its own data or
+		acting as a relay to pass other's data along (typically in mesh
+		networks).
+	</p>
+	<p>The transfer of an arbitrary payload of RDF data could be
+		implemented through the container mechanism, adding and removing
+		sets of RDF triples to it. Currently, the 
+		"SemanticXO" project uses named graphs and the graph store protocol to
+		create/delete/copy graphs across the nodes but this (almost)
+		imposes the usage of a triple store. Unfortunately, triple stores
+		are rather demanding pieces of software that are not always usable
+		on limited hardware. Some generic REST-like interaction backed up
+		with a lightweight column store would be better approach.</p>
+	</section>
+	<section id="sharing-binary-resources-and-metadata" rel="bibo:chapter" resource="#story-binary_and_metadata" typeof="bibo:Chapter">
+	<h3 id="story-binary_and_metadata"><span class="secno">3.10 </span>Sharing Binary Resources and Metadata</h3>
+	<p>When publishing datasets about stars one may want to publish
+		links to the pictures in which those stars appear, and this may
+		well require publishing the pictures themselves. Vice versa: when
+		publishing a picture of space we need to know which telescope took
+		the picture, which part of the sky it was pointing at, what
+		filters were used, which identified stars are visible, who can
+		read it, who can write to it, ...</p>
+	<p>If Linked Data contains information about resources that are
+		most naturally expressed in non-RDF formats (be they binary such
+		as pictures or videos, or human readable documents in XML
+		formats), those non-RDF formats should be just as easy to publish
+		to the LinkedData server as the RDF relations that link those
+		resources up. A LinkedData server should therefore allow
+		publishing of non linked data resources too, and make it easy to
+		publish and edit metadata about those resources.</p>
+	<p>The resource comes in two parts - the image and information
+		about the image (which may be in the image file but is better kept external
+		to it as it's more general). The information about the image is
+		vital. It's a compound item of image data and other data (application 
+		metadata about the image) does are not distinguished from the
+		platform's point-of-view.</p>
+	</section>
+	<section id="data-catalogs" rel="bibo:chapter" resource="#story-data_catalogs" typeof="bibo:Chapter">
+	<h3 id="story-data_catalogs"><span class="secno">3.11 </span>Data Catalogs</h3>
+	<p>
+		The Asset Description Metadata Schema (<a href="" title="" rel="nofollow">ADMS</a>)
+		provides the data model to describe semantic asset repository
+		contents, but this leaves many open challenges when building a
+		federation of these repositories to serve the need of asset
+		reuse. These include accessing and querying individual
+		repositories and efficiently retrieving <a href="#uc-has_resource_changed" title="">
+			updated content</a> without having to retrieve the whole content.
+		Hence, we chose to build the integration solution capitalizing on
+		the Data Warehousing integration approach. This allows us to cope
+		with heterogeneity of sources technologies and to benefit from the
+		optimized performance it offers, given that individual
+		repositories do not usually change frequently. With Data
+		Warehousing, the federation requires one to:
+	</p>
+	<ul>
+		<li>understand the data, i.e. understand their semantic
+			descriptions, and other systems.</li>
+		<li>seamlessly exchange the semantic assets metadata from
+			different repositories</li>
+		<li>keep itself up-to-date.</li>
+	</ul>
+	<p>Repository owners can maintain de-referenceable URIs for
+		their repository description and contained assets in a Linked Data
+		compatible manner. ADMS provides the necessary data model to
+		enable meaningful exchange of data. However, this leaves the
+		challenge of efficient access to the data not fully addressed.</p>
+	<p>
+		Related: <a href="" title="" rel="nofollow">Data Catalog Schema and Protocol</a>
+	</p>
+	</section>
+	<section id="constrained-devices-and-networks" rel="bibo:chapter" resource="#story-constrained_devices" typeof="bibo:Chapter">
+	<h3 id="story-constrained_devices"><span class="secno">3.12 </span>Constrained Devices and Networks</h3>
+	<p>
+		Information coming from resource constrained devices in the Web of
+		Things (<a href="" title="" rel="nofollow">WoT</a>)
+		has been identified as a major driver in many domains, from smart
+		cities to environmental monitoring to real-time tracking. The
+		amount of information produced by these devices is growing
+		exponentially and needs to be accessed and integrated in a
+		systematic, standardized and cost efficient way. By using the same
+		standards as on the Web, integration with applications will be
+		simplified and higher-level interactions among resource
+		constrained devices, abstracting away heterogeneities, will become
+		possible. Up-coming IoT/WoT standards such as <a href="" title="" rel="nofollow">6LowPAN</a>
+		- IPv6 for resource constrained devices - and the Constrained
+		Application Protocol (<a href="" title="" rel="nofollow">CoAP</a>), which provides a downscaled version of
+		HTTP on top of UDP for the use on constrained devices, are already
+		at a mature stage. The next step now is to support RESTful
+		interfaces also on resource constrained devices, adhering to the
+		Linked Data principles. Due to the limited resources available,
+		both on the device and in the network (such as bandwidth, energy,
+		memory) a solution based on SPARQL Update is at the current point
+		in time considered not to be useful and/or feasible. An approach
+		based on the <a href="" title="" rel="nofollow">HTTP-CoAP Mapping</a> would enable constrained
+		devices to directly participate in a Linked Data-based
+		environment.
+	</p>
+	</section>
+	<section id="services-supporting-the-process-of-science" rel="bibo:chapter" resource="#story-process_of_science" typeof="bibo:Chapter">
+	<h3 id="story-process_of_science"><span class="secno">3.13 </span>Services Supporting the Process
+			of Science</h3>
+	<p>Many fields of science now include branches with in silico
+		data-intensive methods, e.g. bioinformatics, astronomy. To support
+		these new methods we look to move beyond the established platforms
+		provided by scientific workflow systems to capture, assist, and
+		preserve the complete lifecycle from record of the experiment,
+		through local trusted sharing, analysis, dissemination (including
+		publishing of experimental data "beyond the PDF"), and re-use.</p>
+	<ul>
+		<li><a href="#uc-aggregate_resources" title="">Aggregations</a>,
+			specifically <i>Research Objects (ROs)</i> that are exchanged
+			between services and clients bringing together workflows, data
+			sets, annotations, and provenance. We use an RDF model for this.
+			While some aggregated contents are encoded using RDF and an
+			increasing number are linked data sources, others are not; while
+			some are stored locally "within" the RO, others are remote (in
+			both cases this is often due to size of the resources or access
+			policies).</li>
+		<li>Services that are distributed and linked. Some may be
+			centralising for e.g. publication, others may be local, e.g. per
+			lab. We need lightweight services that can be simply and easily
+			integrated into and scale across the wide variety of softwares
+			and data used in science: we have adopted a RESTful approach
+			where possible.
+			<ul>
+				<li>Foundation services that collect and expose ROs for
+					storage, modification, exploration, and reuse.</li>
+				<li>Services that provide added-value to ROs such as
+					seamless import/export from scientific workflow systems,
+					automated stability evaluation, or recommendation (and
+					therefore interact with the foundation services to
+					retrieve/store/modify/ROs).</li>
+			</ul>
+		</li>
+	</ul>
+	<p>
+		seeAlso: <a href="" title="" rel="nofollow">Wf4Ever</a>
+	</p>
+	</section>
+	<section id="project-membership-information-information-evolution" rel="bibo:chapter" resource="#story-project_data" typeof="bibo:Chapter">
+	<h3 id="story-project_data"><span class="secno">3.14 </span>Project Membership Information: Information Evolution</h3>
+	<p>Information about people and projects changes as roles
+		change, as organisations change and as contact details change.
+		Finding the current state of a project is important in enabling
+		people to contact the right person in the right role. It can also
+		be useful to look back and see who was performing what role in the
+		past.</p>
+	<p>A use of a Linked Data Platform could be to give
+		responsibility for managing such information to the project team
+		itself, instead of requiring updates to be requested from a centralised
+		website administrator.</p>
+	<p>This could be achieved with:</p>
+	<ul>
+		<li>Resource descriptions for each person and project</li>
+		<li>A container resource to describe roles/membership in the
+			project.</li>
+	</ul>
+	<p>To retain the history of the project, the old version of a
+		resources, including container resources, should be retained so
+		there is a need to address both specific items and also have a
+		notion of "current".</p>
+	<p>Access to information has two aspects:</p>
+	<ul>
+		<li>Access to the "current" state, regardless of the version
+			of the resource description</li>
+		<li>Access to historical state, via access to a specific
+			version of the resource description</li>
+	</ul>
+	</section>
+	<section id="cloud-infrastructure-management" rel="bibo:chapter" resource="#story-cloud" typeof="bibo:Chapter">
+	<h3 id="story-cloud"><span class="secno">3.15 </span>Cloud Infrastructure Management</h3>
+	<p>Cloud operators offer API support to provide customers with
+		remote access for the management of Cloud infrastructure (IaaS).
+		Infrastructure consists of Systems, Computers, Networks, Discs,
+		etc. The overall structure can be seen as mostly hierarchical,
+		(Cloud contains Systems, Systems contain Machines, etc),
+		complemented with crossing links (e.g. multiple Machines connected
+		to a Network).</p>
+	<p>The IaaS scenario makes specific requirements on lifecycle
+		management and discovery, handling non-instant changes, history
+		capture and query:</p>
+	<ul>
+		<li>Many aspects of Cloud infrastructure have associated
+			lifecycle, e.g. a Computer can be transitioned between Running
+			and Shutdown. This should be manageable through the API, which
+			should include how a client discovers dynamic lifecycle options
+			and thus help steering through an application.</li>
+		<li>It is often the case that attaining a new lifecycle state
+			is not instantaneous. Clients require a universal mechanism for
+			monitoring such changes.</li>
+		<li>A facility to retrieve all events in the lifecycle of a
+			resource can be useful.</li>
+		<li>Query provides the means to interrogate the resources
+			behind the API, as well as finding new entry points into the
+			application.</li>
+	</ul>
+	<p>Infrastructure management may be viewed as the manipulation
+		of the underlying graph of resources.</p>
+	</section>
+<section id="use-cases" rel="bibo:chapter" resource="#usecases" typeof="bibo:Chapter">
+<!--OddPage--><h2 id="usecases"><span class="secno">4. </span>Use Cases</h2>
+	<p>The following use-cases are each derived from one or more of
+		the user-stories above. These use-cases are explored in detail
+		through the development of scenarios, each motivated by some key
+		aspect exemplified by a single user-story. The examples they
+		contain are included purely for illustrative purposes, and should
+		not be interpreted normatively.</p>
+	<section id="use-case-manage-containers" rel="bibo:chapter" resource="#uc-manage_containers" typeof="bibo:Chapter">
+	<h3 id="uc-manage_containers"><span class="secno">4.1 </span>Use Case: Manage containers</h3>
+	<p>
+		A number of user-stories introduce the idea of a <i>container</i>
+		as a mechanism for creating and managing resources within the
+		context of an application. Resources grouped together within the
+		same container would typically belong to the same application. A
+		container is identified by a URI so is a resource in its own
+		right. The properties of a container may also represent the <i>affordances</i>
+		of that container, enabling clients to determine what other
+		operations they can do on that container. These operations may
+		include descriptions of application specific services that can be
+		invoked by exchanging RDF documents.
+	</p>
+	<ul>
+		<li>Provide "access guidance for ... resources" (affordances)
+			(from user-story, <a href="#story-social" title="Social Contacts">Maintaining
+				Social Contact Information</a>).
+		</li>
+	</ul>
+	<section id="primary-scenario-create-container" rel="bibo:chapter" resource="#scen-create_container" typeof="bibo:Chapter">
+	<h4 id="scen-create_container"><span class="secno">4.1.1 </span>Primary scenario: create
+			container</h4>
+	<p>
+		Create a new container resource within the <abbr title="Linked Data Platform">LDP</abbr> server. In <a href="#story-process_of_science" title="">Services
+			supporting the process of science</a>, <a href="" title="" rel="nofollow">Research
+			Objects</a> are semantically rich aggregations of resources that
+		bring together data, methods and people in scientific
+		investigations. A basic workflow research object will be created
+		to aggegate <a href="" title="" rel="nofollow">scientific
+			workflows</a> and the artefacts that result from this workflow. The
+		research object begins life as an empty container into which
+		workflows, datasets, results and other data will be added
+		throughout the lifecycle of the project.
+	</p>
+	<div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example">@prefix ro:
[email protected] dct:
[email protected] ore:
+&lt;&gt; a ro:ResearchObject, ore:Aggregation ;
+    dct:created "2012-12-01"^^xsd:dateTime .</pre></div>
+	</section>
+	<section id="alternative-scenario-create-a-nested-container" rel="bibo:chapter" resource="#scen-create_a_nested_container" typeof="bibo:Chapter">
+	<h4 id="scen-create_a_nested_container"><span class="secno">4.1.2 </span>Alternative scenario: create a
+			nested container</h4>
+	<p>
+		The motivation for nested containers comes from the <a href="#story-oslc" title="Story Tool Integration">
+			System and Software Development Tool Integration</a> user-story. The
+		OSLC Change Management vocabulary allows bug reports to have
+		attachments referenced by the membership predicate
+		oslc_cm:attachment. The 'top-level-container' contains issues, and
+		each issue resource has its own container of attachment resources.
+	</p>
+	<div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example">@prefix dcterms: &lt;;.
[email protected] rdfs: &lt;;.
[email protected] oslc_cm: &lt;;.
[email protected] : &lt;;.
+:top-level-container rdfs:member :issue1234 .
+:issue1234 a oslc_cm:ChangeRequest;
+      dcterms:identifier "1234";
+      dcterms:type "a bug";
+      dcterms:related :issue1235 ;
+      oslc_cm:attachments :attachments123.
+:issue1235 a oslc_cm:ChangeRequest;
+      dcterms:title "a related bug".
+:attachments a oslc_cm:AttachmentList;
+      oslc_cm:attachment :attachment324, :attachment251.</pre></div>
+	</section>
+	</section>
+	<section id="use-case-manage-resources" rel="bibo:chapter" resource="#uc-manage_resources" typeof="bibo:Chapter">
+	<h3 id="uc-manage_resources"><span class="secno">4.2 </span>Use Case: Manage resources</h3>
+	<p>
+		This use-case addresses the managed lifecycle of a resource and is
+		concerned with resource <i>ownership</i>. The responsibility for
+		managing resources belongs with their container. For example, a
+		container may accept a request from a client to make a new
+		resource. This use-case focuses on creation and deletion of
+		resources in the context of a container, and the potential for
+		transfer of ownership by moving resources between containers. The
+		ownership of a resource should always be clear; no resource
+		managed in this way should ever be owned by more than one
+		container.
+	</p>
+	<p>
+		Once a new resource has been created it should be identified by a
+		URI. Clients may defer responsibility for establishing
+		dereferenceable URIs to the container of their data. The container
+		is a natural choice for the endpoint for this interface as it will
+		already have some application-specific knowledge about the
+		contained resources. While the server has ultimate control over
+		resource naming, some applications may require more control over
+		naming, perhaps to provide a more human-readable URI. An <abbr title="Linked Data Platform">LDP</abbr>
+		server could support something like the Atom
+			Publishing Protocol slug header to convey a user defined naming
+		'hint' [<cite><a href="#bib-RFC5023" class="bibref">RFC5023</a></cite>].
+	</p>
+	<ul>
+		<li>Non-duplication of resources: "Eliminate multiple
+			copies", representing resources in a single place (from <a href="#story-social" title="Story Social Informatinon">#Maintaining
+				Social Contact Information</a>).
+		</li>
+		<li>Distribution of resources: Linked data "may be stored on
+			separate servers" (from <a href="#story-social" title="Story Social Informatinon">#Maintaining
+				Social Contact Information</a>).
+		</li>
+		<li>Consistent, global naming: Resources should be "linked to
+			consistently, ... instead of maintaining various identifiers in
+			different formats" (from <a href="#story-tracking_relationships" title="Story Tracking Relationships">#Keeping Track of Personal and Business
+				Relationships</a>).
+		</li>
+	</ul>
+	<section id="primary-scenario-create-resource" rel="bibo:chapter" resource="#scen-create_resource" typeof="bibo:Chapter">
+	<h4 id="scen-create_resource"><span class="secno">4.2.1 </span>Primary scenario: create resource</h4>
+	<p>
+		Resources begin life by being created within a container. From
+		user-story, <a href="#story-social" title="Story Social Informatinon">
+		Maintaining Social Contact Information</a>, It should be
+		possible to "easily create a new contact and add it to my
+		contacts." This suggests that resource creation is closely linked
+		to the application context. The new resource is created in a
+		container representing "my contacts." The lifecycle of the
+		resource is linked to the lifecycle of it's container. So, for
+		example, if "my contacts" is deleted then a user would also
+		reasonably expect that all contacts within it would also be
+		deleted.
+	</p>
+	<p>
+		Contact details are captured as an RDF description and it's
+		properties, including "names, email addresses, telephone numbers,
+		instant messenger identities and so on." The description may
+		include non-standard RDF; "data about my contacts that the
+		original design didn’t consider." The following RDF could be used
+		to describe contact information using the FOAF
+		vocabulary [<cite><a href="#bib-FOAF" class="bibref">FOAF</a></cite>]. A contact is represented here by a
+		foaf:PersonalProfileDocument defining a resource that can be
+		created and updated as a single-unit, even though it may describe
+		ancillary resources, such as a foaf:Person, below.
+	</p>
+	<div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example">@prefix foaf:  &lt;; .
+&lt;&gt; a foaf:PersonalProfileDocument;
+	foaf:PrimaryTopic [ 
+		a foaf:Person;
+		foaf:name "Timothy Berners-Lee";
+		foaf:title "Sir";
+		foaf:firstName "Timothy";
+		foaf:surname "Berners-Lee";
+		foaf:nick "TimBL", "timbl";
+		foaf:homepage &lt;;;
+		foaf:weblog &lt;;;
+		foaf:mbox &lt;mailto:[email protected]&gt;;
+		foaf:workplaceHomepage &lt;;.
+	]</pre></div>
+	</section>
+	<section id="alternative-scenario-delete-resource" rel="bibo:chapter" resource="#scen-delete_resource" typeof="bibo:Chapter">
+	<h4 id="scen-delete_resource"><span class="secno">4.2.2 </span>Alternative scenario: delete
+			resource</h4>
+	<p>
+		Delete a resource and all it's properties. If the resource resides
+		within a container it will be removed from that container, however
+		other links to the deleted resource may be left as dangling
+		references. In the case where the resource is a container, the
+		server may also delete any or all contained resources. In normal
+		practice, a deleted resource cannot be reinstated. There are
+		however, edge-cases where limited undelete may be desirable. Best
+		practice states that "Cool URIs don't change" [<cite><a href="#bib-COOLURIS" class="bibref">COOLURIS</a></cite>], which implies that
+		deleted URIs shouldn't be recycled.
+	</p>
+	</section>
+	<section id="alternative-scenario-moving-contained-resources" rel="bibo:chapter" resource="#scen-moving_contained_resources" typeof="bibo:Chapter">
+	<h4 id="scen-moving_contained_resources"><span class="secno">4.2.3 </span>Alternative scenario: moving
+			contained resources</h4>
+	<p>
+		Many resources may have value beyond the life of their membership
+		in a container. This implies methods to add references to revise
+		container membership. Cloning container members for use in other
+		containers results in duplication of information and maintenance
+		problems; web practice is to encourage the creation of one
+		resource, which may be referenced as many places as necessary. A
+		change of ownership may - or may not - imply a change of URI,
+		depending upon the specific server naming policy. While assigning a
+		new URI to a resource is discouraged [<cite><a href="#bib-WEBARCH" class="bibref">WEBARCH</a></cite>], it is possible to indicate that a
+		resource has moved with an appropriate HTTP response.
+	</p>
+	</section>
+	</section>
+	<section id="use-case-retrieve-resource-description" rel="bibo:chapter" resource="#uc-retrieve_resource_description" typeof="bibo:Chapter">
+	<h3 id="uc-retrieve_resource_description"><span class="secno">4.3 </span>Use Case: Retrieve resource
+			description</h3>
+	<p>Access the current description of a resource, containing
+		properties of that resource and links to related resources. The
+		representation may include descriptions of related resources that
+		cannot be accessed directly. Depending upon the application, an
+		server may enrich the retrieved RDF with additional triples. Examples
+		include adding incoming links, sameAs closure and type closure.
+		The HTTP response should also include versioning information (i.e.
+		last update or entity tag) so that subsequent updates can ensure
+		they are being applied to the correct version.</p>
+	<ul>
+		<li>Use standard vocabularies as appropriate to enable a
+			"common understanding of the resource" (from <a href="#story-social" title="">Maintaining
+				Social Contact Information</a>).
+		</li>
+		<li>A "scalable linking model is key" (from <a href="#story-meter_monitoring" title="">#Municipality
+				Operational Monitoring</a>).
+		</li>
+	</ul>
+	<section id="primary-scenario" rel="bibo:chapter" resource="#scen-fetch" typeof="bibo:Chapter">
+	<h4 id="scen-fetch"><span class="secno">4.3.1 </span>Primary scenario</h4>
+	<p>
+		The user-story <a href="#story-project_data" title=""> Project Membership Information</a> discusses the
+		representation of information about people and projects. It calls
+		for "Resource descriptions for each person and project" allowing
+		project teams to review information held about these resources.
+		The example below illustrates the kinds of information that might
+		be held about organizational structures based on the <a href="" title="" rel="nofollow">Epimorphics</a>
+		<a href="" title="" rel="nofollow">organizational ontology</a>.
+	</p>
+	<p>Note that the example below defines two resources (shown as
+		separate sections below) that will be hosted on an <abbr title="Linked Data Platform">LDP</abbr> server based at
+ The representations of these resources may
+		include descriptions of related resources, such as
+, that that fall under a different authority and
+		therefore can't be served from the <abbr title="Linked Data Platform">LDP</abbr> server at this location.</p>
+	<div class="example"><div class="example-title"><span>Example 4</span></div><pre class="example">@prefix org: &lt;; .
[email protected] owltime: &lt;; .
[email protected] xsd: &lt;; .
[email protected] &lt;; .
+&lt;member1&gt; a org:Membership ;
+	org:member &lt;; ;
+	org:organization; ;
+	org:role &lt;director&gt; ;
+	org:memberDuring [a owltime:Interval; owltime:hasBeginning [
+		owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .
+&lt;; a org:FormalOrganization ;
+	skos:prefLabel "The World Wide Web Consortium"@en ;
+	skos:altLabel "W3C" .</pre></div>
+<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example">@prefix org: &lt;; .
[email protected] rdfs: &lt;; .
[email protected] &lt;; .
+&lt;director&gt; a org:Role ;
+	rdfs:label "Director" .</pre></div>
+	</section>
+	<section id="alternative-scenario-retrieve-description-of-a-non-document-resource" rel="bibo:chapter" resource="#scen-alt_non-document_resource" typeof="bibo:Chapter">
+	<h4 id="scen-alt_non-document_resource"><span class="secno">4.3.2 </span>Alternative scenario: retrieve
+			description of a non-document resource</h4>
+	<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
+		the person and the profile; the former being the topic of the
+		latter. This begs the question as to what a client should do with
+		such non-document resources. In this case the HTTP protocol
+		requires that the fragment part be stripped off before requesting
+		the URI from the server. The result is a resolvable URI for the
+		profile.</p>
+	<div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example">@base &lt;;
[email protected] foaf: &lt;;.
[email protected] dc: &lt;;.
+&lt;&gt; a foaf:PersonalProfileDocument ;
+	dc:title "Tim Berners-Lee's FOAF file" ;
+	foaf:homepage &lt;; ;
+	foaf:primaryTopic &lt;#i&gt; .</pre></div>
+	</section>
+	</section>
+	<section id="use-case-update-existing-resource" rel="bibo:chapter" resource="#uc-update_existing" typeof="bibo:Chapter">
+	<h3 id="uc-update_existing"><span class="secno">4.4 </span>Use Case: Update existing resource</h3>
+	<p>
+		Change the RDF description of a <abbr title="Linked Data Platform">LDP</abbr> resource, potentially removing
+		or overwriting existing data. This allows applications to <i>enrich</i>
+		the representation of a resource by addling additional links to
+		other resources.
+	</p>
+	<ul>
+		<li>Unrestricted vocabulary: It should be possible be "able
+			to add ... application-specific data" to resources (from <a href="#story-social" title="">#Maintaining
+				Social Contact Information</a>).
+		</li>
+	</ul>
+	<section id="primary-scenario-enrichment" rel="bibo:chapter" resource="#scen-update_enrichment" typeof="bibo:Chapter">
+	<h4 id="scen-update_enrichment"><span class="secno">4.4.1 </span>Primary scenario: enrichment</h4>
+	<p>
+		This relates to user-story <a href="#story-media" title="">
+			Metadata Enrichment in Broadcasting</a> and is based on the <a href="" title="" rel="nofollow">BBC
+			Sports Ontology</a>. The <i>resource-centric</i> view of linked-data
+		provides a natural granularity for substituting, or overwriting a
+		resource and its data. The simplest kind of update would simply
+		replace what is currently known about a resource with a new
+		representation. There are two distinct resources in the example
+		below; a sporting event and an associated award. The granularity
+		of the resource would allow a user to replace the information about the
+		award without disturbing the information about the event.
+	</p>
+	<div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example">@prefix sport: &lt;; .
[email protected] rdfs: &lt;; .
+ :mens_sprint a sport:MultiStageCompetition;
+    rdfs:label "Men's Sprint";
+    sport:award &lt;#gold_medal&gt; .
+&lt;#gold_medal&gt; a sport:Award .</pre></div>
+	<p>We can enrich the description as events unfold, linking to
+		the winner of the gold medal by substituting the above description
+		with the following.</p>
+	<div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example">@prefix sport: &lt;; .
[email protected] rdfs: &lt;; .
[email protected] foaf: &lt;; .
+ :mens_sprint a sport:MultiStageCompetition;
+    rdfs:label "Men's Sprint";
+    sport:award &lt;#gold_medal&gt; .
+&lt;#gold_medal&gt; a sport:Award; 
+    sport:awarded_to [
+        a foaf:Agent ;
+        foaf:name "Chris Hoy" .
+    ] .</pre></div>
+	</section>
+	<section id="alternative-scenario-selective-update-of-a-resource" rel="bibo:chapter" resource="#scen-alt_selective_update" typeof="bibo:Chapter">
+	<h4 id="scen-alt_selective_update"><span class="secno">4.4.2 </span>Alternative scenario: selective
+			update of a resource</h4>
+	<p>
+		This relates to user-story <a href="#story-data_catalogs" title="">Data
+			Catalogs</a>, based on the <a href="" title="" rel="nofollow">Data Catalog Vocabulary</a>. A catalogue is
+		described by the following RDF model.
+	</p>
+	<div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example">@prefix dcat: &lt;;	.
[email protected] dcterms: &lt;; .
+ :catalog a dcat:Catalog ;
+    dcat:dataset :dataset/001;
+    dcterms:issued "2012-12-11"^^xsd:date.</pre></div>
+	<p>
+		A catalog may contain multiple datasets, so when linking to new
+		datasets it would be simpler and preferable to selectively add
+		just the new dataset links. A <a href="" title="" rel="nofollow">Talis changeset</a> could be used to add a new dc:title to the
+		dataset. The following update would be directed to the catalogue
+		to add an additional dataset.
+	</p>
+	<div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example">@prefix : &lt;;.
[email protected] dcterms: &lt;; .
[email protected] cs: &lt;; .
[email protected] rdf: &lt;;.
+  a cs:ChangeSet ;
+  cs:subjectOfChange :catalog ;
+  cs:createdDate "2012-01-01T00:00:00Z" ;
+  cs:changeReason "Update catalog datasets" ;
+  cs:addition [
+    a rdf:Statement ;
+    rdf:subject :catalog ;
+    rdf:predicate dcat:dataset ;
+    rdf:object :dataset/002 .
+  ] .</pre></div>
+	</section>
+	</section>
+	<section id="use-case-determine-if-a-resource-has-changed" rel="bibo:chapter" resource="#uc-has_resource_changed" typeof="bibo:Chapter">
+	<h3 id="uc-has_resource_changed"><span class="secno">4.5 </span>Use Case: Determine if a resource has
+			changed</h3>
+	<p>
+		It should be possible to retrieve versioning information about a
+		resource (e.g. last modified or entity tag) without having to
+		download a representation of the resource. This information can
+		then be compared with previous information held about that
+		resource to determine if it has changed. This versioning
+		information can also be used in subsequent <i>conditional</i>
+		requests to ensure they are only applied if the version is
+		unchanged.
+	</p>
+	<section id="primary-scenario-1" rel="bibo:chapter" resource="#scen-primary_has_changed" typeof="bibo:Chapter">
+	<h4 id="scen-primary_has_changed"><span class="secno">4.5.1 </span>Primary scenario</h4>
+	<p>
+		Based on the user-story, <a href="#story-constrained_devices" title="">
+			Constrained Devices and Networks</a>, an <abbr title="Linked Data Platform">LDP</abbr> server could be configured to
+		act as a proxy for a CoAP [<cite><a href="#bib-COAP" class="bibref">COAP</a></cite>] based <a href="" title="" rel="nofollow">Web
+			of Things</a>. As an observer of CoAP resources, the <abbr title="Linked Data Platform">LDP</abbr> server registers
+		its interest so that it will be notified whenever the sensor
+		reading changes. Clients of the <abbr title="Linked Data Platform">LDP</abbr> can interrogate the server to
+		determine if the state has changed.
+	</p>
+	<p>
+		In this example, the information about a sensor and corresponding
+		sensor readings can be represented as RDF resources. The first
+		resource below, represents a sensor described using the <a href="" title="" rel="nofollow">Semantic
+			Sensor Network</a> ontology.
+	</p>
+	<div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example">@prefix : &lt;;.
+&lt;&gt; a :MainsFrequencySensor;
+  rdfs:comment "Sense grid load based on mains frequency";
+  ssn:hasMeasurementCapability [
+	a :FrequencyMeasurementCapability;
+	ssn:hasMeasurementProperty &lt;#property_1&gt; .
+  ] .</pre></div>
+	<p>
+		The value of the sensor changes in real-time as measurements are
+		taken. The <abbr title="Linked Data Platform">LDP</abbr> client can interrogate the resource below to
+		determine if it has changed, <i>without</i> necessarily having to
+		download the RDF representation. As different sensor properties
+		are represented disjointly (separate RDF representations) they may
+		change independently.
+	</p>
+	<div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example">@prefix : &lt;;.
+&lt;; :hasMeasurementPropertyValue &lt;&gt; .
+&lt;&gt; a :FrequencyValue;
+	:hasQuantityValue "50"^^xsd:float.</pre></div>
+	</section>
+	</section>
+	<section id="use-case-aggregate-resources" rel="bibo:chapter" resource="#uc-aggregate_resources" typeof="bibo:Chapter">
+	<h3 id="uc-aggregate_resources"><span class="secno">4.6 </span>Use Case: Aggregate resources</h3>
+	<p>
+		There is a requirement to be able to manage <i>collections</i> of
+		resources. The concept of a collection overlaps with, but is
+		distinct from that of a container. These collections are (weak)
+		aggregations, unrelated to the lifecycle management of resources,
+		and distinct from the ownership between a resource and its
+		container. However, the composition of a container may be
+		reflected as a collection to support navigation of the container
+		and its contents. There is a need to be able to create collections
+		by adding and deleting individual membership properties. Resources
+		may belong to multiple collections, or to none.
+	</p>
+	<ul>
+		<li>Resource descriptions are a "mix of simple data and
+			collections" (from <a href="#story-tracking_relationships" title="">#Keeping Track of Personal and Business
+				Relationships</a>).
+		</li>
+		<li>Relative URIs: It should be possible to "ship payloads of
+			RDF" for a collection as a whole without breaking internal links
+			(from <a href="#story-constrained_devices" title="">Constrained
+				Devices and Networks</a>).
+		</li>
+	</ul>
+	<section id="primary-scenario-add-a-resource-to-a-collection" rel="bibo:chapter" resource="#scen-add_a_resource_to_a_collection" typeof="bibo:Chapter">
+	<h4 id="scen-add_a_resource_to_a_collection"><span class="secno">4.6.1 </span>Primary scenario: add a resource
+			to a collection</h4>
+	<p>
+		This example is from <a href="#story-lld" title="">Library
+			Linked Data</a> and LLD-UC [<cite><a href="#bib-LLD-UC" class="bibref">LLD-UC</a></cite>], specifically <a href="" title="" rel="nofollow">Subject Search</a>.
+	</p>
+	<p>There is an existing collection at
+		&lt;; that
+		defines a collection of subject headings. This collection is
+		defined as a skos:ConceptScheme and the client wishes to insert a
+		new concept into the scheme. which will be related to the
+		collection via a skos:inScheme link. The new subject-heading,
+		"outer space exploration", is not necessarily owned by a
+		container. The following RDF would be added to the (item-level)
+		description of the collection.</p>
+	<div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example">@prefix scheme : &lt;;.
[email protected] concept : &lt;;.
+scheme:subject-heading a skos:ConceptScheme.
+concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.</pre></div>
+	</section>
+	<section id="alternative-scenario-add-a-resource-to-multiple-collections" rel="bibo:chapter" resource="#scen-add_a_resource_to_multiple_collections" typeof="bibo:Chapter">
+	<h4 id="scen-add_a_resource_to_multiple_collections"><span class="secno">4.6.2 </span>Alternative scenario: add a
+			resource to multiple collections</h4>
+	<p>
+		Logically, a resource should not be owned by more than one
+		container. however, it may be a member of multiple collections
+		which define a weaker form of <i>aggregation</i>. As this is
+		simply a manipulation of the RDF description of a collection, it
+		should be possible to add the same resource to multiple
+		collections.
+	</p>
+	<p>
+		As a machine-readable collection of medical terms, the <a href="|" title="|" rel="nofollow">SNOMED</a> ontology
+		is of key importance in <a href="#Healthcare" title="">
+			healthcare</a>. SNOMED CT allows concepts with more than one parent
+		that don't fall into a lattice. In the example below, the same
+		concept may fall under two different parent concepts. The example
+		uses skos:narrowerTransitive to elide intervening concepts.
+	</p>
+	<div class="example"><div class="example-title"><span>Example 14</span></div><pre class="example">@prefix : &lt;;.
+:_119376003 a skos:Concept ;
+	skos:prefLabel "Tissue specimen"
+	skos:narrowerTransitive :TissueSpecimenFromHeart.
+:_127462005 a skos:Concept ;
+	skos:prefLabel "Specimen from heart"
+   skos:narrowerTransitive :TissueSpecimenFromHeart.
+:_128166000 a skos:Concept;
+	rdfs:label "Tissue specimen from heart".</pre></div>
+	</section>
+	</section>
+	<section id="use-case-filter-resource-description" rel="bibo:chapter" resource="#uc-filter_resource_description" typeof="bibo:Chapter">
+	<h3 id="uc-filter_resource_description"><span class="secno">4.7 </span>Use Case: Filter resource description</h3>
+	<p>This use-case extends the normal behaviour of retrieving an
+		RDF description of a resource, by dynamically excluding specific
+		(membership) properties. For containers, it is often desirable to
+		be able to read a collection, or item-level description that
+		excludes the container membership.</p>
+	<section id="primary-scenario-retrieve-collection-level-description" rel="bibo:chapter" resource="#scen-retrieve_collection-level_description" typeof="bibo:Chapter">
+	<h4 id="scen-retrieve_collection-level_description"><span class="secno">4.7.1 </span>Primary scenario: retrieve
+			collection-level description</h4>
+	<p>
+		This scenario, based on <a href="#Library_Linked_Data" title="">
+			Library Linked Data</a>, uses the Dublin Core Metadata Initiative <a href="|" title="|" rel="nofollow">Collection-Level</a> description. A collection can
+		refer to any aggregation of physical or digital items. This
+		scenario covers the case whereby a client can request a
+		collection-level description as typified by the example below,
+		without necessarily having to download a full listing of the items
+		within the collection.
+	</p>
+	<div class="example"><div class="example-title"><span>Example 15</span></div><pre class="example">@prefix rdf: &lt;rdf=""&gt;.
[email protected] dc: &lt;;.
[email protected] : &lt;;.
[email protected] dcmitype: &lt;;.
[email protected] cld: &lt;;.
[email protected] dcterms: &lt;;.
+&lt;&gt; dc:type dcmitype:Collection ;
+	dc:title "Directory of organizations working with Linked Data" ;
+	dcterms:abstract "This is a directory of organisations specializing in Linked Data."
+	cld:isLocatedAt &lt;;
+	cld:isAccessedVia &lt;;</pre></div>
+	</section>
+	<section id="alternative-scenario-retrieve-item-level-description-of-a-collection" rel="bibo:chapter" resource="#scen-retrieve_item-level_description_of_a_collection" typeof="bibo:Chapter">
+	<h4 id="scen-retrieve_item-level_description_of_a_collection"><span class="secno">4.7.2 </span>Alternative scenario: retrieve
+			item-level description of a collection</h4>
+	<p>
+		This use-case scenario, also based on <a href="#story-lld" title=""> Library Linked Data</a>,
+		focuses on obtaining an item-level description of the resources
+		aggregated by a collection. The simplest scenario is where the
+		members of a collection are returned within a single
+		representation, so that a client can explore the data by following
+		these links. Different applications may use different membership
+		predicates to capture this aggregation. The example below uses
+		rdfs:member, but many different membership predicates are in
+		common use, including RDF Lists. Item-level descriptions can be
+		captured using the Functional Requirements for Bibliographic
+		Records (<a href="" title="" rel="nofollow">FRBR</a>) <a href="" class="external text" title="" rel="nofollow">ontology</a>.
+	</p>
+	<div class="example"><div class="example-title"><span>Example 16</span></div><pre class="example">@prefix frbr: &lt;;.
+&lt;&gt; rdfs:member &lt;#ebooks97&gt;, &lt;#ebooks21279&gt;.
+&lt;#work97&gt; a frbr:LiteraryWork;
+   dc:title "Flatland: a romance of many dimensions" ;
+	frbr:creator &lt;#Abbott_Edwin&gt;;
+	frbr:manifestation &lt;ebook97&gt;.
+&lt;#work21279&gt; a frbr:LiteraryWork;
+	dc:title "2 B R 0 2 B" ;
+	frbr:creator &lt;#Vonnegut_Kurt&gt;;
+	frbr:manifestation &lt;ebook21279&gt;.</pre></div>
+	<p>Collections are potentially very large, so some means may be
+		required to limit the size of RDF representation returned by the
+		<abbr title="Linked Data Platform">LDP</abbr> server (e.g. pagination).</p>
+	</section>
+	</section>
+	<section id="use-case-manage-media-resources" rel="bibo:chapter" resource="#uc-manage_media_resources" typeof="bibo:Chapter">
+	<h3 id="uc-manage_media_resources"><span class="secno">4.8 </span>Use Case: Manage media resources</h3>
+	<p>It should be possible to easily add non-RDF media resources
+		to containers that accept them. Media resources may be updated and
+		removed during the lifecycle of the container.</p>
+	<section id="primary-scenario-access-media-resources" rel="bibo:chapter" resource="#scen-access_media_resources" typeof="bibo:Chapter">
+	<h4 id="scen-access_media_resources"><span class="secno">4.8.1 </span>Primary scenario: access media
+			resources</h4>
+	<p>
+		From the User Story <a href="#Sharing_Binary_Resources_and_Metadata" title="">
+			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
+		represent this media resource, and creates a link from the
+		container to the new URI.The media resource may have an explicit
+		representation of the media type. It should be possible to find
+		the metadata about such a resource and to access and edit it in
+		the usual ways.
+	</p>
+	<p>
+		This example uses the Ontology
+			for Media Resources to describe a media resource added to a
+		collection [<cite><a href="#bib-MEDIAONT" class="bibref">MEDIAONT</a></cite>].
+	</p>
+	<div class="example"><div class="example-title"><span>Example 17</span></div><pre class="example">@prefix ma: &lt;; .
+&lt;dataset&gt; a ma:Collection ;
+	:hasMember &lt;dataset/image1.jpg&gt;
+&lt;dataset/image1.jpg&gt; a ma:MediaResource ;
+	ma:hasFormat "image/jpeg" .</pre></div>
+	</section>
+	<section id="alternative-scenario-media-resource-attachments" rel="bibo:chapter" resource="#scen-media_attachments" typeof="bibo:Chapter">
+	<h4 id="scen-media_attachments"><span class="secno">4.8.2 </span>Alternative scenario:
+			media-resource attachments</h4>
+	<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
+		trying to create a work order along with an attached image showing
+		a faulty machine part. To the user and to the work order system,
+		these two artifacts are managed as a set. A single request may
+		create the work order, the attachment, and the relationship
+		between them, atomically. When the user retrieves the work order
+		later, they expect a single request by default to retrieve the
+		work order plus all attachments. When the user updates the work
+		order, e.g. to mark it completed, they only want to update the
+		work order proper, not its attachments. Users may
+		add/remove/replace attachments to the work order during its
+		lifetime.
+	</p>
+	</section>
+	</section>
+<section id="requirements" rel="bibo:chapter" resource="#reqs" typeof="bibo:Chapter">
+<!--OddPage--><h2 id="reqs"><span class="secno">5. </span>Requirements</h2>
+<section id="functional-requirements" rel="bibo:chapter" resource="#reqs-functional" typeof="bibo:Chapter">
+	<h3 id="reqs-functional"><span class="secno">5.1 </span>Functional Requirements</h3>
+	<ol>
+		<li>Create Containers, from <a href="#uc-manage_containers" title="">Use Case: Manage containers</a>
+		</li>
+		<li>Creation of nested containers, from <a href="#uc-manage_containers" title="">Use Case: Manage
+				containers</a>
+		</li>
+		<li>Creation of resources (within a container), from <a href="#uc-manage_resources" title="">Use Case: Manage resources</a>
+		</li>
+		<li>Deletion of resources, from <a href="#uc-amnage_resources" title="">Use Case: Manage resources</a>
+		</li>
+		<li>Moving contained resources, from <a href="#uc-manage_resources" title="">Use Case: Manage resources</a>
+		</li>
+		<li>Retrieve resource description, from <a href="#uc-retrieve_resource_description" title="">Use Case:
+				Retrieve resource description</a>
+		</li>
+		<li>Retrieve description of a non-document resource, from <a href="#uc-retrieve_resource_description" title="">Use Case:
+				Retrieve resource description</a>
+		</li>
+		<li>Enrichment (substituting update of existing resource),
+			from <a href="#uc-update_existing" title="">Use Case:
+				Update existing resource</a>
+		</li>
+		<li>Selective update of a resource, from <a href="#uc-update_existing" title="">Use Case: Update
+				existing resource</a>
+		</li>
+		<li>Determine if a resource has changed, from <a href="#uc-has_resource_changed" title="">Use Case:
+				Determine if a resource has changed</a>
+		</li>
+		<li>Add a resource to a collection, from <a href="#uc-aggregate_resources" title="">Use Case: Aggregate
+				resources</a>
+		</li>
+		<li>Add a resource to multiple collections, from <a href="#uc-aggregate_resources" title="">Use Case: Aggregate
+				resources</a>
+		</li>
+		<li>Retrieve collection-level description, from <a href="#uc-filter_resource_description" title="">Use Case:
+				Filter resource description</a>
+		</li>
+		<li>Retrieve item-level description of a collection, from <a href="#uc-filter_resource_description" title="">Use Case:
+				Filter resource description</a>
+		</li>
+		<li>Access media resources, from <a href="#uc-manage_media_resources" title="">Use Case: Manage
+				media resources</a>
+		</li>
+		<li>Media-resource attachments, from <a href="#uc-manage_media_resources" title="">Use Case: Manage
+				media resources</a>
+		</li>
+	</ol>
+	</section>
+	<section id="non-functional-requirements" rel="bibo:chapter" resource="#reqs-non-functional" typeof="bibo:Chapter">
+	<h3 id="reqs-non-functional"><span class="secno">5.2 </span>Non-Functional Requirements</h3>
+	<ol>
+		<li>Provide access guidance to resources, from <a href="#uc-manage_containers" title="">Use Case: Manage
+				containers</a>
+		</li>
+		<li>Non-duplication of resources, from <a href="#uc-manage_resources" title="">Use Case: Manage resources</a>
+		</li>
+		<li>Distribution of resources, from <a href="#uc-manage_resources" title="">Use Case: Manage resources</a>
+		</li>
+		<li>Consistent, global naming, from <a href="#uc-manage_resources" title="">Use Case: Manage resources</a>
+		</li>
+		<li>Use standard vocabularies as appropriate, from <a href="#uc-retrieve_resource_description" title="">Use Case:
+				Retrieve resource description</a>
+		</li>
+		<li>Scalable linking model, from <a href="#uc-retrieve_resource_description" title="">Use Case:
+				Retrieve resource description</a>
+		</li>
+		<li>Unrestricted vocabulary, from <a href="#uc-update_existing" title="">Use Case: Update
+				existing resource</a>
+		</li>
+		<li>Resource descriptions are a "mix of simple data and
+			collections", from <a href="#uc-aggregate_resources" title="">Use Case:
+				Aggregate resources</a>
+		</li>
+		<li>Relative URIs enabling sharing of collections, from <a href="#uc-aggregate_resources" title="">Use Case: Aggregate
+				resources</a>
+		</li>
+	</ol>
+	</section>
+<section id="acknowledgements" class="appendix informative">
+<!--OddPage--><h2><span class="secno">A. </span>Acknowledgements</h2><p><em>This section is non-normative.</em></p>
+<p>We would like to acknowledge the contributions of user-story authors: Christophe Guéret,
+Roger Menday, Eric Prud'hommeaux, Steve Speicher, John Arwe, Kevin Page.</p>
+<section rel="bibo:chapter" resource="#history" typeof="bibo:Chapter" class="appendix informative" id="history">
+<!--OddPage--><h2><span class="secno">B. </span>Change History</h2><p><em>This section is non-normative.</em></p>
+	<li>2012-12-14 - Initial ReSpec'ing framework for <a href="">Workgroup working wiki document</a> (SS)</li>
+	<li>2012-12-16 - Pulled in and ReSpec'd content from <a href="">Workgroup working wiki document</a> (SS)</li>
+	<li>2012-12-16 - Fixed cross section links and initial pass at biblio refs (SS)</li>
+<section rel="bibo:chapter" resource="#references" typeof="bibo:Chapter" class="appendix" id="references"><!--OddPage--><h2><span class="secno">C. </span>References</h2><section rel="bibo:chapter" resource="#informative-references" typeof="bibo:Chapter" id="informative-references"><h3><span class="secno">C.1 </span>Informative references</h3><dl about="" class="bibliography"><dt id="bib-COAP">[COAP]</dt><dd rel="dcterms:references">E Shelby; et al. <a href=""><cite>Constrained Application Protocol (CoAP)</cite></a>. IETF Internet Draft, December 2012. URL: <a href=""></a>
+</dd><dt id="bib-COOLURIS">[COOLURIS]</dt><dd rel="dcterms:references">Richard Cyganiak; Leo Sauermann. <a href=""><cite>Cool URIs for the Semantic Web.</cite></a> 3 December 2008. W3C Note. URL: <a href=""></a>
+</dd><dt id="bib-DAP-REQS">[DAP-REQS]</dt><dd rel="dcterms:references">Robin Berjon et al. <a href=""><cite>Device API Requirementsml</cite></a> 15 October 2009. Working Group Note. URL: <a href=""></a>
+</dd><dt id="bib-DCAT-UCR">[DCAT-UCR]</dt><dd rel="dcterms:references">R. Cyganiak; F. Maali. <a href=""><cite>Use Cases and Requirements for the Data Catalog Vocabulary</cite></a> 16 December 2012. W3C Editor's Draft. URL: <a href=""></a>.
+</dd><dt id="bib-FOAF">[FOAF]</dt><dd rel="dcterms:references">Dan Brickley, Libby Miller. <a href=""><cite>FOAF Vocabulary Specification 0.98.</cite></a> 9 August 2010. URL: <a href=""></a>
+</dd><dt id="bib-LINKED-DATA">[LINKED-DATA]</dt><dd rel="dcterms:references">Tim Berners-Lee. <a href=""><cite>Linked Data Design Issues.</cite></a> 27 July 2006. W3C-Internal Document. URL: <a href=""></a>
+</dd><dt id="bib-LINKED-DATA-PLATFORM">[LINKED-DATA-PLATFORM]</dt><dd rel="dcterms:references">Steve Speicher et al. <a href=""><cite>Linked Data Platform 1.0</cite></a> 25 October 2012. W3C Working Draft. URL: <a href=""></a>
+</dd><dt id="bib-LLD-UC">[LLD-UC]</dt><dd rel="dcterms:references">D. Vila Suero. <a href=""><cite>Library Linked Data Incubartor Group: Use Cases.</cite></a> 25 October 2011. W3C Incubator Group Report. URL: <a href=""></a>
+</dd><dt id="bib-MEDIA-FRAGMENTS-REQS">[MEDIA-FRAGMENTS-REQS]</dt><dd rel="dcterms:references">Raphael Troncy; Erik Mannens. <a href=""><cite>Use cases and requirements for Media Fragments</cite></a>. W3C Working Draft 17 December 2009. URL: <a href=""></a> 
+</dd><dt id="bib-MEDIAONT">[MEDIAONT]</dt><dd rel="dcterms:references">WonSuk Lee; et. al. <a href=""><cite>Ontology for Media Resources 1.0.</cite></a> 9 February 2012. W3C Recommendation. URL: <a href=""></a>
+</dd><dt id="bib-POWDER-USE-CASES">[POWDER-USE-CASES]</dt><dd rel="dcterms:references">Phil Archer. <a href=""><cite>POWDER: Use Cases and Requirements.</cite></a> 31 October 2007. W3C Note. URL: <a href=""></a>
+</dd><dt id="bib-RDB2RDF-UC">[RDB2RDF-UC]</dt><dd rel="dcterms:references">Eric Prud'hommeaux; Michael Hausenblas. <a href=""><cite>Use Cases and Requirements for Mapping Relational Databases to RDF.</cite></a> 8 June 2010. W3C Working Draft. URL: <a href=""></a>
+</dd><dt id="bib-RFC5023">[RFC5023]</dt><dd rel="dcterms:references">J. Gregorio, B. de hOra. <a href=""><cite>Atom Publishing Protocol</cite></a>. IETF RFC 5023. October 2007. URL: <a href=""></a>
+</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:references">Norman Walsh; Ian Jacobs. <a href=""><cite>Architecture of the World Wide Web, Volume One.</cite></a> 15 December 2004. W3C Recommendation. URL: <a href=""></a>