2013-01-03 - Fixed Typos. Rewording for clarity. (JA)
authorJohn Arwe <johnarwe@us.ibm.com>
Thu, 03 Jan 2013 16:49:09 -0500
changeset 34 e82a925b73b7
parent 33 3c8c101f3f97
child 35 a70ab3ad21aa
2013-01-03 - Fixed Typos. Rewording for clarity. (JA)
ldp-ucr.html
--- a/ldp-ucr.html	Fri Dec 28 15:18:04 2012 -0500
+++ b/ldp-ucr.html	Thu Jan 03 16:49:09 2013 -0500
@@ -103,7 +103,7 @@
 <body>
 <section id='abstract'>
 A set of user stories, use cases, scenarios and requirements that motivate a simple 
-approach for a read-write Linked Data architecture, based on HTTP access to web 
+read-write Linked Data architecture, based on HTTP access to web 
 resources that describe their state using RDF.
 </section>
 
@@ -168,8 +168,8 @@
 		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 Basic Profile for
-		Linked Data to achieve interoperability.</p>
+		existing technologies in the construction of a 
+		[[LINKED-DATA-PLATFORM]] to achieve interoperability.</p>
 	<p>The following list illustrates a few of the issues that
 		require additional rules and patterns:</p>
 	<ul>
@@ -184,7 +184,7 @@
 		<li>What standard vocabularies should I use?</li>
 		<li>What primitive data types should I use?</li>
 	</ul>
-	<p>A good goal for the Basic Profile for Linked Data would be
+	<p>A good goal for the [[LINKED-DATA-PLATFORM]] 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
@@ -202,7 +202,8 @@
  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 LDP specification.
+ 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>
@@ -297,7 +298,7 @@
 		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> and add it to my contacts and when deleting 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.
@@ -349,7 +350,7 @@
 			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 of its collection
+			title="">a collection of accounts for each member of its collection
 			of customers</a>.
 	</p>
 	</section>
@@ -395,9 +396,9 @@
 		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
+		technology has a strong appeal <a
 			href="http://open-services.net/" class="external text"
-			title="http://open-services.net/" rel="nofollow">OSLC</a>
+			title="http://open-services.net/" rel="nofollow">OSLC</a>.
 	</p>
 	</section>
 	
@@ -527,11 +528,11 @@
 	</ul>
 	<p>This comes in support of more effective information
 		management and data/content mining (if you can't find your
-		content, it' like if you don't have and must either recreate or
+		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
+		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>
@@ -588,12 +589,12 @@
 	</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, one of the project
-		"SemanticXO" uses named graphs and the graph protocol to
+		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 store
-		are rather demanding piece of software that are not always usable
-		on limited hardware. Some generic ReST like interaction backed up
+		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>
 	
@@ -606,19 +607,19 @@
 		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 LinkedData contains information about resources that are
-		most naturally expressed in non-rdf formats (be they binary such
+	<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
+		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 in the image file but better external
+		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 (being
-		application metadata about the image does not distinguish from the
+		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>
 	
@@ -628,9 +629,9 @@
 		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 assets repositories
+		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 assets
+		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="">
@@ -640,7 +641,7 @@
 		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 to:
+		Warehousing, the federation requires one to:
 	</p>
 	<ul>
 		<li>understand the data, i.e. understand their semantic
@@ -649,10 +650,10 @@
 			different repositories</li>
 		<li>keep itself up-to-date.</li>
 	</ul>
-	<p>Repositories owners can maintain de-referenceable URIs for
+	<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
+		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/"
@@ -714,7 +715,7 @@
 			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 in
+			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
@@ -752,8 +753,8 @@
 		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 with the project team
-		itself, not requiring updates to be requested of a centralised
+		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>
@@ -923,7 +924,7 @@
 		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 LDP has ultimate control over
+		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
@@ -936,7 +937,7 @@
 			href="#story-social" title="Story Social Informatinon">#Maintaining
 				Social Contact Information</a>).
 		</li>
-		<li>Distribution of resources: Linked aata "may be stored on
+		<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>).
@@ -1023,7 +1024,7 @@
 		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 LDP naming policy. While assigning a
+		depending upon the specific server naming policy. While assigning a
 		new URI to a resource is discouraged [[WEBARCH]], it is possible to indicate that a
 		resource has moved with an appropriate HTTP response.
 	</p>
@@ -1037,7 +1038,7 @@
 		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
-		LDP may enrich the retrieved RDF with additional triples. Examples
+		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
@@ -1072,11 +1073,11 @@
 			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 LDP based at
+		separate sections below) that will be hosted on an LDP 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 LDP at this location.</p>
+		therefore can't be served from the LDP server at this location.</p>
 	<pre class='example'>
 @prefix org: &lt;http://www.w3.org/ns/org#&gt; .
 @prefix owltime: &lt;http://www.w3.org/2006/time&gt; .
@@ -1110,7 +1111,7 @@
 			description of a non-document resource</h3>
 	<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
+		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
@@ -1160,7 +1161,7 @@
 		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 LDP would allow a user to replace the information about the
+		of the resource would allow a user to replace the information about the
 		award without disturbing the information about the event.
 	</p>
 	<pre class='example'>
@@ -1260,13 +1261,13 @@
 	<p>
 		Based on the user-story, <a
 			href="#story-constrained_devices" title="">
-			Constrained Devices and Networks</a>, an LDP could be configured to
+			Constrained Devices and Networks</a>, an LDP server could be configured to
 		act as a proxy for a CoAP [[COAP]] 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 LDP registers
+			of Things</a>. As an observer of CoAP resources, the LDP server registers
 		its interest so that it will be notified whenever the sensor
-		reading changes. Clients of the LDP can interrogate the LDP to
+		reading changes. Clients of the LDP can interrogate the server to
 		determine if the state has changed.
 	</p>
 	<p>
@@ -1478,7 +1479,7 @@
 </pre>
 	<p>Collections are potentially very large, so some means may be
 		required to limit the size of RDF representation returned by the
-		LDP (e.g. pagination).</p>
+		LDP server (e.g. pagination).</p>
 	</section>
 	</section>
 	
@@ -1495,7 +1496,7 @@
 		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 a containers that accept them.
+		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