--- a/ldp-ucr.html Mon Jul 08 13:04:30 2013 +0100
+++ b/ldp-ucr.html Mon Jul 08 14:05:18 2013 +0100
@@ -104,7 +104,7 @@
<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
+ 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.
@@ -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>
@@ -358,7 +351,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 +379,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
@@ -754,8 +747,8 @@
<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
contain are included purely for illustrative purposes, and should
@@ -850,11 +843,11 @@
<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
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
@@ -1346,7 +1339,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 +1380,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 +1419,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>
@@ -1441,7 +1434,7 @@
<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#>.