Drafted section: Use fragments as object identifiers lc1
authorcburleso
Fri, 16 Aug 2013 16:31:19 -0500
changeset 272 71b0517fff46
parent 271 4bdbd8e18c5b
child 273 0d933ea95814
Drafted section: Use fragments as object identifiers
ldp-bp/ldp-bp.html
--- a/ldp-bp/ldp-bp.html	Wed Aug 14 17:41:57 2013 -0500
+++ b/ldp-bp/ldp-bp.html	Fri Aug 16 16:31:19 2013 -0500
@@ -414,31 +414,57 @@
 
 	
 				<section>
-					<h3>Use fragments as entity identifiers</h3>
 					
-					<p class="note">This needs more detail and an example.</p>
-	
-					<p>Fragments are nice because they can be expressed as relative
-						URIs on the document describing them.</p>
+					<h3>Use fragments as object identifiers</h3>
+
+					<p>The fragment identifier introduced by a hash mark <b><code>#</code></b> is the optional last part of a URI for an object, which is typically used to identify a subordinate or related object.</p>
+
+					<p>
+					Take the URI, <code>http://www.example.com/products#item10245</code>, for example. The base URI is the part preceding the hash mark, <code>http://www.example.com/products</code>, and the fragment identifier is the part that follows, 
+					<code>item10245</code>.
+					</p>
+
+					<p>
+					In the RDF expressing Linked Data Platform Resources, fragments are useful because they can be expressed as relative URIs on the document describing them. This is particularly handy for 
+					describing a handful of resources that are frequently used together.
+					</p>
+
+					<p>
+					First, it provides the convenience and efficiency of brevity. Suppose, for example that you want to describe the resources foo, bar and baz. 
+					Since serving all of the descriptions in a single document is a acceptable, we can mint relative URIs within the document using the fragment 
+					identifier (<code>&lt;#foo&gt;</code>, <code>&lt;#bar&gt;</code> and <code>&lt;#baz&gt;</code>). The full URI is assumed to be the base URI, plus the 
+					hash mark, and the fragment identifier.
+					</p>
+
+					<p>
+					Second, it can help avoid certain complexities inherent with other approaches. Achieving the same result (three dereferenceable URIs) could be more involved, because you'd need to create and publish 
+					multiple documents, perhaps also having to setup 303 redirects.
+					</p>
+
+					<p><strong>See also:</strong></p>
+
+					<p> 
+						<a href="http://www.w3.org/TR/cooluris">Cool URIs for the Semantic Web</a>
+						<ul>
+							<li><a href="http://www.w3.org/TR/cooluris/#hashuri">http://www.w3.org/TR/cooluris/#hashuri</a></li>
+							<li><a href="http://www.w3.org/TR/cooluris/#choosing">http://www.w3.org/TR/cooluris/#choosing</a></li>
+						</ul>
+					</p>
+
+					<p><a href="http://www.w3.org/DesignIssues/Fragment.html">Axioms of Web Architecture, URI References: Fragment Identifiers on URIs</a><br/>
+						http://www.w3.org/DesignIssues/Fragment.html</p>
+
+					<p><a href="http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14">Dereferencing HTTP URIs</a><br/>
+						http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14</p>
+
 				</section>
 	
 	
 				<section>
 					<h3>Prefer standard datatypes</h3>
 	
-					<p class="note">
-						This was originally part of <a
-							href="http://www.w3.org/TR/2012/WD-ldp-20121025/#general">old
-							Section 4.1.9</a> that was deleted from the FPWD based on resolution
-						of <a href="https://www.w3.org/2012/ldp/track/issues/6">ISSUE-6</a>.
-					</p>
-	
-	
-					<p>LDPR representations must use only the following standard
-						datatypes. RDF does not by itself define datatypes to be used for
-						literal property values, therefore a set of standard datatypes
-						based on [[XMLSCHEMA11-2]] and [[RDF-PRIMER]] are to be used:</p>
-	
+					<p>LDPR representations should use only the following standard datatypes. RDF does not by itself define datatypes to be used for literal property values, therefore a set of standard datatypes
+						based on [[XMLSCHEMA11-2]] and [[RDF-PRIMER]] should be used:</p>
 	
 					<table class="simple">
 						<thead>
@@ -497,35 +523,21 @@
 	
 	
 				<section>
-					<h3>Re-use established linked data vocabularies instead of
-						(re-)inventing duplicates</h3>
-	
-					<p class="note">
-						This was originally from <a
-							href="http://www.w3.org/TR/2012/WD-ldp-20121025/#common-properties">old
-							section 4.8</a> that was deleted from the FPWD based on resolution of
-						<a href="https://www.w3.org/2012/ldp/track/issues/42">ISSUE-42</a>.
-						As indicated in that issue, the text below (which was simply copied
-						from the spec) may need further editing.
-					</p>
-	
-					<p>Common Properties</p>
+
+					<h3>Re-use established linked data vocabularies instead of (re-)inventing duplicates</h3>
 	
 					<p>This section summarizes some well-known RDF vocabularies that
-						must be used in Linked Data Platform Resources wherever a resource
+						should be used in Linked Data Platform Resources wherever a resource
 						needs to use a predicate whose meaning matches one of these. For
-						example, if a BP resource has a description, and the application
-						semantic of that description is compatible with
-						dcterms:description, then dcterms:description must be used. If
-						needed, additional application-specific predicates may be used. A
-						specification for a domain that is based on BP may require one or
-						more of these properties for a particular resource type. The Range
-						column in the tables below identify the recommended rdfs:range for
-						the properties.</p>
-	
-					<p>
-						From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a>
-					</p>
+						example, if a resource has a description, and the application
+						semantic of that description is compatible with <code>dcterms:description</code>, 
+						then <code>dcterms:description</code> should be used. If needed, additional application-specific predicates may be used. 
+						A specification for a domain may require one or more of these properties for a particular resource type. 
+						The Range column in the tables below identifies the recommended <code>rdfs:range</code> for the properties.</p>
+					
+					<h4>Common Properties</h4>
+					
+					<strong>From Dublin Core URI: <a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></strong>
 	
 					<table class="simple">
 						<thead>
@@ -591,18 +603,9 @@
 						</tbody>
 					</table>
 	
-					<p>
-						The predicate
-						<code>dcterms:type</code>
-						should not be used, instead use
-						<code>rdf:type</code>
-						. [[DC-RDF]].
-					</p>
+					<p>The predicate <code>dcterms:type</code> should not be used, instead use <code>rdf:type</code>. [[DC-RDF]].</p>
 	
-					<p>
-						From RDF URI: <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a>
-					</p>
-	
+					<strong>From RDF URI: <a href="http://www.w3.org/1999/02/22-rdf-syntax-ns#">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></strong>
 	
 					<table class="simple">
 						<thead>
@@ -618,14 +621,10 @@
 								<td>rdfs:Class</td>
 								<td>The type or types of the resource</td>
 							</tr>
-	
 						</tbody>
 					</table>
 	
-					<p>
-						From RDF Schema URI: <a
-							href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a>
-					</p>
+					<strong>From RDF Schema URI: <a href="http://www.w3.org/2000/01/rdf-schema#">http://www.w3.org/2000/01/rdf-schema#</a></strong>
 	
 					<table class="simple">
 						<thead>
@@ -639,13 +638,12 @@
 							<tr>
 								<td>rdfs:member</td>
 								<td>rdfs:Resource</td>
-								<td></td>
+								<td>&nbsp;</td>
 							</tr>
 							<tr>
 								<td>rdfs:label</td>
 								<td>rdfs:Literal</td>
-								<td>Only use this in vocabulary documents, to define the
-									name of the vocabulary term.</td>
+								<td>Only use this in vocabulary documents, to define the name of the vocabulary term.</td>
 							</tr>
 						</tbody>
 					</table>
@@ -655,8 +653,7 @@
 	
 				<section>
 					<h3>Properly use q values</h3>
-					<p>Not properly handling q values is a major problem in
-						implementations of content negotiation.</p>
+					<p>Not properly handling q values is a major problem in implementations of content negotiation.</p>
 				</section>
 	
 				<section>