--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/ldp-ucr-note-snapshot.html Wed Mar 05 17:02:22 2014 +0000
@@ -0,0 +1,1753 @@
+<!DOCTYPE html>
+<html lang="en" dir="ltr" typeof="bibo:Document " about="" property="dcterms:language" content="en">
+<head>
+ <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 - http://berjon.com/
+ *****************************************************************/
+
+/* --- 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;
+}
+
+/* --- 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;
+}
+
+@media print {
+ .removeOnSave {
+ display: none;
+ }
+}
+</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="https://www.w3.org/StyleSheets/TR/W3C-WG-NOTE" rel="stylesheet"><!--[if lt IE 9]><script src='https://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+<body id="respecDocument" role="document" class="h-entry"><div id="respecHeader" role="contentinfo" class="head">
+ <p>
+
+ <a href="http://www.w3.org/"><img src="https://www.w3.org/Icons/w3c_home" alt="W3C" width="72" height="48"></a>
+
+ </p>
+ <h1 class="title p-name" id="title" property="dcterms:title">Linked Data Platform Use Cases and Requirements</h1>
+
+ <h2 id="w3c-working-group-note-05-march-2014" property="dcterms:issued" datatype="xsd:dateTime" content="2014-03-05T16:56:09.000Z"><abbr title="World Wide Web Consortium">W3C</abbr> Working Group Note <time class="dt-published" datetime="2014-03-05">05 March 2014</time></h2>
+ <dl>
+
+ <dt>This version:</dt>
+ <dd><a class="u-url" href="http://www.w3.org/TR/2014/NOTE-ldp-ucr-20140305/">http://www.w3.org/TR/2014/NOTE-ldp-ucr-20140305/</a></dd>
+ <dt>Latest published version:</dt>
+ <dd><a href="http://www.w3.org/TR/ldp-ucr/">http://www.w3.org/TR/ldp-ucr/</a></dd>
+
+
+ <dt>Latest editor's draft:</dt>
+ <dd><a href="http://www.w3.org/2012/ldp/hg/ldp-ucr.html">http://www.w3.org/2012/ldp/hg/ldp-ucr.html</a></dd>
+
+
+
+
+
+
+
+ <dt>Editors:</dt>
+ <dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Steve Battle" href="http://stevebattle.me">Steve Battle</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://www.sysemia.com">Sysemia Limited</a></span>
+</dd>
+<dd class="p-author h-card vcard" rel="bibo:editor" inlist=""><span typeof="foaf:Person"><a class="u-url url p-name fn" rel="foaf:homepage" property="foaf:name" content="Steve Speicher" href="http://stevespeicher.me">Steve Speicher</a>, <a rel="foaf:workplaceHomepage" class="p-org org h-org h-card" href="http://ibm.com/">IBM Corporation</a></span>
+</dd>
+
+
+
+ </dl>
+
+
+
+
+
+ <p class="copyright">
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> ©
+ 2014
+
+ <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup>
+ (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>,
+ <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>,
+ <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>),
+
+ All Rights Reserved.
+
+ <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
+ <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and
+
+ <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a>
+
+ rules apply.
+ </p>
+
+
+ <hr>
+</div>
+<section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" datatype="" property="dcterms:abstract" class="introductory" id="abstract"><h2 id="h2_abstract" role="heading" aria-level="1">Abstract</h2>
+<p>
+To foster the development of the Linked Data Platform specification, this document includes 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.
+ The starting point for the development of these use cases is a collection of user stories that provide realistic examples describing how people may use read-write Linked Data. The use cases themselves are captured in a narrative style that describes a
+ behavior, or set of behaviors based on, and using scenarios from, these 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>
+</section><section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="sotd" class="introductory"><h2 id="h2_sotd" role="heading" aria-level="1">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="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports index</a> at
+ http://www.w3.org/TR/.</em>
+ </p>
+
+
+ <p>
+ This document was published by the <a href="http://www.w3.org/2012/ldp">Linked Data Platform Working Group</a> as a Working Group Note.
+
+
+ If you wish to make comments regarding this document, please send them to
+ <a href="mailto:public-ldp@w3.org">public-ldp@w3.org</a>
+ (<a href="mailto:public-ldp-request@w3.org?subject=subscribe">subscribe</a>,
+ <a href="http://lists.w3.org/Archives/Public/public-ldp/">archives</a>).
+
+
+
+
+ All comments are welcome.
+
+ </p>
+
+
+ <p>
+ Publication as a Working Group Note 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 id="sotd_patent" about="" rel="w3p:patentRules" href="http://www.w3.org/Consortium/Patent-Policy-20040205/">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="http://www.w3.org/2004/01/pp-impl/55082/status" 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="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
+ Claim(s)</a> must disclose the information in accordance with
+ <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
+ 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+
+
+ </p>
+
+
+
+
+</section><section id="toc"><h2 id="h2_toc" role="heading" aria-level="1" class="introductory">Table of Contents</h2><ul id="respecContents" role="directory" 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><span>Maintaining Social Contact Information</span></a></li><li class="tocline"><a class="tocxref" href="#keeping-track-of-personal-and-business-relationships"><span class="secno">3.2 </span><span>Keeping Track of Personal and Business Relationships</span></a></li><li class="tocline"><a class="tocxref" href="#system-and-software-development-tool-integration"><span class="secno">3.3 </span><span>System and Software Development Tool Integration</span></a></li><li class="tocline"><a class="tocxref" href="#library-linked-data"><span class="secno">3.4 </span><span>Library Linked Data</span></a></li><li class="tocline"><a class="tocxref" href="#municipality-operational-monitoring"><span class="secno">3.5 </span><span>Municipality Operational Monitoring</span></a></li><li class="tocline"><a class="tocxref" href="#healthcare"><span class="secno">3.6 </span><span>Healthcare</span></a></li><li class="tocline"><a class="tocxref" href="#metadata-enrichment-in-broadcasting"><span class="secno">3.7 </span><span>Metadata Enrichment in Broadcasting</span></a></li><li class="tocline"><a class="tocxref" href="#aggregation-and-mashups-of-infrastructure-data"><span class="secno">3.8 </span><span>Aggregation and Mashups of Infrastructure Data</span></a></li><li class="tocline"><a class="tocxref" href="#sharing-payload-of-rdf-data-among-low-end-devices"><span class="secno">3.9 </span><span>Sharing Payload of RDF Data Among Low-End Devices</span></a></li><li class="tocline"><a class="tocxref" href="#sharing-binary-resources-and-metadata"><span class="secno">3.10 </span><span>Sharing Binary Resources and Metadata</span></a></li><li class="tocline"><a class="tocxref" href="#data-catalogs"><span class="secno">3.11 </span><span>Data Catalogs</span></a></li><li class="tocline"><a class="tocxref" href="#constrained-devices-and-networks"><span class="secno">3.12 </span><span>Constrained Devices and Networks</span></a></li><li class="tocline"><a class="tocxref" href="#services-supporting-the-process-of-science"><span class="secno">3.13 </span><span>Services Supporting the Process of Science</span></a></li><li class="tocline"><a class="tocxref" href="#project-membership-information"><span class="secno">3.14 </span><span>Project Membership Information</span></a></li><li class="tocline"><a class="tocxref" href="#cloud-infrastructure-management"><span class="secno">3.15 </span><span>Cloud Infrastructure Management</span></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="#uc1"><span class="secno">4.1 </span><span>UC1</span>: Compose resources</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#s1.1"><span class="secno">4.1.1 </span>Primary scenario: create a container</a></li><li class="tocline"><a class="tocxref" href="#s1.2"><span class="secno">4.1.2 </span>Alternative scenario: create a nested container</a></li><li class="tocline"><a class="tocxref" href="#s1.3"><span class="secno">4.1.3 </span>Alternative scenario: Delete a container</a></li></ul></li><li class="tocline"><a class="tocxref" href="#uc2"><span class="secno">4.2 </span><span>UC2</span>: Manage resource lifecycle</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#s2.1"><span class="secno">4.2.1 </span>Primary scenario: create resource</a></li><li class="tocline"><a class="tocxref" href="#s2.2"><span class="secno">4.2.2 </span>Alternative scenario: delete resource</a></li><li class="tocline"><a class="tocxref" href="#s2.3"><span class="secno">4.2.3 </span>Alternative scenario: moving contained resources</a></li></ul></li><li class="tocline"><a class="tocxref" href="#uc3"><span class="secno">4.3 </span><span>UC3</span>: Retrieve resource description</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#s3.1"><span class="secno">4.3.1 </span>Primary scenario: retrieve resource description</a></li><li class="tocline"><a class="tocxref" href="#s3.2"><span class="secno">4.3.2 </span>Alternative scenario: retrieve description of a non-document resource (hash URI)</a></li></ul></li><li class="tocline"><a class="tocxref" href="#uc4"><span class="secno">4.4 </span><span>UC4</span>: Update existing resource</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#s4.1"><span class="secno">4.4.1 </span>Primary scenario: enrichment</a></li><li class="tocline"><a class="tocxref" href="#s4.2"><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="#uc5"><span class="secno">4.5 </span><span>UC5</span>: Determine if a resource has changed</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#s5.1"><span class="secno">4.5.1 </span>Primary scenario: determine if a resource has changed</a></li></ul></li><li class="tocline"><a class="tocxref" href="#uc6"><span class="secno">4.6 </span><span>UC6</span>: Aggregate resources</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#s6.1"><span class="secno">4.6.1 </span>Primary scenario: add a resource to a collection</a></li><li class="tocline"><a class="tocxref" href="#s6.2"><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="#uc7"><span class="secno">4.7 </span><span>UC7</span>: Filter resource description</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#s7.1"><span class="secno">4.7.1 </span>Primary scenario: retrieve collection-level description</a></li><li class="tocline"><a class="tocxref" href="#s7.2"><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="#uc8"><span class="secno">4.8 </span><span>UC8</span>: Retrieve a large resource description in multiple parts</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#s8.1"><span class="secno">4.8.1 </span>Primary scenario: Pagination</a></li></ul></li><li class="tocline"><a class="tocxref" href="#uc9"><span class="secno">4.9 </span><span>UC9</span>: Manage binary resources</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#s9.1"><span class="secno">4.9.1 </span>Primary scenario: access binary resources</a></li><li class="tocline"><a class="tocxref" href="#s9.2"><span class="secno">4.9.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-1"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a class="tocxref" href="#references"><span class="secno">B. </span>References</a><ul class="toc"><li class="tocline"><a class="tocxref" href="#informative-references"><span class="secno">B.1 </span>Informative references</a></li></ul></li></ul></section>
+
+
+
+<section id="scope-and-motivation" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+<!--OddPage--><h2 role="heading" aria-level="1" 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>The goal for the [<cite><a href="#bib-LINKED-DATA-PLATFORM" class="bibref">LINKED-DATA-PLATFORM</a></cite>] is
+ 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), which shares some characteristics with Linked Data
+ such as the use of HTTP and URLs but relying on a flexible data model based on RDF that allows for
+ multiple representations.</p>
+
+</section>
+
+<section id="organization-of-this-document" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+<!--OddPage--><h2 role="heading" aria-level="1" id="org"><span class="secno">2. </span>Organization of this Document</h2>
+ <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') [<cite><a href="#bib-COHN-2004" class="bibref">COHN-2004</a></cite>].
+ This document redacts a number of user stories around the theme of read/writeable linked data.
+ Analysis of each user story reveals a
+ number of (functional) use cases and other non-functional
+ requirements. See <em>Device API Access Control Use Cases and Requirements</em> [<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="#usecases" 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 [<cite><a href="#bib-COCKBURN-2000" class="bibref">COCKBURN-2000</a></cite>],
+ cataloging who does what with the system, for what purpose, but
+ without concern for system design or implementation. 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, step-by-step behaviors (as in <em>POWDER:
+ Use Cases and Requirements</em> [<cite><a href="#bib-POWDER-USE-CASES" class="bibref">POWDER-USE-CASES</a></cite>]), and non-functional requirements
+ raised by the use case.</li>
+ </ul>
+ <ul>
+ <li><b>Scenarios</b> are used to model the functional requirements of a use case and focus on a use case in action. Scenarios may range from
+ lightweight narratives as seen in <em>Use
+ cases and requirements for Media Fragments</em> [<cite><a href="#bib-MEDIA-FRAGMENTS-REQS" class="bibref">MEDIA-FRAGMENTS-REQS</a></cite>], to being formally
+ modeled as interaction diagrams. Each use case includes at
+ least a primary scenario, and possibly other alternative
+ scenarios.</li>
+ </ul>
+ <ul>
+ <li><b><a href="#reqs" title="Requirements">Requirements</a></b>
+ list functional and non-functional or quality requirements, and the use cases
+ they may be derived from. This approach is exemplified in the <em>Use Cases and Requirements for the Data
+ Catalog Vocabulary</em> [<cite><a href="#bib-DCAT-UCR" class="bibref">DCAT-UCR</a></cite>].</li>
+ </ul>
+</section>
+
+<section id="user-stories" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+<!--OddPage--><h2 role="heading" aria-level="1" id="userstories"><span class="secno">3. </span>User Stories</h2>
+
+ <section id="maintaining-social-contact-information" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-social"><span class="secno">3.1 </span><dfn id="dfn-maintaining-social-contact-information">Maintaining Social Contact Information</dfn></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,
+ how to use those links to interact with a contact (including <a href="#uc3" title="">reading</a>,
+ <a href="#uc4" title="">updating</a>,
+ and <a href="#s2.2" title="">deleting</a>
+ it), as well as how to easily <a href="#s2.1" 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="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-tracking_relationships"><span class="secno">3.2 </span><dfn id="dfn-keeping-track-of-personal-and-business-relationships">Keeping Track of Personal and Business Relationships</dfn></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, and we
+ have to use their identifier(s) for us.</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="#uc3" title="">examine</a>
+ or <a href="#uc4" title="">change</a>
+ their contents, would it not be simpler if there were a single
+ consistent application interface that they all supported?
+ </p>
+ <p>
+ The information held by any single organization might be a mix of
+ simple data and <a href="#uc6" 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="#s1.2" 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="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-oslc"><span class="secno">3.3 </span><dfn id="dfn-system-and-software-development-tool-integration">System and Software Development Tool Integration</dfn></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 [<cite><a href="#bib-OSLC" class="bibref">OSLC</a></cite>].
+ </p>
+ </section>
+
+ <section id="library-linked-data" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-lld"><span class="secno">3.4 </span><dfn id="dfn-library-linked-data">Library Linked Data</dfn></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 <em>Use Case Report</em> [<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="#uc6" 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="#uc4" title="">link resources
+ together</a>."
+ </li>
+ </ul>
+ <ul>
+ <li>Browsing: "<a href="#uc7" 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="#uc7" 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="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-meter_monitoring"><span class="secno">3.5 </span><dfn id="dfn-municipality-operational-monitoring">Municipality Operational Monitoring</dfn></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="#uc3" 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="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-healthcare"><span class="secno">3.6 </span><dfn id="dfn-healthcare">Healthcare</dfn></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 effects
+ 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="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-media"><span class="secno">3.7 </span><dfn id="dfn-metadata-enrichment-in-broadcasting">Metadata Enrichment in Broadcasting</dfn></h3>
+ <p>
+ There are many different use cases when broadcasters show interest
+ in metadata <a href="#uc4" 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="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-mashup"><span class="secno">3.8 </span><dfn id="dfn-aggregation-and-mashups-of-infrastructure-data">Aggregation and Mashups of Infrastructure Data</dfn></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="#uc6" title="">aggregated</a>, <a href="#uc7" 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="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-low-end_devices"><span class="secno">3.9 </span><dfn id="dfn-sharing-payload-of-rdf-data-among-low-end-devices">Sharing Payload of RDF Data Among Low-End Devices</dfn></h3>
+ <p>
+ Several projects around the idea of <em>downscaling the Semantic Web</em> 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 a container mechanism, adding and removing
+ sets of RDF triples to it. Currently, the
+ SemanticXO [<cite><a href="#bib-XO" class="bibref">XO</a></cite>] 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 a better approach.</p>
+ </section>
+
+ <section id="sharing-binary-resources-and-metadata" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-binary_and_metadata"><span class="secno">3.10 </span><dfn id="dfn-sharing-binary-resources-and-metadata">Sharing Binary Resources and Metadata</dfn></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) that are not distinguished from the
+ platform's point-of-view.</p>
+ </section>
+
+ <section id="data-catalogs" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-data_catalogs"><span class="secno">3.11 </span><dfn id="dfn-data-catalogs">Data Catalogs</dfn></h3>
+ <p>
+ The <em>Asset Description Metadata Schema</em> [<cite><a href="#bib-ADMS" class="bibref">ADMS</a></cite>]
+ 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="#uc5" title="">
+ updated content</a> without having to retrieve the whole content.
+ The Data Warehousing integration approach 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 descriptions 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>
+ </section>
+
+ <section id="constrained-devices-and-networks" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-constrained_devices"><span class="secno">3.12 </span><dfn id="dfn-constrained-devices-and-networks">Constrained Devices and Networks</dfn></h3>
+ <p>
+ Information coming from resource constrained devices in the Web of
+ Things [<cite><a href="#bib-WOT" class="bibref">WOT</a></cite>]
+ 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 '6LowPAN' [<cite><a href="#bib-6LOWPAN" class="bibref">6LOWPAN</a></cite>]
+ - IPv6 for resource constrained devices - and the <em>Constrained
+ Application Protocol</em> [<cite><a href="#bib-COAP" class="bibref">COAP</a></cite>], 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,
+ and memory) a solution based on <em>SPARQL Update</em> [<cite><a href="#bib-RDF-SPARQL-UPDATE" class="bibref">RDF-SPARQL-UPDATE</a></cite>] is at the current point
+ in time considered not to be useful and/or feasible. An approach
+ based on the HTTP-CoAP Mapping [<cite><a href="#bib-COAP-MAP" class="bibref">COAP-MAP</a></cite>] 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="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-process_of_science"><span class="secno">3.13 </span><dfn id="dfn-services-supporting-the-process-of-science">Services Supporting the Process of Science</dfn></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="#uc6" title="">Aggregations</a>,
+ specifically <em>Research Objects (ROs)</em> are exchanged
+ between services and clients bringing together workflows, data
+ sets, annotations, and provenance.
+ </li>
+ <li>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.
+ <ul>
+ <li>Foundation services 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.</li>
+ </ul>
+ </li>
+ </ul>
+ </section>
+
+ <section id="project-membership-information" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-project_data"><span class="secno">3.14 </span><dfn id="dfn-project-membership-information">Project Membership Information</dfn></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="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="story-cloud"><span class="secno">3.15 </span><dfn id="dfn-cloud-infrastructure-management">Cloud Infrastructure Management</dfn></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>
+
+<section id="use-cases" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+<!--OddPage--><h2 role="heading" aria-level="1" 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 rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="uc1">
+ <h3 id="h3_uc1" role="heading" aria-level="2"><span class="secno">4.1 </span><dfn id="dfn-uc1">UC1</dfn>: Compose resources</h3>
+ <p>
+ A number of user stories introduce the idea of a <em>container</em>
+ as a mechanism for composing resources within the
+ context of an application. A
+ composition would be identified by URI being a linked resource in its own
+ right. Its properties may represent the <em>affordances</em>
+ of the application, enabling clients to determine what other
+ operations they can do. These operations may
+ include descriptions of application specific services that can be
+ invoked by exchanging RDF documents.
+ </p>
+ <ul>
+ <li><a class="internalDFN" href="#dfn-nf1.1">NF1.1</a>: Provide "access guidance" (affordances) from user story, <a class="internalDFN" href="#dfn-maintaining-social-contact-information">Maintaining Social Contact Information</a>.</li>
+ </ul>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s1.1">
+ <h4 id="h4_s1.1" role="heading" aria-level="3"><span class="secno">4.1.1 </span>Primary scenario: create a container</h4>
+ <p>
+ Create a new container resource within the <abbr title="Linked Data Platform">LDP</abbr> server. In <a class="internalDFN" href="#dfn-services-supporting-the-process-of-science">Services Supporting the Process of Science</a>,
+ <a href="http://www.wf4ever-project.org/" title="http://www.wf4ever-project.org/" 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 aggregate scientific workflows and their artefacts [<cite><a href="#bib-RESEARCH-OBJECTS" class="bibref">RESEARCH-OBJECTS</a></cite>].
+ These artefacts will be added to the research object throughout the project lifecycle of the project.
+ </p>
+ <p>
+ The RDF description below captures the initial state of the research object. For the purposes of the example, we have included the time of creation. It is a linked data resource addressed via URL from which the following RDF can be retrieved. The null-relative URL <code><></code> should be understood as a self-reference to the research object itself.
+ </p>
+ <div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example"><code>
+@prefix ro: <http://purl.org/wf4ever/ro#> .
+@prefix dct: <http://purl.org/dc/terms/> .
+@prefix ore: <http://www.openarchives.org/ore/> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+
+<> a ro:ResearchObject, ore:Aggregation ;
+ dct:created "2012-12-01"^^xsd:dateTime .
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f1.1">F1.1</a>)</div>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s1.2">
+ <h4 id="h4_s1.2" role="heading" aria-level="3"><span class="secno">4.1.2 </span>Alternative scenario: create a nested container</h4>
+ <p>
+ The motivation for nested containers comes from the <a class="internalDFN" href="#dfn-system-and-software-development-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
+ <code>oslc_cm:attachment</code>. This may be viewed as nested containment. The <em>top-level-container</em> contains issues, and
+ each issue is itself a container of attachments.
+ In the example, <code>issue1234</code> is a member of the container <code>top-level-container</code>. In turn, <code>attachment324</code> and <code>attachment251</code> are attachments within <code>issue1234</code>. Treating these as containers makes it easier to manage them as self-contained units.
+ </p>
+ <div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example"><code>
+@prefix dcterms: <http://purl.org/dc/terms/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
+@prefix oslc_cm: <http://open-services.net/ns/cm#>.
+@prefix : <http://example.org/>.
+
+:top-level-container rdfs:member :issue1234 .
+
+:issue1234 a oslc_cm:ChangeRequest;
+ dcterms:identifier "1234";
+ dcterms:type "a bug";
+ oslc_cm:attachments :attachments.
+
+:attachments a oslc_cm:AttachmentList;
+ oslc_cm:attachment :attachment324, :attachment251.
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f1.2">F1.2</a>)</div>
+ </section>
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s1.3">
+ <h4 id="h4_s1.3" role="heading" aria-level="3"><span class="secno">4.1.3 </span>Alternative scenario: Delete a container</h4>
+ If a container can be deleted, it seems natural that any contained resources and nested containers should also be deleted.
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f1.3">F1.3</a>).</div>
+ </section>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="uc2">
+ <h3 id="h3_uc2" role="heading" aria-level="2"><span class="secno">4.2 </span><dfn id="dfn-uc2">UC2</dfn>: Manage resource lifecycle</h3>
+ <p>
+ This use case addresses the managed lifecycle of a resource and is
+ concerned with resource <em>ownership</em>. The responsibility for
+ managing resources belongs to 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>
+ <ul>
+ <li><a class="internalDFN" href="#dfn-nf2.1">NF2.1</a>: Non-duplication of resources: "Eliminate multiple
+ copies", representing resources in a single place from <a class="internalDFN" href="#dfn-maintaining-social-contact-information">Maintaining Social Contact Information</a>.
+ </li>
+ <li><a class="internalDFN" href="#dfn-nf2.2">NF2.2</a>: Distribution of resources: Linked data "may be stored on
+ separate servers" from <a class="internalDFN" href="#dfn-maintaining-social-contact-information">Maintaining Social Contact Information</a>.
+ </li>
+ <li><a class="internalDFN" href="#dfn-nf2.3">NF2.3</a>: Consistent, global naming: Resources should be "linked to
+ consistently, ... instead of maintaining various identifiers in
+ different formats" from <a class="internalDFN" href="#dfn-keeping-track-of-personal-and-business-relationships">Keeping Track of Personal and Business Relationships</a>.
+ </li>
+ </ul>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s2.1">
+ <h4 id="h4_s2.1" role="heading" aria-level="3"><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 class="internalDFN" href="#dfn-maintaining-social-contact-information">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
+ <code>foaf:PersonalProfileDocument</code> defining a resource that can be
+ created and updated as a single-unit, even though it may describe
+ ancillary resources, such as a <code>foaf:Person</code>, below.
+ </p>
+ <div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example"><code>
+@prefix foaf: <http://xmlns.com/foaf/0.1/> .
+
+<> 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 <http://www.w3.org/People/Berners-Lee/>;
+ foaf:weblog <http://dig.csail.mit.edu/breadcrumbs/blog/4>;
+ foaf:mbox <mailto:timbl@w3.org>;
+ foaf:workplaceHomepage <http://www.w3.org/>.
+ ]
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f2.1">F2.1</a>)</div>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s2.2">
+ <h4 id="h4_s2.2" role="heading" aria-level="3"><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>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f2.2">F2.2</a>)</div>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s2.3">
+ <h4 id="h4_s2.3" role="heading" aria-level="3"><span class="secno">4.2.3 </span>Alternative scenario: moving contained resources</h4>
+ <p>
+ Resources may have value beyond the life of their membership
+ in a container. This implies methods to add references to revise
+ container membership.
+ A change of ownership may or may not imply a change of URI,
+ depending upon the 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>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f2.3">F2.3</a>)</div>
+ </section>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="uc3">
+ <h3 id="h3_uc3" role="heading" aria-level="2"><span class="secno">4.3 </span><dfn id="dfn-uc3">UC3</dfn>: 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, <code>owl:sameAs</code> closure and <code>rdf:type</code> 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><a class="internalDFN" href="#dfn-nf3.1">NF3.1</a>: Use standard vocabularies as appropriate to enable a
+ "common understanding of the resource" from <a class="internalDFN" href="#dfn-maintaining-social-contact-information">Maintaining Social Contact Information</a>.
+ </li>
+ <li><a class="internalDFN" href="#dfn-nf3.2">NF3.2</a>: A "scalable linking model is key" from <a class="internalDFN" href="#dfn-municipality-operational-monitoring">Municipality Operational Monitoring</a>.
+ </li>
+ </ul>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s3.1">
+ <h4 id="h4_s3.1" role="heading" aria-level="3"><span class="secno">4.3.1 </span>Primary scenario: retrieve resource description</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="http://www.epimorphics.com/web/" title="http://www.epimorphics.com" rel="nofollow">Epimorphics</a>
+ organizational ontology [<cite><a href="#bib-ORG-ONT" class="bibref">ORG-ONT</a></cite>].
+ </p>
+ <p>Examples 4 and 5 below define two resources that would be hosted on an <abbr title="Linked Data Platform">LDP</abbr> server based at
+ <http://example.com/>. The representation in Example 4 describes <http://example.com/member1>, while that of Example 5 describes <http://example.com/role>.
+ A client reading Example 4 would have to separately retrieve Example 5 in order to get role information such as its descriptive label.
+ </p>
+ <p>
+ Note that the representations of these resources may
+ include descriptions of related resources, such as
+ <http://www.w3.org/>, that that fall under a completely different authority and
+ therefore can't be served directly from the <abbr title="Linked Data Platform">LDP</abbr> server at this location.</p>
+ <div>
+ <div class="example"><div class="example-title"><span>Example 4</span></div><pre class="example"><code>
+@prefix org: <http://www.w3.org/ns/org#> .
+@prefix owltime: <http://www.w3.org/2006/time> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+@base <http://example.com/> .
+
+<member1> a org:Membership ;
+ org:member <http://www.w3.org/People/Berners-Lee/card#i> ;
+ org:organization http://www.w3.org/> ;
+ org:role <director> ;
+ org:memberDuring [a owltime:Interval; owltime:hasBeginning [
+ owltime:inXSDDateTime "1994-10-01T00:00:00Z"^^xsd:dateTime]] .
+
+<http://www.w3.org/> a org:FormalOrganization ;
+ skos:prefLabel "The World Wide Web Consortium"@en ;
+ skos:altLabel "W3C" .
+</code></pre></div>
+</div>
+<div>
+<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example"><code>
+@prefix org: <http://www.w3.org/ns/org#> .
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
+@base <http://example.com/> .
+
+<director> a org:Role ;
+ rdfs:label "Director" .
+
+</code></pre></div>
+</div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f3.1">F3.1</a>)</div>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s3.2">
+ <h4 id="h4_s3.2" role="heading" aria-level="3"><span class="secno">4.3.2 </span>Alternative scenario: retrieve description of a non-document resource (hash URI)</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. Where the fragment is defined relative to the base, as in this example, the URL including the fragment may be used to access the resource representing the containing document. The HTTP protocol
+ requires that the fragment part be stripped off before requesting
+ the URI from the server. The client can then read properties of the hash URI <code><#i></code> from the retrieved description.
+ </p>
+ <div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example"><code>
+@base <http://www.w3.org/People/Berners-Lee/card>
+@prefix foaf: <http://xmlns.com/foaf/0.1/>.
+@prefix dc: <http://purl.org/dc/elements/1.1/>.
+
+<> a foaf:PersonalProfileDocument ;
+ dc:title "Tim Berners-Lee's FOAF file" ;
+ foaf:homepage <http://www.w3.org/People/Berners-Lee/> ;
+ foaf:primaryTopic <#i> .
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f3.2">F3.2</a>)</div>
+ </section>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="uc4">
+ <h3 id="h3_uc4" role="heading" aria-level="2"><span class="secno">4.4 </span><dfn id="dfn-uc4">UC4</dfn>: 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 <em>enrich</em>
+ the representation of a resource by addling additional links to
+ other resources.
+ </p>
+ <ul>
+ <li><a class="internalDFN" href="#dfn-nf4.1">NF4.1</a>: Unrestricted vocabulary: It should be possible be "able
+ to add ... application-specific data" to resources from <a class="internalDFN" href="#dfn-maintaining-social-contact-information">Maintaining Social Contact Information</a>.
+ </li>
+ </ul>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s4.1">
+ <h4 id="h4_s4.1" role="heading" aria-level="3"><span class="secno">4.4.1 </span>Primary scenario: enrichment</h4>
+ <p>
+ This relates to user story <a class="internalDFN" href="#dfn-metadata-enrichment-in-broadcasting">Metadata Enrichment in Broadcasting</a> and is based on the BBC
+ Sports Ontology [<cite><a href="#bib-BBC-SPORT" class="bibref">BBC-SPORT</a></cite>]. The <em>resource-centric</em> 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.
+ </p>
+ <p>
+ 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"><code>
+@prefix : <http://example.com/>.
+@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
+
+ :mens_sprint a sport:MultiStageCompetition;
+ rdfs:label "Men's Sprint";
+ sport:award <#gold_medal> .
+
+<#gold_medal> a sport:Award .
+</code></pre></div>
+ <p>The description can be enriched as events unfold, adding a link 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"><code>
+@prefix : <http://example.com/>.
+@prefix sport: <http://www.bbc.co.uk/ontologies/sport/> .
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
+@prefix foaf: <http://xmlns.com/foaf/0.1/> .
+
+ :mens_sprint a sport:MultiStageCompetition;
+ rdfs:label "Men's Sprint";
+ sport:award <#gold_medal> .
+<#gold_medal> a sport:Award;
+ sport:awarded_to [
+ a foaf:Agent ;
+ foaf:name "Chris Hoy" .
+ ] .
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f4.1">F4.1</a>)</div>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s4.2">
+ <h4 id="h4_s4.2" role="heading" aria-level="3"><span class="secno">4.4.2 </span>Alternative scenario: selective update of a resource</h4>
+ <p>
+ This relates to user story <a class="internalDFN" href="#dfn-data-catalogs">Data Catalogs</a>. A catalogue is
+ described by the following RDF model, based on the Data Catalog Vocabulary [<cite><a href="#bib-vocab-dcat" class="bibref">vocab-dcat</a></cite>] which provides a standard format for representing the metadata held by organizations.
+ </p>
+ <div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example"><code>
+@prefix : <http://example.com/>.
+@prefix dcat: <http://www.w3.org/ns/dcat#> .
+@prefix dcterms: <http://purl.org/dc/terms/> .
+
+ :catalog a dcat:Catalog ;
+ dcat:dataset :dataset/001;
+ dcterms:issued "2012-12-11"^^xsd:date.
+</code></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. For this example, a Changeset [<cite><a href="#bib-CHANGESET" class="bibref">CHANGESET</a></cite>] might be used to add a new <code>dc:title</code> 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"><code>
+@prefix : <http://example.com/>.
+@prefix dcterms: <http://purl.org/dc/terms/> .
+@prefix cs: <http://purl.org/vocab/changeset/schema#> .
+@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
+
+<change1>
+ 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 .
+ ] .
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f4.2">F4.2</a>)</div>
+ </section>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="uc5">
+ <h3 id="h3_uc5" role="heading" aria-level="2"><span class="secno">4.5 </span><dfn id="dfn-uc5">UC5</dfn>: 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 <em>conditional</em>
+ requests to ensure they are only applied if the version is
+ unchanged.
+ </p>
+ <ul>
+ <li><a class="internalDFN" href="#dfn-nf5.1">NF5.1</a>: Multiple changes to a resource: The <a class="internalDFN" href="#dfn-project-membership-information">Project Membership Information</a> user story is concerned with "access to the 'current' state", as distinct from earlier versions.
+ This is particularly relevant to changes which are made with respect to a specific version of the resource description.
+ The <abbr title="Linked Data Platform">LDP</abbr> must ensure consistent access in the case of multiple simultaneous attempts to access a resource.
+ </li>
+ </ul>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s5.1">
+ <h4 id="h4_s5.1" role="heading" aria-level="3"><span class="secno">4.5.1 </span>Primary scenario: determine if a resource has changed</h4>
+ <p>
+ Based on the user story, <a class="internalDFN" href="#dfn-constrained-devices-and-networks">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 Web of Things [<cite><a href="#bib-WOT" class="bibref">WOT</a></cite>]. 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 Semantic
+ Sensor Network [<cite><a href="#bib-SSN" class="bibref">SSN</a></cite>] ontology.
+ </p>
+ <div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example"><code>
+@prefix : <http://example.com/energy-management/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
+@prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#> .
+
+<> a :MainsFrequencySensor;
+ rdfs:comment "Sense grid load based on mains frequency";
+ ssn:hasMeasurementCapability [
+ a :FrequencyMeasurementCapability;
+ ssn:hasMeasurementProperty <#property_1> .
+ ] .
+</code></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, <em>without</em> 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"><code>
+@prefix : <http://example.com/energy-management/> .
+@prefix ssn: <http://purl.oclc.org/NET/ssnx/ssn#> .
+@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
+
+
+<http://example.com/energy-management#property_1> :hasMeasurementPropertyValue <> .
+<> a :FrequencyValue;
+ :hasQuantityValue "50"^^xsd:float.
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f5.1">F5.1</a>)</div>
+ </section>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="uc6">
+ <h3 id="h3_uc6" role="heading" aria-level="2"><span class="secno">4.6 </span><dfn id="dfn-uc6">UC6</dfn>: Aggregate resources</h3>
+ <p>
+ There is a requirement to be able to manage <em>collections</em> 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><a class="internalDFN" href="#dfn-nf6.1">NF6.1</a>: Resource descriptions are a "mix of simple data and
+ collections" from <a class="internalDFN" href="#dfn-keeping-track-of-personal-and-business-relationships">Keeping Track of Personal and Business Relationships</a>.
+ </li>
+ <li><a class="internalDFN" href="#dfn-nf6.2">NF6.2</a>: Relative URIs: It should be possible to "ship payloads of
+ RDF" for a collection as a whole without breaking internal links
+ from <a class="internalDFN" href="#dfn-constrained-devices-and-networks">Constrained Devices and Networks</a>.
+ </li>
+ </ul>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s6.1">
+ <h4 id="h4_s6.1" role="heading" aria-level="3"><span class="secno">4.6.1 </span>Primary scenario: add a resource to a collection</h4>
+ <p>
+ This example is from <a class="internalDFN" href="#dfn-library-linked-data">Library Linked Data</a> and LLD-UC [<cite><a href="#bib-LLD-UC" class="bibref">LLD-UC</a></cite>], specifically <em>Subject Search</em>.
+ </p>
+ <p>There is an existing collection at
+ <http://example.com/concept-scheme/subject-heading> that
+ defines a collection of subject headings. This collection is
+ defined as a <code>skos:ConceptScheme</code> and the client wishes to insert a
+ new concept into the scheme. which will be related to the
+ collection via a <code>skos:inScheme</code> link. In the example below, a new subject-heading,
+ "outer space exploration" is added to the <code>scheme:subject-heading</code> collection. The following RDF describes the (item-level)
+ description of the collection,
+ also demonstrating that the relationship between the parent and child resources may run in a seemingly counter-intuitive direction, from child to parent.
+ </p>
+ <div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example"><code>
+@prefix scheme : <http://example.com/concept-scheme/>.
+@prefix concept : <http://example.com/concept/>.
+@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
+
+scheme:subject-heading a skos:ConceptScheme.
+
+concept:Outer+space+Exploration skos:inScheme scheme:subject-heading.
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f6.1">F6.1</a>)</div>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s6.2">
+ <h4 id="h4_s6.2" role="heading" aria-level="3"><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 <em>aggregation</em>. 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 SNOMED CT ontology [<cite><a href="#bib-SNOMED" class="bibref">SNOMED</a></cite>]
+ is of key importance in user story, <a class="internalDFN" href="#dfn-healthcare">Healthcare</a>. SNOMED CT allows concepts with more than one parent. In the example below, SNOMED concepts are treated as
+ collections (aggregations) of narrower concepts. We see that the
+ concept <code>:TissueSpecimenFromHeart</code> belongs to two parent collections as it is both a <code>:TissueSpecimen</code> and a <code>:SpecimenFromHeart</code>.
+ This example also demonstrates how composition and aggregation support different scenarios, as the ability to have multiple parents should not be a possibility with composition.
+ </p>
+ <div class="example"><div class="example-title"><span>Example 14</span></div><pre class="example"><code>
+@prefix : <http://example.com/snomed/>.
+@prefix skos: <http://www.w3.org/2004/02/skos/core#> .
+
+:TissueSpecimen a skos:Concept ;
+ :conceptID "119376003";
+ skos:prefLabel "Tissue specimen"
+ skos:narrowerTransitive :TissueSpecimenFromHeart.
+
+:SpecimenFromHeart a skos:Concept ;
+ :conceptID "127462005";
+ skos:prefLabel "Specimen from heart"
+ skos:narrowerTransitive :TissueSpecimenFromHeart.
+
+:TissueSpecimenFromHeart a skos:Concept;
+ :conceptID "128166000";
+ rdfs:label "Tissue specimen from heart".
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f6.2">F6.2</a>)</div>
+ </section>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="uc7">
+ <h3 id="h3_uc7" role="heading" aria-level="2"><span class="secno">4.7 </span><dfn id="dfn-uc7">UC7</dfn>: 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 rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s7.1">
+ <h4 id="h4_s7.1" role="heading" aria-level="3"><span class="secno">4.7.1 </span>Primary scenario: retrieve collection-level description</h4>
+ <p>
+ This scenario, based on <a class="internalDFN" href="#dfn-library-linked-data">Library Linked Data</a>, uses the Dublin Core Metadata Initiative Collection-Level description [<cite><a href="#bib-DC-COLLECTIONS" class="bibref">DC-COLLECTIONS</a></cite>]. 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"><code>
+@prefix dc: <http://purl.org/dc/elements/1.1/>.
+@prefix : <http://example.org/bookshelf/>.
+@prefix dcmitype: <http://purl.org/dc/dcmitype/>.
+@prefix cld: <http://purl.org/cld/terms/>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
+
+<> 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 <http://dir.w3.org>
+ cld:isAccessedVia <http://dir.w3.org/directory/pages/landing-page.xhtml?view>
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f7.1">F7.1</a>)</div>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s7.2">
+ <h4 id="h4_s7.2" role="heading" aria-level="3"><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 class="internalDFN" href="#dfn-library-linked-data">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
+ <code>rdfs:member</code>, 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 (FRBR) ontology [<cite><a href="#bib-FRBR" class="bibref">FRBR</a></cite>] [<cite><a href="#bib-FRBR-CORE" class="bibref">FRBR-CORE</a></cite>].
+ </p>
+ <p>
+ Based on the example below, the item-level description should include as a minimum all the <code>rdfs:member</code> relationships. It need not include other properties of the collection, and it need not include additional properties of the members.
+ </p>
+ <div class="example"><div class="example-title"><span>Example 16</span></div><pre class="example"><code>
+@prefix frbr: <http://purl.org/vocab/frbr/core#>.
+@prefix dc: <http://purl.org/dc/elements/1.1/>.
+@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
+
+<> rdfs:member <#ebooks97>, <#ebooks21279>.
+
+<#work97> a frbr:LiteraryWork;
+ dc:title "Flatland: a romance of many dimensions" ;
+ frbr:creator <#Abbott_Edwin>;
+ frbr:manifestation <ebook97>.
+
+<#work21279> a frbr:LiteraryWork;
+ dc:title "2 B R 0 2 B" ;
+ frbr:creator <#Vonnegut_Kurt>;
+ frbr:manifestation <ebook21279>.
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f7.2">F7.2</a>)</div>
+ </section>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="uc8">
+ <h3 id="h3_uc8" role="heading" aria-level="2"><span class="secno">4.8 </span><dfn id="dfn-uc8">UC8</dfn>: Retrieve a large resource description in multiple parts</h3>
+
+<p>This use case addresses a problem with the “resource-centric” approach to interacting with RDF data. The problem is that some resources participate in a very large number of triples, and therefore a “resource-centric” granularity leads to resource descriptions that are too large to be practically processed in a single HTTP request. This use case applies to all resources, not just containers.</p>
+
+ <ul>
+ <li>It's not really the resource description that's being paginated, but the values of a particular property.</li>
+ <li>The server is responsible for pagination, and may decide how large the pages are.</li>
+ <li>Pagination should apply symmetrically to both <em>incoming</em> and <em>outgoing</em> properties.</li>
+ <li>The next-page URL should be treated as opaque.</li>
+ </ul>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s8.1">
+ <h4 id="h4_s8.1" role="heading" aria-level="3"><span class="secno">4.8.1 </span>Primary scenario: Pagination</h4>
+
+<p>In user story, <a class="internalDFN" href="#dfn-maintaining-social-contact-information">Maintaining Social Contact Information</a>, it is not uncommon for users to have a very large number of contacts.
+This leads to a very large resource description, especially if some basic information about the contacts is included as well. The size of this representation may be so large that retrieval in a single HTTP request is impractical.</p>
+
+<p>In this example the response to the first request includes a reference to the <code>next</code> resource in an ordered collection of resources. For the purposes of the example, we make use of the <code>next</code> property defined by the <a href="http://www.w3.org/1999/xhtml/vocab">XHTML Metainformation Vocabulary</a>. There is no presumption that the <abbr title="Linked Data Platform">LDP</abbr> specification will recommend the use of this vocabulary.</p>
+ <div class="example"><div class="example-title"><span>Example 17</span></div><pre class="example"><code>
+@prefix : <http://example.com/people/>.
+@prefix xhv: <http://www.w3.org/1999/xhtml/vocab#>.
+
+:alice a foaf:Person;
+ rdfs:label "Alice";
+ foaf:mbox <mailto:alice@example.com>.
+
+<> xhv:next <http://example.com/1234567890>.
+ </code></pre></div>
+
+<p>When the client requests the resource identified by <code>next</code>, the response includes additional content that can be merged with the earlier data to construct a more complete model of the originally requested resource. It may also contain further <code>next</code> links, which may be requested in turn.</p>
+
+<p>The following representation is the response to the resource identified by <code>next</code>, completing the contacts list.</p>
+
+ <div class="example"><div class="example-title"><span>Example 18</span></div><pre class="example"><code>
+@prefix : <http://example.com/people/>.
+
+:bob a foaf:Person;
+ rdfs:label "Bob";
+ foaf:mbox <mailto:bob@example.com>.
+ </code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f8.1">F8.1</a>)</div>
+ </section>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="uc9">
+ <h3 id="h3_uc9" role="heading" aria-level="2"><span class="secno">4.9 </span><dfn id="dfn-uc9">UC9</dfn>: Manage binary resources</h3>
+ <p>It should be possible to easily add non-RDF binary resources
+ to containers that accept them. Binary resources may be updated and
+ removed during the lifecycle of the container.</p>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s9.1">
+ <h4 id="h4_s9.1" role="heading" aria-level="3"><span class="secno">4.9.1 </span>Primary scenario: access binary resources</h4>
+ <p>
+ From the user story <a class="internalDFN" href="#dfn-sharing-binary-resources-and-metadata">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 binary resource may be accompanied by an explicit RDF
+ description. 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 19</span></div><pre class="example"><code>
+@prefix ma: <http://www.w3.org/ns/ma-ont#> .
+
+<dataset> a ma:Collection ;
+ ma:hasMember <dataset/image1.jpg>
+
+<dataset/image1.jpg> a ma:MediaResource ;
+ ma:hasFormat "image/jpeg" .
+</code></pre></div>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f9.1">F9.1</a>)</div>
+ </section>
+
+ <section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="s9.2">
+ <h4 id="h4_s9.2" role="heading" aria-level="3"><span class="secno">4.9.2 </span>Alternative scenario: media-resource attachments</h4>
+ <p>
+ A resource may have multiple <em>renditions</em>. For example, 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>
+ <div>(see functional requirement <a class="internalDFN" href="#dfn-f9.2">F9.2</a>)</div>
+ </section>
+ </section>
+</section>
+
+<section id="requirements" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+<!--OddPage--><h2 role="heading" aria-level="1" id="reqs"><span class="secno">5. </span>Requirements</h2>
+<p>This section lists the functional and non-functional requirements arising from the use-cases catalogued in this document. Specific requirements that have been de-prioritized or rejected have been left in the document for completeness, but are shown as struck out.</p>
+<section id="functional-requirements" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="reqs-functional"><span class="secno">5.1 </span>Functional Requirements</h3>
+ <dl>
+ <dt><dfn id="dfn-f1.1">F1.1</dfn>:</dt>
+ <dd>The system shall provide the ability to create containers for composing resources, from <a class="internalDFN" href="#dfn-uc1">UC1</a>.
+ </dd>
+ <dt><dfn id="dfn-f1.2">F1.2</dfn>:</dt>
+ <dd>The system shall provide the ability to create nested containers, from <a class="internalDFN" href="#dfn-uc1">UC1</a>.
+ </dd>
+ <dt><dfn id="dfn-f1.3">F1.3</dfn>:</dt>
+ <dd>On deletion of a container, the system shall delete any contained resources and nested containers, from <a class="internalDFN" href="#dfn-uc1">UC1</a>.
+ </dd>
+ <dt><dfn id="dfn-f2.1">F2.1</dfn>:</dt>
+ <dd>The system shall provide the ability to create resources within a container, from <a class="internalDFN" href="#dfn-uc2">UC2</a>.
+ </dd>
+ <dt><dfn id="dfn-f2.2">F2.2</dfn>:</dt>
+ <dd>The system shall provide the ability to delete resources, from <a class="internalDFN" href="#dfn-uc2">UC2</a>.
+ </dd>
+ <dt><dfn id="dfn-f2.3">F2.3</dfn>:</dt>
+ <dd><span style="text-decoration:line-through;">The system shall provide the ability to move resources between containers, from <a class="internalDFN" href="#dfn-uc2">UC2</a></span>.
+ </dd>
+ <dt><dfn id="dfn-f3.1">F3.1</dfn>:</dt>
+ <dd>The system shall provide the ability to retrieve resource descriptions, from <a class="internalDFN" href="#dfn-uc3">UC3</a>.
+ </dd>
+ <dt><dfn id="dfn-f3.2">F3.2</dfn>:</dt>
+ <dd>The system shall enable the client to retrieve the description of a hash URI, from <a class="internalDFN" href="#dfn-uc3">UC3</a>.
+ </dd>
+ <dt><dfn id="dfn-f4.1">F4.1</dfn>:</dt>
+ <dd>The system shall provide the ability to update an existing resource by substitution, from <a class="internalDFN" href="#dfn-uc4">UC4</a>.
+ </dd>
+ <dt><dfn id="dfn-f4.2">F4.2</dfn>:</dt>
+ <dd>The system shall provide the ability to perform a selective update of a resource, from <a class="internalDFN" href="#dfn-uc4">UC4</a>.
+ </dd>
+ <dt><dfn id="dfn-f5.1">F5.1</dfn>:</dt>
+ <dd>The system shall provide the ability to determine if a resource has changed, from <a class="internalDFN" href="#dfn-uc5">UC5</a>.
+ </dd>
+ <dt><dfn id="dfn-f6.1">F6.1</dfn>:</dt>
+ <dd>The system shall provide the ability to aggregate resources, from <a class="internalDFN" href="#dfn-uc6">UC6</a>.
+ </dd>
+ <dt><dfn id="dfn-f6.2">F6.2</dfn>:</dt>
+ <dd>The system shall support the addition of a resource to multiple aggregations, from <a class="internalDFN" href="#dfn-uc6">UC6</a>.
+ </dd>
+ <dt><dfn id="dfn-f7.1">F7.1</dfn>:</dt>
+ <dd>The system shall provide the ability to retrieve a collection-level description of a composition, from <a class="internalDFN" href="#dfn-uc7">UC7</a>.
+ </dd>
+ <dt><dfn id="dfn-f7.2">F7.2</dfn>:</dt>
+ <dd>The system shall provide the ability to retrieve an item-level description of a composition or aggregation, from <a class="internalDFN" href="#dfn-uc7">UC7</a>.
+ </dd>
+ <dt><dfn id="dfn-f8.1">F8.1</dfn></dt>
+ <dd>The system shall provide the ability to retrieve a paginated description of a composition or aggregation, from <a class="internalDFN" href="#dfn-uc8">UC8</a>.
+ </dd>
+ <dt><dfn id="dfn-f9.1">F9.1</dfn>:</dt>
+ <dd>The system shall provide the ability to store and access media resources, from <a class="internalDFN" href="#dfn-uc9">UC9</a>
+ </dd>
+ <dt><dfn id="dfn-f9.2">F9.2</dfn>:</dt>
+ <dd><span style="text-decoration:line-through;">The system shall provide the ability to add media-resource attachments, from <a class="internalDFN" href="#dfn-uc9">UC9</a>.</span>
+ </dd>
+ </dl>
+ </section>
+
+ <section id="non-functional-requirements" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter">
+ <h3 role="heading" aria-level="2" id="reqs-non-functional"><span class="secno">5.2 </span>Non-Functional Requirements</h3>
+ <dl>
+ <dt><dfn id="dfn-nf1.1">NF1.1</dfn>:</dt>
+ <dd>The system shall provide access guidance to resources, from <a class="internalDFN" href="#dfn-uc1">UC1</a>.
+ </dd>
+ <dt><dfn id="dfn-nf2.1">NF2.1</dfn>:</dt>
+ <dd>The system shall encourage non-duplication of resources, from <a class="internalDFN" href="#dfn-uc2">UC2</a>.
+ </dd>
+ <dt><dfn id="dfn-nf2.2">NF2.2</dfn>:</dt>
+ <dd>The system shall support distribution of resources, from <a class="internalDFN" href="#dfn-uc2">UC2</a>.
+ </dd>
+ <dt><dfn id="dfn-nf2.3">NF2.3</dfn>:</dt>
+ <dd>The system shall support consistent, global naming, from <a class="internalDFN" href="#dfn-uc2">UC2</a>.
+ </dd>
+ <dt><dfn id="dfn-nf3.1">NF3.1</dfn>:</dt>
+ <dd>The system shall support the use of standard vocabularies where appropriate, from <a class="internalDFN" href="#dfn-uc3">UC3</a>.
+ </dd>
+ <dt><dfn id="dfn-nf3.2">NF3.2</dfn>:</dt>
+ <dd>The system shall provide a scalable linking model, from <a class="internalDFN" href="#dfn-uc3">UC3</a>.
+ </dd>
+ <dt><dfn id="dfn-nf4.1">NF4.1</dfn>:</dt>
+ <dd>The system shall permit unrestricted vocabulary, from <a class="internalDFN" href="#dfn-uc4">UC4</a>.
+ </dd>
+ <dt><dfn id="dfn-nf5.1">NF5.1</dfn>:</dt>
+ <dd>The <abbr title="Linked Data Platform">LDP</abbr> shall ensure consistent access in the case of multiple simultaneous attempts to access a resource, from <a class="internalDFN" href="#dfn-uc5">UC5</a>.
+ </dd>
+ <dt><dfn id="dfn-nf6.1">NF6.1</dfn>:</dt>
+ <dd>The system shall allow resource descriptions that are a "mix of simple data and collections", from <a class="internalDFN" href="#dfn-uc6">UC6</a>.
+ </dd>
+ <dt><dfn id="dfn-nf6.2">NF6.2</dfn>:</dt>
+ <dd>The system shall support relative URIs enabling sharing of collections, from <a class="internalDFN" href="#dfn-uc6">UC6</a>.
+ </dd>
+ </dl>
+ </section>
+</section>
+
+
+<section id="acknowledgements-1" rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" class="appendix informative">
+<!--OddPage--><h2 role="heading" aria-level="1" id="acknowledgements"><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>
+
+<!--section class='appendix informative' id="history">
+<h1>Change History</h1>
+<ul>
+ <li>2012-12-14 - Initial ReSpec'ing framework for <a href="http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements">Workgroup working wiki document</a> (SS)</li>
+ <li>2012-12-16 - Pulled in and ReSpec'd content from <a href="http://www.w3.org/2012/ldp/wiki/Use_Cases_And_Requirements">Workgroup working wiki document</a> (SS)</li>
+ <li>2012-12-16 - Fixed cross section links and initial pass at biblio refs (SS)</li>
+</ul></section-->
+
+
+
+<section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="references" class="appendix"><!--OddPage--><h2 id="h2_references" role="heading" aria-level="1"><span class="secno">B. </span>References</h2><section rel="bibo:Chapter" resource="#ref" typeof="bibo:Chapter" id="informative-references"><h3 id="h3_informative-references" role="heading" aria-level="2"><span class="secno">B.1 </span>Informative references</h3><dl about="" class="bibliography"><dt id="bib-6LOWPAN">[6LOWPAN]</dt><dd rel="dcterms:references"><a href="http://datatracker.ietf.org/wg/6lowpan/"><cite>IPv6 over Low power WPAN</cite></a>. URL: <a href="http://datatracker.ietf.org/wg/6lowpan/">http://datatracker.ietf.org/wg/6lowpan/</a>
+</dd><dt id="bib-ADMS">[ADMS]</dt><dd rel="dcterms:references"><a href="http://joinup.ec.europa.eu/asset/adms/home"><cite>Asset Description Metadata Schema</cite></a>. URL: <a href="http://joinup.ec.europa.eu/asset/adms/home">http://joinup.ec.europa.eu/asset/adms/home</a>
+</dd><dt id="bib-BBC-SPORT">[BBC-SPORT]</dt><dd rel="dcterms:references">J. Rayfield; P. Wilton; S. Oliver. <a href="http://www.bbc.co.uk/ontologies/sport/2011-02-17.shtml"><cite>Sport Ontology</cite></a>. URL: <a href="http://www.bbc.co.uk/ontologies/sport/2011-02-17.shtml">http://www.bbc.co.uk/ontologies/sport/2011-02-17.shtml</a>
+</dd><dt id="bib-CHANGESET">[CHANGESET]</dt><dd rel="dcterms:references">S. Tunnicliffe; I. Davis. <a href="http://vocab.org/changeset/schema.html"><cite>Changeset</cite></a>. URL: <a href="http://vocab.org/changeset/schema.html">http://vocab.org/changeset/schema.html</a>
+</dd><dt id="bib-COAP">[COAP]</dt><dd rel="dcterms:references"><a href="http://tools.ietf.org/html/draft-ietf-core-coap-18"><cite>Constrained Application Protocol</cite></a>. URL: <a href="http://tools.ietf.org/html/draft-ietf-core-coap-18">http://tools.ietf.org/html/draft-ietf-core-coap-18</a>
+</dd><dt id="bib-COAP-MAP">[COAP-MAP]</dt><dd rel="dcterms:references"><a href="http://tools.ietf.org/html/draft-castellani-core-http-mapping-07"><cite>Best Practices for HTTP-CoAP Mapping Implementation</cite></a>. URL: <a href="http://tools.ietf.org/html/draft-castellani-core-http-mapping-07">http://tools.ietf.org/html/draft-castellani-core-http-mapping-07</a>
+</dd><dt id="bib-COCKBURN-2000">[COCKBURN-2000]</dt><dd rel="dcterms:references">Alistair Cockburn. <a href="http://alistair.cockburn.us/get/2465"><cite>Writing Effective Use Cases</cite></a>. 2000. URL: <a href="http://alistair.cockburn.us/get/2465">http://alistair.cockburn.us/get/2465</a>
+</dd><dt id="bib-COHN-2004">[COHN-2004]</dt><dd rel="dcterms:references">Mike Cohn. <a href="http://www.mountaingoatsoftware.com/books/user-stories-applied"><cite>User Stories Applied: For Agile Software Development</cite></a>. 2004. URL: <a href="http://www.mountaingoatsoftware.com/books/user-stories-applied">http://www.mountaingoatsoftware.com/books/user-stories-applied</a>
+</dd><dt id="bib-COOLURIS">[COOLURIS]</dt><dd rel="dcterms:references">Leo Sauermann; Richard Cyganiak. <a href="http://www.w3.org/TR/cooluris"><cite>Cool URIs for the Semantic Web</cite></a>. 3 December 2008. W3C Note. URL: <a href="http://www.w3.org/TR/cooluris">http://www.w3.org/TR/cooluris</a>
+</dd><dt id="bib-DAP-REQS">[DAP-REQS]</dt><dd rel="dcterms:references">Robin Berjon et al. <a href="http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/"><cite>Device API Requirementsml</cite></a>. 15 October 2009. Working Group Note. URL: <a href="http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/">http://www.w3.org/TR/2009/NOTE-dap-api-reqs-20091015/</a>
+</dd><dt id="bib-DC-COLLECTIONS">[DC-COLLECTIONS]</dt><dd rel="dcterms:references"><a href="http://dublincore.org/groups/collections/collection-application-profile/"><cite>Dublin Core Collections Application Profile</cite></a>. URL: <a href="http://dublincore.org/groups/collections/collection-application-profile/">http://dublincore.org/groups/collections/collection-application-profile/</a>
+</dd><dt id="bib-DCAT-UCR">[DCAT-UCR]</dt><dd rel="dcterms:references">R. Cyganiak; F. Maali.. <a href="http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html"><cite>Use Cases and Requirements for the Data Catalog Vocabulary</cite></a>. 16 December 2012. W3C Editor's Draft. URL: <a href="http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html">http://dvcs.w3.org/hg/gld/raw-file/default/dcat-ucr/index.html</a>
+</dd><dt id="bib-FOAF">[FOAF]</dt><dd rel="dcterms:references">Dan Brickley, Libby Miller. <a href="http://xmlns.com/foaf/spec/"><cite>FOAF Vocabulary Specification 0.98.</cite></a> 9 August 2010. URL: <a href="http://xmlns.com/foaf/spec/">http://xmlns.com/foaf/spec/</a>
+</dd><dt id="bib-FRBR">[FRBR]</dt><dd rel="dcterms:references"><a href="http://www.ifla.org/publications/functional-requirements-for-bibliographic-records"><cite>Functional Requirements for Bibliographic Records</cite></a>. URL: <a href="http://www.ifla.org/publications/functional-requirements-for-bibliographic-records">http://www.ifla.org/publications/functional-requirements-for-bibliographic-records</a>
+</dd><dt id="bib-FRBR-CORE">[FRBR-CORE]</dt><dd rel="dcterms:references">I. Davis; R. Newman. <a href="http://vocab.org/frbr/core.html"><cite>Expression of Core FRBR Concepts in RDF</cite></a>. URL: <a href="http://vocab.org/frbr/core.html">http://vocab.org/frbr/core.html</a>
+</dd><dt id="bib-LINKED-DATA">[LINKED-DATA]</dt><dd rel="dcterms:references">Tim Berners-Lee. <a href="http://www.w3.org/DesignIssues/LinkedData.html"><cite>Linked Data Design Issues</cite></a>. 27 July 2006. W3C-Internal Document. URL: <a href="http://www.w3.org/DesignIssues/LinkedData.html">http://www.w3.org/DesignIssues/LinkedData.html</a>
+</dd><dt id="bib-LINKED-DATA-PLATFORM">[LINKED-DATA-PLATFORM]</dt><dd rel="dcterms:references">Steve Speicher; John Arwe; Ashok Malhotra. <a href="http://www.w3.org/TR/ldp/"><cite>Linked Data Platform 1.0</cite></a>. 30 July 2013. W3C Last Call Working Draft. URL: <a href="http://www.w3.org/TR/ldp/">http://www.w3.org/TR/ldp/</a>
+</dd><dt id="bib-LLD-UC">[LLD-UC]</dt><dd rel="dcterms:references">D. Vila Suero. <a href="http://www.w3.org/2005/Incubator/lld/XGR-lld-usecase-20111025/"><cite>Library Linked Data Incubartor Group: Use Cases</cite></a>. 25 October 2011. W3C Incubator Group Report. URL: <a href="http://www.w3.org/2005/Incubator/lld/XGR-lld-usecase-20111025/">http://www.w3.org/2005/Incubator/lld/XGR-lld-usecase-20111025/</a>
+</dd><dt id="bib-MEDIA-FRAGMENTS-REQS">[MEDIA-FRAGMENTS-REQS]</dt><dd rel="dcterms:references">Raphaël Troncy; Erik Mannens. <a href="http://www.w3.org/TR/media-frags-reqs"><cite>Use cases and requirements for Media Fragments</cite></a>. 17 December 2009. W3C Working Draft. URL: <a href="http://www.w3.org/TR/media-frags-reqs">http://www.w3.org/TR/media-frags-reqs</a>
+</dd><dt id="bib-MEDIAONT">[MEDIAONT]</dt><dd rel="dcterms:references">WonSuk Lee; Werner Bailer; Tobias Bürger; Pierre-Antoine Champin; Jean-Pierre EVAIN; Véronique Malaisé; Thierry Michel; Felix Sasaki; Joakim Söderberg; Florian Stegmaier; John Strassner. <a href="http://www.w3.org/TR/mediaont-10/"><cite>Ontology for Media Resources 1.0</cite></a>. 9 February 2012. W3C Recommendation. URL: <a href="http://www.w3.org/TR/mediaont-10/">http://www.w3.org/TR/mediaont-10/</a>
+</dd><dt id="bib-ORG-ONT">[ORG-ONT]</dt><dd rel="dcterms:references">D. Reynolds. <a href="http://www.epimorphics.com/public/vocabulary/org.html"><cite>An organization ontology</cite></a>. URL: <a href="http://www.epimorphics.com/public/vocabulary/org.html">http://www.epimorphics.com/public/vocabulary/org.html</a>
+</dd><dt id="bib-OSLC">[OSLC]</dt><dd rel="dcterms:references"><a href="http://open-services.net/"><cite>Open Services for Lifecycle Collaboration</cite></a>. URL: <a href="http://open-services.net/">http://open-services.net/</a>
+</dd><dt id="bib-POWDER-USE-CASES">[POWDER-USE-CASES]</dt><dd rel="dcterms:references">Phil Archer. <a href="http://www.w3.org/TR/powder-use-cases/"><cite>POWDER: Use Cases and Requirements</cite></a>. 31 October 2007. W3C Note. URL: <a href="http://www.w3.org/TR/powder-use-cases/">http://www.w3.org/TR/powder-use-cases/</a>
+</dd><dt id="bib-RDB2RDF-UC">[RDB2RDF-UC]</dt><dd rel="dcterms:references">Eric Prud'hommeaux; Michael Hausenblas. <a href="http://www.w3.org/TR/rdb2rdf-ucr/"><cite>Use Cases and Requirements for Mapping Relational Databases to RDF</cite></a>. 8 June 2010. W3C Working Draft. URL: <a href="http://www.w3.org/TR/rdb2rdf-ucr/">http://www.w3.org/TR/rdb2rdf-ucr/</a>
+</dd><dt id="bib-RDF-SPARQL-UPDATE">[RDF-SPARQL-UPDATE]</dt><dd rel="dcterms:references">Paul Gearon; Alexandre Passant; Axel Polleres. <a href="http://www.w3.org/TR/sparql11-update/"><cite>SPARQL 1.1 Update</cite></a>. 21 March 2013. W3C Recommendation. URL: <a href="http://www.w3.org/TR/sparql11-update/">http://www.w3.org/TR/sparql11-update/</a>
+</dd><dt id="bib-RESEARCH-OBJECTS">[RESEARCH-OBJECTS]</dt><dd rel="dcterms:references">K Belhajjame et al. <a href="http://ceur-ws.org/Vol-903/paper-01.pdf"><cite>Workflow-Centric Research Objects: First Class Citizens in Scholarly Discourse</cite></a>. URL: <a href="http://ceur-ws.org/Vol-903/paper-01.pdf">http://ceur-ws.org/Vol-903/paper-01.pdf</a>
+</dd><dt id="bib-SNOMED">[SNOMED]</dt><dd rel="dcterms:references"><a href="http://www.ihtsdo.org/snomed-ct/"><cite>SNOMED CT</cite></a>. URL: <a href="http://www.ihtsdo.org/snomed-ct/">http://www.ihtsdo.org/snomed-ct/</a>
+</dd><dt id="bib-SSN">[SSN]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/2005/Incubator/ssn/XGR-ssn/"><cite>Semantic Sensor Network XG Final Report</cite></a>. URL: <a href="http://www.w3.org/2005/Incubator/ssn/XGR-ssn/">http://www.w3.org/2005/Incubator/ssn/XGR-ssn/</a>
+</dd><dt id="bib-WEBARCH">[WEBARCH]</dt><dd rel="dcterms:references">Ian Jacobs; Norman Walsh. <a href="http://www.w3.org/TR/webarch/"><cite>Architecture of the World Wide Web, Volume One</cite></a>. 15 December 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/webarch/">http://www.w3.org/TR/webarch/</a>
+</dd><dt id="bib-WOT">[WOT]</dt><dd rel="dcterms:references"><a href="http://www.w3.org/community/wot/"><cite>Web of Things Community Group</cite></a>. URL: <a href="http://www.w3.org/community/wot/">http://www.w3.org/community/wot/</a>
+</dd><dt id="bib-XO">[XO]</dt><dd rel="dcterms:references"><a href="http://worldwidesemanticweb.org/projects/semanticxo/"><cite>SemanticXO</cite></a>. URL: <a href="http://worldwidesemanticweb.org/projects/semanticxo/">http://worldwidesemanticweb.org/projects/semanticxo/</a>
+</dd><dt id="bib-vocab-dcat">[vocab-dcat]</dt><dd rel="dcterms:references">Fadi Maali; John Erickson. <a href="http://www.w3.org/TR/vocab-dcat/"><cite>Data Catalog Vocabulary (DCAT)</cite></a>. 16 January 2014. W3C Recommendation. URL: <a href="http://www.w3.org/TR/vocab-dcat/">http://www.w3.org/TR/vocab-dcat/</a>
+</dd></dl></section></section></body></html>
\ No newline at end of file