--- a/ldp-ucr.html Mon Jul 08 14:05:56 2013 +0100
+++ b/ldp-ucr.html Mon Jul 08 14:22:56 2013 +0100
@@ -228,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>
@@ -259,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
@@ -275,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
@@ -292,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
@@ -341,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,
@@ -401,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
@@ -433,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
@@ -509,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/"
@@ -531,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>
@@ -542,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
@@ -587,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>
@@ -615,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
@@ -625,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"