Fixed up some specref references
authorsspeiche
Mon, 17 Feb 2014 21:36:17 -0500
changeset 495 559a77692da5
parent 494 81a41ff4e1ee
child 496 94420c5678ae
Fixed up some specref references
ldp.html
--- a/ldp.html	Mon Feb 17 17:07:01 2014 -0500
+++ b/ldp.html	Mon Feb 17 21:36:17 2014 -0500
@@ -7,14 +7,14 @@
      and see if there is a friendlier 	way to phrase it.
     TODO: Consider how to not have to explicitly list parent classes.
     TODO: Improve LDPC intro by explaining simply that LDP-DC restricts LDPC and LDP-BC restricts LDP-DC.
+	TODO: Add new "discovery of server capabilities" non-norm section
 
 Paging related:
+	TODO: Missing link header for equivalent of ldp:pageOf? Need to verify.
 	TODO: Example 11 is missing ldp:contains, true?  Omit due to GET on page resource, should make it more clear.
 	TODO: Paging intro: add 3rd example showing header link	age amongst pages and (HEAD on) the base resource.
      Maybe also insert HEAD on base as new first example instead of relying on text alone.
-	TODO: The ReSpec SPARQL QUERY link is http://www.w3.org/TR/rdf-sparql-query/ , which has highlighted text
-	referring readers to SPARQL 1.1.  Which normative reference do we want? http://www.w3.org/TR/sparql11-query/ Ask Sandro
-	TODO: Add new "discovery of server capabilities" non-norm section
+
  -->
 <html>
   <head>
@@ -263,12 +263,12 @@
 <section id="terms">
 <h1>Terminology</h1>
 
-<p>Terminology is based on W3C's Architecture of the World Wide Web [[WEBARCH]] and Hyper-text Transfer Protocol [[HTTP11]].
+<p>Terminology is based on W3C's Architecture of the World Wide Web [[webarch]] and Hyper-text Transfer Protocol [[HTTP11]].
 </p>
   <dl class="glossary">
 	<dt>Link</dt>
 	<dd>A relationship between two resources when one resource (representation) refers to the other resource by means
-		of a URI [[WEBARCH]].
+		of a URI [[webarch]].
 		<p></p></dd>
 							
 	<dt>Linked Data</dt>
@@ -296,7 +296,7 @@
 	<dt><dfn>Linked Data Platform RDF Source</dfn> (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>)</dt>
 	<dd>An <a title="Linked Data Platform Resource">LDPR</a> whose state is represented in RDF, corresponding to
 	an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a>. See also the term
-	<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source">RDF Source</a> from [[!RDF11-CONCEPTS]].
+	<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-source">RDF Source</a> from [[!rdf11-concepts]].
 	<p></p></dd>	
 
 	<dt><dfn>Linked Data Platform Non-RDF Source</dfn> (<abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr>)</dt>
@@ -306,7 +306,7 @@
 		
 	<dt><dfn>Linked Data Platform Container</dfn> (<abbr title="Linked Data Platform Container">LDPC</abbr>)</dt>
 	<dd>An LDPR representing a collection of <a title="Membership">member</a> resources and/or <a title="Containment">contained</a>
