--- 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: <http://www.w3.org/ns/org#> .
@prefix owltime: <http://www.w3.org/2006/time> .
@@ -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