Merge
authorsteve.battle <steve.battle@sysemia.co.uk>
Mon, 08 Jul 2013 14:05:56 +0100
changeset 154 f23e54fd77dc
parent 153 86956781820b (current diff)
parent 152 938e7d21cc10 (diff)
child 155 e960d5f2cd9e
Merge
--- a/ldp.html	Mon Jul 08 14:05:18 2013 +0100
+++ b/ldp.html	Mon Jul 08 14:05:56 2013 +0100
@@ -271,11 +271,6 @@
 requests and generates HTTP responses that conform to the rules defined in sections on <a href="#linked-data-platform-resources">LDPRs</a>
 and <a href="#linked-data-platform-containers">LDPCs</a></p>.
 
-<div class="ldp-issue-open">
-	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/57">ISSUE-57</a></div>
-	How can a client determine that it is in communication with an LDP server?
-	</div>
-
 <p>A conforming <b>LDP Client</b> is an application program that generates HTTP 
 requests and processes HTTP responses that conform to the rules defined in sections on <a href="#linked-data-platform-resources">LDPRs</a>
 and <a href="#linked-data-platform-containers">LDPCs</a></p>.
@@ -340,11 +335,16 @@
 		[[!DC-TERMS]], RDF [[!RDF-PRIMER]] and RDF Schema [[!RDF-SCHEMA]], whenever
 		possible.
 	</div>
-	<div id="ldpr-4_1_5" class="rule">4.1.5 LDPRs MUST use the predicate <code>rdf:type</code> to
+	<div class="ldp-issue-pending">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/77">ISSUE-77</a></div>
+	why MUST a LDPR declare its type?  remove 4.1.5
+	</div>
+	</div>
+	<div id="ldpr-4_1_5" class="rule"><del>4.1.5 LDPRs MUST use the predicate <code>rdf:type</code> to
 		represent the concept of type. The use of non-standard type
 		predicates, as well as <code>dcterms:type</code>, is
 		discouraged, as it is not recommended
-		by the Dublin Core Metadata Initiative for use with RDF resources [[!DC-RDF]]. 
+		by the Dublin Core Metadata Initiative for use with RDF resources [[!DC-RDF]]. </del>
 	</div>
 	<div id="ldpr-4_1_6" class="rule">4.1.6 LDPR representations SHOULD have at least one <code>rdf:type</code>
 		set explicitly.  This makes the representations much more useful to
@@ -389,7 +389,7 @@
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/19">ISSUE-19</a></div>
 	Adressing more error cases
 	</div>	
-	<div class="ldp-issue-open">
+	<div class="ldp-issue-pending">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/32">ISSUE-32</a></div>
 	How can clients discover that a resource is an LDPR or LDPC, and what features are supported?
 	</div>
@@ -405,6 +405,38 @@
 		that can modify resources. For some server applications, excessive
 		constraints on modification of resources may be required.
 	</div>
+
+<div class="ldp-issue-pending">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/57">ISSUE-57</a></div>
+	How can a client determine that it is in communication with an LDP server?
+	</div>
+
+	<div id="ldpr-4_1_12" class="rule">4.1.12 LDPR servers
+		MUST advertise their LDP support by exposing a HTTP <code>Link</code> header
+		with a target URI of <code>http://www.w3.org/ns/ldp/Resource</code>, and
+		a link relation type of <code>type</code> (that is, <code>rel="type"</code>)
+		in all responses to requests made 
+		to the resource's HTTP <code>request-URI</code>. This is notionally equivalent to the
+		presence of a <code>< subject-URI, rdf:type , ldp:Resource ></code> triple in the resource.
+		The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP spec in a way
+		that clients can introspect dynamically at run-time.  Conservative clients should note that 
+		a server can host a mixture of LDPRs and other resources, and therefore there is no implication
+		that LDP support advertised on one HTTP <code>request-URI</code> means that other 
+		resources on the same server are also LDPRs.  Each HTTP <code>request-URI</code> needs to be 
+		individually introspected by a conservative client, in the absence of outside information.
+	</div>
+<div class="ldp-issue-pending">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/78">ISSUE-78</a></div>
+	inferencing levels
+	</div>
+
+	<div id="ldpr-4_1_13" class="rule">4.1.13 LDPR servers
+		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.  The practical implication is that all content defined by LDP
+		must be explicitly represented. 
+	</div>
+
 </section>
 
 <section>