--- a/ldp-ucr.html Mon Jul 08 11:17:22 2013 -0400
+++ b/ldp-ucr.html Mon Jul 08 11:18:19 2013 -0400
@@ -104,8 +104,8 @@
<section id='abstract'>
<p>
To foster the development of the Linked Data Platform specification, this document includes a set of user stories, use cases, scenarios and requirements that motivate a simple read-write Linked Data architecture, based on HTTP access to web resources that describe their state using RDF.
- The starting point for the development of these use-cases is a collection of user-stories that provide realistic examples that describe how people may use read-write Linked Data. The use-cases themselves are captured in a narrative style that describes a
- behavior, or set of behaviors based on, and using scenarios from, these user-stories. The aim throughout has been to avoid details of protocol (specifically
+ The starting point for the development of these use cases is a collection of user stories that provide realistic examples describing how people may use read-write Linked Data. The use cases themselves are captured in a narrative style that describes a
+ behavior, or set of behaviors based on, and using scenarios from, these user stories. The aim throughout has been to avoid details of protocol (specifically
the HTTP protocol), and use of any specific vocabulary that might be introduced by the
<abbr title="Linked Data Platform">LDP</abbr> specification.
</p>
@@ -159,13 +159,12 @@
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 [[DAP-REQS]] for a good example
+ number of (functional) use cases and other non-functional
+ requirements. See <em>Device API Access Control Use Cases and Requirements</em> [[DAP-REQS]] 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
+ <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"
@@ -178,32 +177,26 @@
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 [[RDB2RDF-UC]]. A variety of styles may be used to capture use-cases,
+ use case indexing in this document is based on rdb2rdf
+ use cases [[RDB2RDF-UC]]. 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 [[POWDER-USE-CASES]], 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>
+ pre/post conditions, step-by-step behaviors (as in POWDER:
+ Use Cases and Requirements [[POWDER-USE-CASES]]), and non-functional requirements
+ raised by the use case.</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 [[MEDIA-FRAGMENTS-REQS]], to being formally
- modeled as interaction diagrams. Each use-case should include at
+ <li><b>Scenarios</b> are used to model the functional requirements of a use case and focus on a use case in action. Scenarios may range from
+ lightweight narratives as seen in <em>Use
+ cases and requirements for Media Fragments</em> [[MEDIA-FRAGMENTS-REQS]], to being formally
+ modeled as interaction diagrams. Each use case includes at
least a primary scenario, and possibly other alternative
scenarios.</li>
</ul>
<ul>
<li><b><a href="#reqs" title="Requirements">Requirements</a></b>
- 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 [[DCAT-UCR]]. 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>
+ list functional and non-functional or quality requirements, and the use cases
+ they may be derived from. This approach is exemplified in the <em>Use Cases and Requirements for the Data
+ Catalog Vocabulary</em> [[DCAT-UCR]].</li>
</ul>
</section>
@@ -235,7 +228,7 @@
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
+ 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>
@@ -266,12 +259,8 @@
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>
+ applications to interact with the data about us, and we
+ have to use their identifier(s) for us.</p>
<p>
Would it not be simpler if at least the Web-addressable portion of
that data could be linked to consistently, so that instead of
@@ -282,8 +271,7 @@
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.
+ consistent application interface that they all supported?
</p>
<p>
Our set of links would probably be a <a
@@ -299,8 +287,7 @@
</section>
<section>
- <h2 id="story-oslc">System and Software Development
- Tool Integration</h2>
+ <h2 id="story-oslc">System and Software Development Tool Integration</h2>
<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
@@ -348,7 +335,7 @@
<section>
<h2 id="story-lld">Library Linked Data</h2>
<p>
- The W3C Library Linked Data working group has a number of use
+ The W3C Library Linked Data Working Group has a number of use
cases cited in their Use Case Report [[LLD-UC]]. 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,
@@ -358,7 +345,7 @@
full extractions and import of data.
</p>
<p>The 'Digital Objects Cluster' contains a number of relevant
- use-cases:</p>
+ use cases:</p>
<ul>
<li>Grouping: This should "Allow the end-users to define <a
href="#uc-aggregate_resources" title="">groups of resources</a>
@@ -386,7 +373,7 @@
elsewhere on the linked Web."</li>
</ul>
<p>The 'Collections' cluster also contains a number of relevant
- use-cases:</p>
+ use cases:</p>
<ul>
<li>Collection-level description: "Provide <a
href="#uc-filter_resource_description" title="">metadata
@@ -408,8 +395,7 @@
</section>
<section>
- <h2 id="story-meter_monitoring">Municipality Operational
- Monitoring</h2>
+ <h2 id="story-meter_monitoring">Municipality Operational Monitoring</h2>
<p>
Across various cities, towns, counties, and various municipalities
there is a growing number of services managed and run by
@@ -440,7 +426,7 @@
<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
+ the patient’s data. If the patient experiences adverse effects
from medications, these physicians need to publish information
about this to an appropriate regulatory source. Other medical
professionals require access to both validated and emerging
@@ -516,7 +502,7 @@
</section>
<section>
- <h2 id="story-low-end_devices">Sharing payload of RDF data among low-end devices</h2>
+ <h2 id="story-low-end_devices">Sharing Payload of RDF Data Among Low-End Devices</h2>
<p>
Several projects around the idea of <a
href="http://worldwidesemanticweb.wordpress.com/"
@@ -538,7 +524,7 @@
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>
+ with a lightweight column store would be a better approach.</p>
</section>
<section>
@@ -549,27 +535,27 @@
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>
+ 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
+ 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
+ metadata about the image) that are not distinguished from the
platform's point-of-view.</p>
</section>
<section>
<h2 id="story-data_catalogs">Data Catalogs</h2>
<p>
- The Asset Description Metadata Schema (<a
+ The <em>Asset Description Metadata Schema</em> (<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
@@ -594,7 +580,7 @@
<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
+ their repository descriptions and contained assets in a Linked Data
compatible manner. ADMS provides the necessary data model to
enable meaningful exchange of data. However, this leaves the
challenge of efficient access to the data not fully addressed.</p>
@@ -622,8 +608,8 @@
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
+ - IPv6 for resource constrained devices - and the <em>Constrained
+ Application Protocol</em> (<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
@@ -632,7 +618,7 @@
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
+ and memory) a solution based on <em>SPARQL Update</em> 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"
@@ -754,17 +740,17 @@
<section>
<h1 id="usecases">Use Cases</h1>
- <p>The following use-cases are each derived from one or more of
- the user-stories above. These use-cases are explored in detail
+ <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
+ 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>
<h2 id="uc-manage_containers">Use Case: Manage containers</h2>
<p>
- A number of user-stories introduce the idea of a <i>container</i>
+ 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
@@ -776,16 +762,15 @@
invoked by exchanging RDF documents.
</p>
<ul>
- <li>Provide "access guidance for ... resources" (affordances)
- (from user-story, <a
+ <li>Provide "access guidance" (affordances)
+ (from user story, <a
href="#story-social" title="Social Contacts">Maintaining
Social Contact Information</a>).
</li>
</ul>
<section>
- <h3 id="scen-create_container">Primary scenario: create
- container</h3>
+ <h3 id="scen-create_container">Primary scenario: create a container</h3>
<p>
Create a new container resource within the LDP server. In <a
href="#story-process_of_science" title="">Services
@@ -795,10 +780,10 @@
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"
+ to aggregate <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
+ research object begins life as an empty container (see below) into which
workflows, datasets, results and other data will be added
throughout the lifecycle of the project.
</p>
@@ -818,11 +803,11 @@
<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
+ 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.
+ <code>oslc_cm:attachment</code>. This may be viewed as nested containment. The 'top-level-container' contains issues, and
+ each issue is itself a container of attachments.
</p>
<pre class='example'>
@prefix dcterms: <http://purl.org/dc/terms/>.
@@ -835,11 +820,7 @@
: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".
+ oslc_cm:attachments :attachments.
:attachments a oslc_cm:AttachmentList;
oslc_cm:attachment :attachment324, :attachment251.
@@ -850,30 +831,17 @@
<section>
<h2 id="uc-manage_resources">Use Case: Manage resources</h2>
<p>
- This use-case addresses the managed lifecycle of a resource and is
+ 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
+ managing resources belongs to their container. For example, a
container may accept a request from a client to make a new
- resource. This use-case focuses on creation and deletion of
+ 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 LDP
- server could support something like the Atom
- Publishing Protocol slug header to convey a user defined naming
- 'hint' [[RFC5023]].
- </p>
<ul>
<li>Non-duplication of resources: "Eliminate multiple
copies", representing resources in a single place (from <a
@@ -898,7 +866,7 @@
<h3 id="scen-create_resource">Primary scenario: create resource</h3>
<p>
Resources begin life by being created within a container. From
- user-story, <a href="#story-social" title="Story Social Informatinon">
+ 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
@@ -1001,7 +969,7 @@
<section>
<h3 id="scen-fetch">Primary scenario</h3>
<p>
- The user-story <a
+ The user story <a
href="#story-project_data"
title=""> Project Membership Information</a> discusses the
representation of information about people and projects. It calls
@@ -1093,7 +1061,7 @@
<section>
<h3 id="scen-update_enrichment">Primary scenario: enrichment</h3>
<p>
- This relates to user-story <a
+ 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/"
@@ -1140,7 +1108,7 @@
<h3 id="scen-alt_selective_update">Alternative scenario: selective
update of a resource</h3>
<p>
- This relates to user-story <a href="#story-data_catalogs" title="">Data
+ 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
@@ -1202,7 +1170,7 @@
<section>
<h3 id="scen-primary_has_changed">Primary scenario</h3>
<p>
- Based on the user-story, <a
+ Based on the user story, <a
href="#story-constrained_devices" title="">
Constrained Devices and Networks</a>, an LDP server could be configured to
act as a proxy for a CoAP [[COAP]] based <a
@@ -1346,7 +1314,7 @@
<section>
<h2 id="uc-filter_resource_description">Use Case: Filter resource description</h2>
- <p>This use-case extends the normal behaviour of retrieving an
+ <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
@@ -1387,7 +1355,7 @@
<h3 id="scen-retrieve_item-level_description_of_a_collection">Alternative scenario: retrieve
item-level description of a collection</h3>
<p>
- This use-case scenario, also based on <a
+ 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
@@ -1426,7 +1394,7 @@
<section>
<h2 id="uc-pagination">Use case: Retrieve a large resource description in multiple parts</h2>
-<p>This use case addresses a problem with the “resource-centric” approach to interacting with RDF data. The problem is that some resources participate in a very large number of triples, and therefore a “resource-centric” granularity leads to resource descriptions that are too large to be practically processed in a single HTTP request. This use-case applies to all resources, not just containers.</p>
+<p>This use case addresses a problem with the “resource-centric” approach to interacting with RDF data. The problem is that some resources participate in a very large number of triples, and therefore a “resource-centric” granularity leads to resource descriptions that are too large to be practically processed in a single HTTP request. This use case applies to all resources, not just containers.</p>
<ul>
<li>It's not really the resource description that's being paginated, but the values of a particular property.</li>
@@ -1438,10 +1406,10 @@
<section>
<h3 id="scen-access_media_resources">Primary scenario: large numbers of contacts</h3>
-<p>In user-story, <a href="#story-social" title="Social Contacts">Maintaining Social Contact Information</a>, it is not uncommon for users to have a very large number of contacts.
+<p>In user story, <a href="#story-social" title="Social Contacts">Maintaining Social Contact Information</a>, it is not uncommon for users to have a very large number of contacts.
This leads to a very large resource description, especially if some basic information about the contacts is included as well. The size of this representation may be so large that retrieval in a single HTTP request is impractical.</p>
-<p>In this example the response to the first request includes a reference to the <i>next</i> resource in an ordered collection of resources. For the purposes of the example, we make use of the <i>next</i> property defined by the <a href="http://www.w3.org/1999/xhtml/vocab/">XHTML Metainformation Vocabulary</a>. There should be no presumption that the LDP specification will recommend the use of this vocabulary to support this use-case.</p>
+<p>In this example the response to the first request includes a reference to the <i>next</i> resource in an ordered collection of resources. For the purposes of the example, we make use of the <i>next</i> property defined by the <a href="http://www.w3.org/1999/xhtml/vocab/">XHTML Metainformation Vocabulary</a>. There should be no presumption that the LDP specification will recommend the use of this vocabulary to support this use case.</p>
<pre class='example'>
@prefix : <http://example.com/people/>.
@prefix xhv: <http://www.w3.org/1999/xhtml/vocab#>.
@@ -1639,7 +1607,7 @@
<section class='appendix informative'>
<h2>Acknowledgements</h2>
-<p>We would like to acknowledge the contributions of user-story authors: Christophe Guéret,
+<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>