-	documents (<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-document">RDF Document</a> [[!RDF11-CONCEPTS]] or information resources [[!WEBARCH]])
+	documents (<a href="http://www.w3.org/TR/rdf11-concepts/#dfn-rdf-document">RDF Document</a> [[!rdf11-concepts]] or information resources [[!webarch]])
 	that responds to client requests for creation, modification, and/or enumeration of its members and documents, 
 	and that conforms to the simple lifecycle
 	patterns and conventions in <a href="#ldpc" class="sectionRef"></a>.
@@ -314,13 +314,13 @@
 	
 	<dt><dfn>Linked Data Platform Basic Container</dfn> (<abbr title="Linked Data Platform Basic Container">LDP-BC</abbr>)</dt>
 	<dd>A <a title="Linked Data Platform Container">LDPC</a> that uses a single pre-defined predicate to link to both
-	its <a title="Containment">contained</a> and <a title="Membership">member</a> documents (information resources) [[!WEBARCH]].
+	its <a title="Containment">contained</a> and <a title="Membership">member</a> documents (information resources) [[!webarch]].
 	<p></p></dd>
 	
 	<dt><dfn>Linked Data Platform Direct Container</dfn> (<abbr title="Linked Data Platform Direct Container">LDP-DC</abbr>)</dt>
 	<dd>A <a title="Linked Data Platform Container">LDPC</a> that has the flexibility of choosing what form its 
 	<a title="Membership triples">membership triples</a> take, and allows <a title="Membership">members</a> to be 
-	any resources [[!WEBARCH]], not only documents.
+	any resources [[!webarch]], not only documents.
 	<p></p></dd>
 	
 	<!-- TODO: Remove LDP-IC definitions
@@ -455,7 +455,7 @@
 <h2>Conventions Used in This Document</h2>
 
 	<p>Sample resource representations are provided in <code>text/turtle</code>
-		format [[TURTLE]].</p>
+		format [[turtle]].</p>
 	<p>Commonly used namespace prefixes:</p>
 	<pre style="word-wrap: break-word; white-space: pre-wrap;">	@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
 	@prefix foaf:     &lt;http://xmlns.com/foaf/0.1/&gt;.
@@ -580,7 +580,7 @@
 	<p>An LDP server manages two kinds of <a title="Linked Data Platform Resources">LDPRs</a>, those resources who whose state 
 	is represented using RDF (LDP-RS) and those using other formats (LDP-NR).  LDP-RSs have the unique
 	quality that their representation is based on RDF, which addresses a number of use cases from web metadata, open data 
-	models, machine processable information, and automated processing by software agents [[!RDF-CONCEPTS]].  LDP-NRs are almost anything
+	models, machine processable information, and automated processing by software agents [[!RDF11-CONCEPTS]].  LDP-NRs are almost anything
 	on the Web today: images, HTML pages, word processing documents, spreadsheets, etc. and LDP-RSs hold 
 	metadata associated with LDP-NRs in some cases.
 	</p>
@@ -617,7 +617,7 @@
 	</h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
 	
 	<section id="ldpr-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> predicates SHOULD use standard vocabularies such as Dublin Core
-		[[!DC-TERMS]], RDF [[!RDF-CONCEPTS]] and RDF Schema [[!RDF-SCHEMA]], whenever
+		[[!DC-TERMS]], RDF [[!RDF11-CONCEPTS]] and RDF Schema [[!rdf-schema]], whenever
 		possible.
 	</h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
 	
@@ -662,7 +662,7 @@
 	<section id="ldpr-gen-noinferencing"><h2 class="normal"><a title="LDP server">LDP servers</a>
 		MUST NOT require LDP clients to implement inferencing in order to recognize the subset
 		of content defined by LDP.  Other specifications built on top of LDP may require clients
-		to implement inferencing [[!RDF-CONCEPTS]].  The practical implication is that all content defined by LDP
+		to implement inferencing [[!RDF11-CONCEPTS]].  The practical implication is that all content defined by LDP
 		must be explicitly represented. 
 	</h2></section><!-- Was 4.2.11 / #ldpr-4_2_11 -->
 	
@@ -675,13 +675,13 @@
 	<section id="ldpr-gen-pubclireqs"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST 
 		publish any constraints on <a title="LDP client">LDP clients’</a> ability to 
 		create or update LDPRs, by adding a Link header with <code>rel='describedby'</code> 
-		[[!POWDER-DR]] to all responses to requests which fail due to violation of 
+		[[!powder-dr]] to all responses to requests which fail due to violation of 
 		those constraints.  For example, a server that refuses resource creation 
 		requests via HTTP PUT, POST, or PATCH would return this <code>Link</code> header on its 
 		4xx responses to such requests.
 		The same <code>Link</code> header MAY be provided on other responses.  LDP neither 
 		defines nor constrains the representation of the link's target resource; 
-		as stated in [[POWDER-DR]], the target might (or might not) be a POWDER 
+		as stated in [[powder-dr]], the target might (or might not) be a POWDER 
 		document.  Natural language constraint documents are therefore permitted, 
 		although machine-readable ones facilitate better client interactions.
 	</h2></section><!-- Was 4.2.13 / #ldpr-4_2_13 -->
@@ -708,7 +708,7 @@
 	</h2></section><!-- Was 4.3.2 / #ldpr-4_3_2 -->
 	
 	<section id="ldpr-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
-		representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> [[!TURTLE]].
+		representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> [[!turtle]].
 	</h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
 
 </section>
@@ -1291,7 +1291,7 @@
 	representations.  When doing this, a preference would be for RDF formats that support multiple named graphs, one
 	named graph for the net worth resource and then two others for asset and liability containers.  This allows for
 	the membership triples to be represented with the named graph for the net worth resource, while the containment triples
-	would be represented within the liability and asset containers [[RDF11-CONCEPTS]].  Generally, the membership triples belong
+	would be represented within the liability and asset containers [[rdf11-concepts]].  Generally, the membership triples belong
 	to the representation of a LDP-RS and the containment triples belong to the representation of the LDPC.
 	</p>
 	
@@ -1389,7 +1389,7 @@
 		a simple case where few empty-container triples are
 		retrieved. In real world situations more complex cases are likely, such as those that add other predicates to
 		containers, for example providing validation information and
-		associating SPARQL endpoints. [[SPARQL-QUERY]]</p>
+		associating SPARQL endpoints. [[sparql11-query]]</p>
 	<p>
 		Here is an example requesting the empty-container triples of a
 		container identified by the URL <code>http://example.org/container1/</code>.
@@ -1697,7 +1697,7 @@
 		and whose object is a <code>rdf:List</code> of
 		<code>ldp:containerSortCriterion</code> resources.  
 		The resulting order MUST be as defined by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause 
-		[[!SPARQL-QUERY]].
+		[[!sparql11-query]].
 		Sorting criteria MUST be the same for all pages of a representation; if
 		the criteria were allowed to vary, the ordering among members of a container
 		across pages would be undefined. 
@@ -1717,7 +1717,7 @@
 		and whose object is 
 		the predicate whose value is used to order members between pages (the <dfn>page-ordering values</dfn>).
 		The only literal data types whose behavior LDP constrains are those defined
-		by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [[!SPARQL-QUERY]].  Other data types
+		by SPARQL <code>SELECT</code>’s <code>ORDER BY</code> clause [[!sparql11-query]].  Other data types
 		can be used, but LDP
 		assigns no meaning to them and interoperability will be limited.
 	</h2></section><!-- Was 5.3.3 / #ldpc-5_3_3 -->
@@ -1746,19 +1746,19 @@
 		as the object of this triple.  While it is better for interoperability to use
 		open standardized values, any value can be used.
 		When the <code>ldp:containerSortCollation</code> triple is absent and the 
-		<a title="page-ordering values">page-ordering values</a> are strings or simple literals [[!SPARQL-QUERY]], the
+		<a title="page-ordering values">page-ordering values</a> are strings or simple literals [[!sparql11-query]], the
 		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
-		[[!SPARQL-QUERY]] using two-argument <code>fn:compare</code>, that is, 
+		[[!sparql11-query]] using two-argument <code>fn:compare</code>, that is, 
 		it behaves as if <code>http://www.w3.org/2005/xpath-functions/collation/codepoint</code> 
 		was the specified collation.
 		When the <code>ldp:containerSortCollation</code> triple is present and the 
 		<a title="page-ordering values">page-ordering values</a> are strings or simple literals 
-		[[!SPARQL-QUERY]], the
+		[[!sparql11-query]], the
 		resulting order is as defined by SPARQL SELECT’s ORDER BY clause 
-		[[!SPARQL-QUERY]] using three-argument <code>fn:compare</code>, that is, the 
+		[[!sparql11-query]] using three-argument <code>fn:compare</code>, that is, the 
 		specified collation.
 		The <code>ldp:containerSortCollation</code> triple MUST be omitted for comparisons
-		involving <a title="page-ordering values">page-ordering values</a> for which [[!SPARQL-QUERY]] does not use collations.
+		involving <a title="page-ordering values">page-ordering values</a> for which [[!sparql11-query]] does not use collations.
 	</h2></section><!-- Was 5.3.5 / #ldpc-5_3_5 -->
 </section>
 
@@ -1807,7 +1807,7 @@
 	
 	<section id="ldpc-post-createrdf"><h2 class="normal"><a title="LDP server">LDP servers</a> that successfully create a resource from a
 		RDF representation in the request entity body MUST honor the client's requested interaction model(s). The created resource
-		can be thought of as an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[!RDF11-CONCEPTS]].
+		can be thought of as an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[!rdf11-concepts]].
 		If any model cannot be honored, the server MUST fail the request.
 	</h2><!-- Was 5.4.4 / #ldpc-5_4_4 -->
 	<ul>
