Updating some simple formatting, reorganizing open issues and todos
Mon, 25 Feb 2013 14:55:36 -0500
changeset 69 0f9825dea52b
parent 68 2160e1811b59
child 70 01e7d1ca8240
Updating some simple formatting, reorganizing open issues and todos
--- a/ldp.html	Mon Feb 25 12:21:15 2013 -0500
+++ b/ldp.html	Mon Feb 25 14:55:36 2013 -0500
@@ -150,11 +150,6 @@
 	narrow to provide a set of key rules for reading and writing Linked
 	Data that most, if not all, other specifications will depend on and
 	implementations will support.</p>   
-	<div class="ldp-issue">
-	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/37">ISSUE-37</a></div>
-	What is the LDP data model and the LDP interaction model?
-	</div>
@@ -285,7 +280,13 @@
 			LDPR. Clients SHOULD use the canonical URL as an LDPR's identity;
 			for example, when determining if two URLs refer to the same resource clients
 			need to compare the canonical URLs not the URLs used to access the resources.
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/49">ISSUE-49</a></div>
+	Canonical URL - how to communicate its value to clients
+	</div>
 	<div id="ldpr-4_1_5" class="rule">4.1.5 LDPRs SHOULD reuse existing vocabularies instead of creating
 		their own duplicate vocabulary terms.  In addition to this general rule, some specific cases are
 		covered by other conformance rules.
@@ -321,6 +322,11 @@
 		object of the triple representing the link (relationship) is enough and
 		does not require the creation of an intermediate link resource to
 		describe the relationship.
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/44">ISSUE-44</a></div>
+	4.1.9. is obscure or too restrictive
+	</div>
 	<div id="ldpr-4_1_10" class="rule">4.1.10 LDPR servers MAY support standard representations beyond those
 		necessary to conform to this specification. These
@@ -381,7 +387,7 @@
 		representations of the requested LDPR beyond those
 		necessary to conform to this specification, using standard HTTP content negotiation. 
 		If the client does not indicate a preference, <code>text/turtle</code> MUST be returned.
+	</div>
 	<div id="ldpr-4_2_4" class="rule">4.2.4 In the absence of special knowledge of the application or domain, LDPR
 		clients MUST assume that any LDPR can have multiple values for <code>rdf:type</code>.
@@ -1216,6 +1222,7 @@
 <h1>Change History</h1>
 <blockquote><em>First Public Working Draft</em></blockquote>
+	<li>2013-02-25 - Updating some simple formatting, reorganizing open issues and todos. (SS) </li>
 	<li>2013-02-15 - ISSUE-34 - Aggregration: 5.6.1 and 5.6.2 updated for review. (JA) </li>
 	<li>2013-02-13 - ISSUE-42 - 4.8 Common Properties moved to 
 			<a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Re-use_established_linked_data_vocabularies_instead_of_.28re-.29inventing_duplicates">Deploment Guide</a> 
@@ -1257,12 +1264,8 @@
 editors use.  They have not meaning in final product of a published working draft and will be removed prior to publishing.</p>
 	<li>Insert some additional examples</li>
-	<li>Expand on status code usages</li>
-	<li>Editor(Steve) to consider structure based on feedback from tbl and others</li>
 	<li>4.1.2: "the" subject ?= Request-URI  ... not always (hash URIs)
-	<li>4.1.4: Location or Content-Location?
-	</li>
 	<li>4.1.5: refers to RDF *Primer* - is that intentful?
 	<li> why does it have the extra .1, to avoid renumbering?  should we divide General into subsections
@@ -1289,10 +1292,11 @@
 	<li>5.4.5: in light of the existence of server-managed properties, why not allow response body from create?
-	<li>
-	</li>
+	<div class="ldp-issue">
+	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/37">ISSUE-37</a></div>
+	Additional introductory text on the LDP data and interaction model
+	</div>
 	<div class="ldp-issue">
 	<div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/5">ISSUE-5</a></div>
 	Add a section explaining how LDP is related to Graph Store Protocol