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