@@ -1820,7 +1820,7 @@
 	</section>
 	
 	<section id="ldpc-post-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST accept a request entity body with a request header
-	    of <code>Content-Type</code> with value of <code>text/turtle</code> [[!TURTLE]].
+	    of <code>Content-Type</code> with value of <code>text/turtle</code> [[!turtle]].
 	</h2></section><!-- Was 5.4.5 / #ldpc-5_4_5 -->
 	
 	<section id="ldpc-post-contenttype"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD use the <code>Content-Type</code> request header 
@@ -1926,7 +1926,7 @@
 	
 	<section id="ldpc-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code> 
 		SHOULD NOT re-use URIs.  For RDF representations (LDP-RSs),the created resource
-		can be thought of as a RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[!RDF11-CONCEPTS]].
+		can be thought of as a RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[!rdf11-concepts]].
 	</h2></section><!-- Was 5.5.4 / #ldpc-5_5_4 -->
 	
 </section>
@@ -2027,7 +2027,7 @@
 
 <section id="specs-webarch" class="informative">
 <h2>Architecture of the World Wide Web</h2>
-Reference: [[!WEBARCH]]
+Reference: [[!webarch]]
 
 	<section id="ldp-webarch-nonexcl-membership" ><h2 class="normal">LDPC membership is not exclusive; this means that the same resource
 	(LDPR or not) can be a member of more than one LDPC.
@@ -2091,7 +2091,7 @@
 
 <section id="specs-rdf" class="informative">
 <h2>RDF</h2>
-Reference: [[RDF-CONCEPTS]]
+Reference: [[RDF11-CONCEPTS]]
 
 	<section id="ldp-rdfconcepts-extra-triples-any"><h2 class="normal">The state of an LDPR 
 		can have triples with any subject(s).  The URL used to retrieve the