cosmetic chnages to UC&R use cases.
authorsteve.battle <steve.battle@sysemia.co.uk>
Mon, 08 Jul 2013 14:42:48 +0100
changeset 156 9dafe5f2b2e8
parent 155 e960d5f2cd9e
child 157 3117cd615572
cosmetic chnages to UC&R use cases.
ldp-ucr.html
--- a/ldp-ucr.html	Mon Jul 08 14:22:56 2013 +0100
+++ b/ldp-ucr.html	Mon Jul 08 14:42:48 2013 +0100
@@ -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 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 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>
@@ -741,16 +741,16 @@
 <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
+		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
@@ -762,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
@@ -781,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>
@@ -804,10 +803,10 @@
 	<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
+		<code>oslc_cm:attachment</code>. The 'top-level-container' contains issues, and
 		each issue resource has its own container of attachment resources.
 	</p>
 	<pre class='example'>
@@ -884,7 +883,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
@@ -987,7 +986,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
@@ -1079,7 +1078,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/"
@@ -1126,7 +1125,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
@@ -1188,7 +1187,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
@@ -1424,7 +1423,7 @@
 		<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>
@@ -1625,7 +1624,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>