--- a/ldp-ucr.html Fri Jul 26 12:46:34 2013 -0400
+++ b/ldp-ucr.html Fri Jul 26 12:47:24 2013 -0400
@@ -154,40 +154,31 @@
capture statements about system requirements written from a user
or application perspective. They are typically lightweight and
informal and can run from one line to a paragraph or two
- (sometimes described as an 'epic') <a
- href="http://www.agilemodeling.com/artifacts/userStory.htm"
- class="external autonumber"
- title="http://www.agilemodeling.com/artifacts/userStory.htm"
- rel="nofollow">[2]</a>. Analysis of each user story will reveal a
+ (sometimes described as an 'epic') [[COHN-2004]].
+ This document redacts a number of user stories around the theme of read/writeable linked data.
+ Analysis of each user story reveals a
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
+ requirements. See <i>Device API Access Control Use Cases and Requirements</i> [[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
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"
- class="external autonumber"
- title="http://alistair.cockburn.us/get/2465" rel="nofollow">[3]</a>,
+ describe the system’s behavior under various conditions [[COCKBURN-2000]],
cataloging who does what with the system, for what purpose, but
- without concern for system design or implementation <a
- href="http://www.bredemeyer.com/pdf_files/functreq.pdf"
- class="external autonumber"
- title="http://www.bredemeyer.com/pdf_files/functreq.pdf"
- rel="nofollow">[4]</a>. Each use case is identified by a
+ without concern for system design or implementation. 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,
from a simple narrative to a structured description with actors,
- pre/post conditions, step-by-step behaviors (as in POWDER:
- Use Cases and Requirements [[POWDER-USE-CASES]]), and non-functional requirements
+ pre/post conditions, step-by-step behaviors (as in <i>POWDER:
+ Use Cases and Requirements</i> [[POWDER-USE-CASES]]), and non-functional requirements
raised by the use case.</li>
</ul>
<ul>
<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
+ lightweight narratives as seen in <i>Use
+ cases and requirements for Media Fragments</i> [[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>
@@ -274,8 +265,6 @@
consistent application interface that they all supported?
</p>
<p>
- Our set of links would probably be a <a
- href="#uc-aggregate_resources" title="">simple collection</a>.
The information held by any single organization might be a mix of
simple data and <a href="#uc-aggregate_resources" title="">collections
of other data</a>, for example, a bank account balance and a
@@ -336,7 +325,7 @@
<h2 id="story-lld">Library Linked Data</h2>
<p>
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
+ cases cited in their <i>Use Case Report</i> [[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,
as well as ways to improve or update the data, would enable
@@ -565,8 +554,7 @@
repositories and efficiently retrieving <a
href="#uc-has_resource_changed" title="">
updated content</a> without having to retrieve the whole content.
- Hence, we chose to build the integration solution capitalizing on
- the Data Warehousing integration approach. This allows us to cope
+ The Data Warehousing integration approach allows us to cope
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
@@ -584,11 +572,6 @@
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>
- <p>
- Related: <a href="http://spec.datacatalogs.org/"
- title="http://spec.datacatalogs.org/"
- rel="nofollow">Data Catalog Schema and Protocol</a>
- </p>
</section>
<section>