--- a/ldp.html Thu Jul 11 09:13:26 2013 -0400
+++ b/ldp.html Thu Jul 11 14:05:00 2013 -0400
@@ -367,7 +367,7 @@
covered by other conformance rules.
</div>
<div id="ldpr-4_1_4_1" class="rule">4.1.4.1 LDPR predicates SHOULD use standard vocabularies such as Dublin Core
- [[!DC-TERMS]], RDF [[!RDF-PRIMER]] and RDF Schema [[!RDF-SCHEMA]], whenever
+ [[!DC-TERMS]], RDF [[!RDF-CONCEPTS]] and RDF Schema [[!RDF-SCHEMA]], whenever
possible.
</div>
<div id="ldpr-4_1_5" class="rule"><del>4.1.5 LDPRs MUST use the predicate <code>rdf:type</code> to
@@ -439,7 +439,7 @@
<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
+ to implement inferencing [[!RDF-CONCEPTS]]. The practical implication is that all content defined by LDP
must be explicitly represented.
</div>
@@ -1267,7 +1267,7 @@
Container MUST also be a conformant Linked Data Platform Resource.
</div>
<div id="ldpc-5_2_2" class="rule">5.2.2 For an LDPC,
- the same resource which is identified by its canonical URI, MAY be a member of
+ the same resource (LDPR or not) which is identified by its canonical URI, MAY be a member of
more than one LDPC.
</div>
<div id="ldpc-5_2_3" class="rule">5.2.3 The state of an LDPC includes information about which
@@ -1922,6 +1922,7 @@
<blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130701/">Third Public Working Draft</a></em></blockquote>
-->
<ul>
+ <li>2013-07-11 - Various editorial clean up items from editor todo list (SS)</li>
<li>2013-07-11 - Removed closed issues that required no new spec changes: 50, 56, 16, 19, 17 (SS)</li>
<li>2013-07-11 - ISSUE-51 Added how a LDPR can show which LDPC is it in (SS)</li>
<li>2013-07-10 - Removed closed issues that required no new spec changes: 18, 35, 20 (SS)</li>
@@ -2020,40 +2021,6 @@
<p>Other than LDP <a href="http://www.w3.org/2012/ldp/track/actions">open actions</a> and <a href="http://www.w3.org/2012/ldp/track/issues">issues</a>, included here are transient tasks and notes
editors use. They have no meaning in final product of a published working draft and will be removed prior to publishing.</p>
<ul>
- <li>5.1.4 ordering example - add example with >1 predicate, and collation sorting</li>
- <li>Insert some additional examples</li>
- <li>4.1.2: "the" subject ?= Request-URI ... not always (hash URIs)
- </li>
- <li>4.1.5: refers to RDF *Primer* - is that intentful?
- </li>
- <li>4.1.6.1: why does it have the extra .1, to avoid renumbering? should we divide General into subsections
- for vocab/client/server constraints? Do we need to define "LDPR server"? ...think about role vs artifact. If
- "an LDPR server" hosts both LDPRs and non-LDPR HTTP resources, 4.1.2 (if "the code" == LDPR server) could be
- read to say that in order to conform to spec it must serve up RDF for non-LDPRs. Hits 5.2.1 too.
- </li>
- <li>4.1.7: define "explicitly"?
- </li>
- <li>4.4.1: specifically calls out 2 props; issue-11 note talks about "server-managed props" which is not defined.
- </li>
- <li>4.4.4/4.4.5 could be read to overlap/dup one another
- </li>
- <li>Deployment guide (was: 4.8 Common Properties) talks about rdfs:Range which implies inferencing.
- 4.1.7 spec says want to avoid putting that reqt on clients.
- </li>
- <li>5.2.1: 4.1.6.1 issue linked to this text
- </li>
- <li>5.2.2: I think we mean "resource" == any HTTP resource, not just LDPR. If so, perhaps we should be more explicit.
- 5.2.1 might be the place.
- </li>
- <li>5.2.3-5.2.5: don't we need to tell clients to fetch LDPC's non-member properties, introspect for these predicates,
- and (if either not found) supply the defaults? that is the net effect of what's here.
- </li>
- <li>5.4.5: in light of the existence of server-managed properties, why not allow response body from create?
- </li>
- <li>Per David Wood, 'Sections 4.4.1, 4.5.1, 4.7.1, 5.4.1, 5.6.1 and 5.8.1 all relate to
- allowable write operations. I suggest adding the statement, "An LDPR server
- MAY require a user to be authenticated and authorized before this action is
- permitted." to each of those sections.', consider place to edit this in.</li>
<li>(IN)Consistency issues
<ul>
<li><a href="#ldpr-inlining" class="sectionRef"></a> + probably other sections say things like "LDP does not provide clients...".
@@ -2075,21 +2042,7 @@
</li>
<li>using respec section labeling consistently
</li>
- <li>
- </li>
- <li>
- </li>
- <li>
- </li>
- <li>
- </li>
- <li>
- </li>
- <li>
- </li>
- <li>
- </li>
- <li>
+ <li>update ldpc's with all required props
</li>
</ul>
</li>
@@ -2099,6 +2052,7 @@
Additional introductory text on the LDP data and interaction model
</div>
</section>
+
</body>
</html>