--- a/ldp-ucr.html	Wed Oct 30 11:40:38 2013 +0000
+++ b/ldp-ucr.html	Wed Oct 30 16:46:49 2013 +0000
@@ -253,7 +253,7 @@
 			of user stories and their analysis.</li>
 	</ul>
 	<ul>
-		<li><b><a href="#use%20cases" title="Use Cases">Use Cases</a></b> are
+		<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 [[COCKBURN-2000]],
 			cataloging who does what with the system, for what purpose, but
@@ -311,11 +311,11 @@
 		resource, a few formats needed, and access guidance for these
 		resources. This would support how to acquire a link to a contact,
 		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>
+			href="#uc3" title="">reading</a>,
+		<a href="#uc4" title="">updating</a>,
+		and <a href="#s2.2" title="">deleting</a>
 		it), as well as how to easily <a
-			href="#scen-create_resource" title="">create a
+			href="#s2.1" title="">create 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
@@ -349,17 +349,17 @@
 		of having to manually supply those identifiers to each one’s
 		corresponding custom application, we could essentially build a set
 		of bookmarks to it all? When we want to <a
-			href="#uc-retrieve_resource_description" title="">examine</a>
-		or <a href="#uc-update_existing" title="">change</a>
+			href="#uc3" title="">examine</a>
+		or <a href="#uc4" title="">change</a>
 		their contents, would it not be simpler if there were a single
 		consistent application interface that they all supported? 
 	</p>
 	<p>
 		The information held by any single organization might be a mix of
-		simple data and <a href="#uc-aggregate_resources" title="">collections
+		simple data and <a href="#uc6" title="">collections
 			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_composition"
+		<a href="#s1.2"
 			title="">a collection of accounts for each member of its collection
 			of customers</a>.
 	</p>
@@ -425,7 +425,7 @@
 		use cases:</p>
 	<ul>
 		<li>Grouping: This should "Allow the end-users to define <a
-			href="#uc-aggregate_resources" title="">groups of resources</a>
+			href="#uc6" title="">groups of resources</a>
 			on the web that for some reason belong together. The relationship
 			that exists between the resources is often left unspecified. Some
 			of the resources in a group may not be under control of the
@@ -434,12 +434,12 @@
 	</ul>
 	<ul>
 		<li>Enrichment: "Enable end-users to <a
-			href="#uc-update_existing" title="">link resources
+			href="#uc4" title="">link resources
 				together</a>."
 		</li>
 	</ul>
 	<ul>
-		<li>Browsing: "<a href="#uc-filter_resource_description"
+		<li>Browsing: "<a href="#uc7"
 			title="">Support end-user browsing through groups</a> and
 			resources that belong to the groups."
 		</li>
@@ -453,7 +453,7 @@
 		use cases:</p>
 	<ul>
 		<li>Collection-level description: "Provide <a
-			href="#uc-filter_resource_description" title="">metadata
+			href="#uc7" title="">metadata
 				pertaining to a collection as a whole</a>, in contrast to item-level
 			description."
 		</li>
@@ -482,7 +482,7 @@
 		and efficiently collect, produce, and analyze all this data, a
 		fundamental set of loosely coupled standard data sources are
 		needed. A simple, low-cost way to <a
-			href="#uc-retrieve_resource_description" title="">expose
+			href="#uc3" title="">expose
 			data</a> from the diverse set of monitored services is needed, one
 		that can easily integrate into the municipalities of other systems
 		that inspect and analyze the data. All these services have links
@@ -521,7 +521,7 @@
 	<h2 id="story-media"><dfn>Metadata Enrichment in Broadcasting</dfn></h2>
 	<p>
 		There are many different use cases when broadcasters show interest
-		in metadata <a href="#uc-update_existing" title="">
+		in metadata <a href="#uc4" title="">
 			enrichment</a>:
 	</p>
 	<ul>
@@ -549,9 +549,9 @@
 		For infrastructure management (such as storage systems, virtual
 		machine environments, and similar IaaS and PaaS concepts), it is
 		important to provide an environment in which information from
-		different sources can be <a href="#uc-aggregate_resources"
+		different sources can be <a href="#uc6"
 			title="">aggregated</a>, <a
-			href="#uc-filter_resource_description" title="">filtered</a>,
+			href="#uc7" title="">filtered</a>,
 		and visualized effectively. Specifically, the following use cases
 		need to be taken into account:
 	</p>
@@ -635,7 +635,7 @@
 		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="">
+			href="#uc5" title="">
 			updated content</a> without having to retrieve the whole content.
 		The Data Warehousing integration approach allows us to cope
 		with heterogeneity of sources technologies and to benefit from the
@@ -696,7 +696,7 @@
 		through local trusted sharing, analysis, dissemination (including
 		publishing of experimental data "beyond the PDF"), and re-use.</p>
 	<ul>
-		<li><a href="#uc-aggregate_resources" title="">Aggregations</a>,
+		<li><a href="#uc6" title="">Aggregations</a>,
 			specifically <em>Research Objects (ROs)</em> are exchanged
 			between services and clients bringing together workflows, data
 			sets, annotations, and provenance.