--- a/ldp-ucr.html Tue Oct 01 16:12:23 2013 -0400
+++ b/ldp-ucr.html Wed Oct 16 15:20:57 2013 +0100
@@ -255,7 +255,7 @@
of user stories and their analysis.</li>
</ul>
<ul>
- <li><b><a href="#use cases" title="Use Cases">Use Cases</a></b> are
+ <li><b><a href="#use%20cases" 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
@@ -822,7 +822,7 @@
These artefacts will be added to the research object throughout the project lifecycle of the project.
</p>
<p>
- The RDF description below captures the initial state of the research object. For the purposes of the example, we have included the time of creation. It is a linked data resource addressed via URL from which the following RDF can be retrieved. The null-relative URL <tt><></tt> should be understood as a self-reference to the research object itself.
+ The RDF description below captures the initial state of the research object. For the purposes of the example, we have included the time of creation. It is a linked data resource addressed via URL from which the following RDF can be retrieved. The null-relative URL <em><></em> should be understood as a self-reference to the research object itself.
</p>
<pre class='example'>
@prefix ro: <http://purl.org/wf4ever/ro#> .
@@ -842,9 +842,9 @@
The motivation for nested containers comes from the <a>System and Software Development Tool Integration</a> user story. The
OSLC Change Management vocabulary allows bug reports to have
attachments referenced by the membership predicate
- <tt>oslc_cm:attachment</tt>. This may be viewed as nested containment. The <tt>top-level-container</tt> contains issues, and
+ <em>oslc_cm:attachment</em>. This may be viewed as nested containment. The <em>top-level-container</em> contains issues, and
each issue is itself a container of attachments.
- In the example, <tt>issue1234</tt> is a member of the container <tt>top-level-container</tt>. In turn, <tt>attachment324</tt> and <tt>attachment251</tt> are attachments within <tt>issue1234</tt>. Treating these as containers makes it easier to manage them as self-contained units.
+ In the example, <em>issue1234</em> is a member of the container <em>top-level-container</em>. In turn, <em>attachment324</em> and <em>attachment251</em> are attachments within <em>issue1234</em>. Treating these as containers makes it easier to manage them as self-contained units.
</p>
<pre class='example'>
@prefix dcterms: <http://purl.org/dc/terms/>.
@@ -920,9 +920,9 @@
original design didn’t consider." The following RDF could be used
to describe contact information using the FOAF
vocabulary [[FOAF]]. A contact is represented here by a
- <tt>foaf:PersonalProfileDocument</tt> defining a resource that can be
+ <em>foaf:PersonalProfileDocument</em> defining a resource that can be
created and updated as a single-unit, even though it may describe
- ancillary resources, such as a <tt>foaf:Person</tt>, below.
+ ancillary resources, such as a <em>foaf:Person</em>, below.
</p>
<pre class='example'>
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
@@ -982,7 +982,7 @@
representation may include descriptions of related resources that
cannot be accessed directly. Depending upon the application, an
server may enrich the retrieved RDF with additional triples. Examples
- include adding incoming links, <tt>owl:sameAs</tt> closure and <tt>rdf:type</tt> closure.
+ include adding incoming links, <em>owl:sameAs</em> closure and <em>rdf:type</em> closure.
The HTTP response should also include versioning information (i.e.
last update or entity tag) so that subsequent updates can ensure
they are being applied to the correct version.</p>
@@ -1010,13 +1010,13 @@
organizational ontology [[ORG-ONT]].
</p>
<p>Examples 4 and 5 below define two resources that would be hosted on an LDP server based at
- <http://example.com/>. The representation in Example 4 describes <http://example.com/member1>, while that of Example 5 describes <http://example.com/role>.
+ <http:⁄⁄example.com⁄>. The representation in Example 4 describes <http:⁄⁄example.com⁄member1>, while that of Example 5 describes <http:⁄⁄example.com⁄role>.
A client reading Example 4 would have to separately retrieve Example 5 in order to get role information such as its descriptive label.
</p>
<p>
Note that the representations of these resources may
include descriptions of related resources, such as
- http://www.w3.org/, that that fall under a completely different authority and
+ <http://www.w3.org/>, that that fall under a completely different authority and
therefore can't be served directly from the LDP server at this location.</p>
<div>
<pre class='example'>
@@ -1059,7 +1059,7 @@
the person and the profile; the former being the topic of the
latter. Where the fragment is defined relative to the base, as in this example, the URL including the fragment may be used to access the resource representing the containing document. The HTTP protocol
requires that the fragment part be stripped off before requesting
- the URI from the server. The client can then read properties of the hash URI <tt><#i></tt> from the retrieved description.
+ the URI from the server. The client can then read properties of the hash URI <em><#i></em> from the retrieved description.
</p>
<pre class='example'>
@base <http://www.w3.org/People/Berners-Lee/card>
@@ -1155,7 +1155,7 @@
<p>
A catalog may contain multiple datasets, so when linking to new
datasets it would be simpler and preferable to selectively add
- just the new dataset links. For this example, a Changeset [[CHANGESET]] might be used to add a new <tt>dc:title</tt> to the
+ just the new dataset links. For this example, a Changeset [[CHANGESET]] might be used to add a new <em>dc:title</em> to the
dataset. The following update would be directed to the catalogue
to add an additional dataset.
</p>
@@ -1281,10 +1281,10 @@
<p>There is an existing collection at
<http://example.com/concept-scheme/subject-heading> that
defines a collection of subject headings. This collection is
- defined as a <tt>skos:ConceptScheme</tt> and the client wishes to insert a
+ defined as a <em>skos:ConceptScheme</em> and the client wishes to insert a
new concept into the scheme. which will be related to the
- collection via a <tt>skos:inScheme</tt> link. In the example below, a new subject-heading,
- "outer space exploration" is added to the <tt>scheme:subject-heading</tt> collection. The following RDF describes the (item-level)
+ collection via a <em>skos:inScheme</em> link. In the example below, a new subject-heading,
+ "outer space exploration" is added to the <em>scheme:subject-heading</em> collection. The following RDF describes the (item-level)
description of the collection,
also demonstrating that the relationship between the parent and child resources may run in a seemingly counter-intuitive direction, from child to parent.
</p>
@@ -1314,7 +1314,7 @@
As a machine-readable collection of medical terms, the SNOMED CT ontology [[SNOMED]]
is of key importance in user story, <a>Healthcare</a>. SNOMED CT allows concepts with more than one parent. In the example below, SNOMED concepts are treated as
collections (aggregations) of narrower concepts. We see that the
- concept <tt>:TissueSpecimenFromHeart</tt> belongs to two parent collections as it is both a <tt>:TissueSpecimen</tt> and a <tt>:SpecimenFromHeart</tt>.
+ concept <em>:TissueSpecimenFromHeart</em> belongs to two parent collections as it is both a <em>:TissueSpecimen</em> and a <em>:SpecimenFromHeart</em>.
This example also demonstrates how composition and aggregation support different scenarios, as the ability to have multiple parents should not be a possibility with composition.
</p>
<pre class='example'>
@@ -1383,13 +1383,13 @@
representation, so that a client can explore the data by following
these links. Different applications may use different membership
predicates to capture this aggregation. The example below uses
- <tt>rdfs:member</tt>, but many different membership predicates are in
+ <em>rdfs:member</em>, but many different membership predicates are in
common use, including RDF Lists. Item-level descriptions can be
captured using the Functional Requirements for Bibliographic
Records (FRBR) ontology [[FRBR]] [[FRBR-CORE]].
</p>
<p>
- Based on the example below, the item-level description should include as a minimum all the <tt>rdfs:member</tt> relationships. It need not include other properties of the collection, and it need not include additional properties of the members.
+ Based on the example below, the item-level description should include as a minimum all the <em>rdfs:member</em> relationships. It need not include other properties of the collection, and it need not include additional properties of the members.
</p>
<pre class='example'>
@prefix frbr: <http://purl.org/vocab/frbr/core#>.
@@ -1420,7 +1420,7 @@
<ul>
<li>It's not really the resource description that's being paginated, but the values of a particular property.</li>
<li>The server is responsible for pagination, and may decide how large the pages are.</li>
- <li>Pagination should apply symmetrically to both <emph>incoming</emph> and <emph>outgoing</emph> properties.</li>
+ <li>Pagination should apply symmetrically to both <em>incoming</em> and <em>outgoing</em> properties.</li>
<li>The next-page URL should be treated as opaque.</li>
</ul>
@@ -1535,9 +1535,9 @@
<dt><dfn>F2.2</dfn>:</dt>
<dd>The system shall provide the ability to delete resources, from <a>UC2</a>.
</dd>
- <dt><dfn>F2.3</dfn>:</dt>
- <dd><strike>The system shall provide the ability to move resources between containers, from <a>UC2</a></strike>.
- </dd>
+ <!--dt><dfn>F2.3</dfn>:</dt>
+ <dd><!strike>The system shall provide the ability to move resources between containers, from <a>UC2</a></strike>.
+ </dd-->
<dt><dfn>F3.1</dfn>:</dt>
<dd>The system shall provide the ability to retrieve resource descriptions, from <a>UC3</a>.
</dd>
@@ -1571,9 +1571,9 @@
<dt><dfn>F9.1</dfn>:</dt>
<dd>The system shall provide the ability to store and access media resources, from <a>UC9</a>
</dd>
- <dt><dfn>F9.2</dfn>:</dt>
+ <!--dt><dfn>F9.2</dfn>:</dt>
<dd><strike>The system shall provide the ability to add media-resource attachments, from <a>UC9</a>.</strike>
- </dd>
+ </dd-->
</dl>
</section>