--- a/ldp.html Mon Feb 10 13:25:54 2014 -0500
+++ b/ldp.html Mon Feb 10 15:22:40 2014 -0500
@@ -1,26 +1,27 @@
<!DOCTYPE html>
<!--
- Editor TODO:
- - Search "TODO" within this document.
- - Once companion documents (best practices, primer) have URLs, link to them. Search on "companion".
- - Once the membership* names stabilize, take a pass through for "membership consistent value", membership-constant-URI
+ TODO: Search for them within this document.
+ TODO: Once companion documents (best practices, primer) have URLs, link to them. Search on "companion".
+ TODO: Stabilize membership* names
+ TODO: Once the membership* names stabilize, take a pass through for "membership consistent value", membership-constant-URI
and see if there is a friendlier way to phrase it.
- - Paging intro: add 3rd example showing header linkage amongst pages and (HEAD on) the base resource.
+ TODO: Paging intro: add 3rd example showing header linkage amongst pages and (HEAD on) the base resource.
Maybe also insert HEAD on base as new first example instead of relying on text alone.
- - 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?
+ 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
Various pre-LC comments:
- - 5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:containsRelation,
+ - TODO: (now 6.2.7) 5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:containsRelation,
5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of ldp:containedByRelation,
5.2.10 Some LDPC's have membership object's that are not directly URIs minted upon LDPC member creation,
(JohnA) I found these particularly hard to read. And I perpetrated the SortCollation paragraphs.
Links to examples might be an 80-20 solution.
- - 5.3.1: I'd change the link to the example ("as in the example") to refer the concrete example #, I think example 9.
+ - TODO: 5.3.1: I'd change the link to the example ("as in the example") to refer the concrete example #, I think example 9.
Currently does not work when printing.
Misc during LC comments:
- - http://lists.w3.org/Archives/Public/public-ldp/2013Aug/0002.html
- #1 Should update example in 5.1.3 to be more clear on what the request vs base URI is. Also example is missing ldp:nextPage.
+ - TODO: #1 Should update example in 5.1.3 to be more clear on what the request vs base URI is. Also example is missing ldp:nextPage.
+ http://lists.w3.org/Archives/Public/public-ldp/2013Aug/0002.html
-->
<html>
<head>
@@ -734,7 +735,7 @@
<code>PUT</code> (<a href="#ldpc-HTTP_PUT" class="sectionRef"></a>) to a LDPC, see those
sections for more details. Any server-imposed constraints on LDPR creation or update
<a href="#ldpr-gen-pubclireqs">must be advertised</a> to clients.
- <!-- TODO: movethis content into an intro/overview section and add PATCH. -->
+
</p>
</section>
@@ -1121,7 +1122,7 @@
Note that LDP only requires enough from <code>OPTIONS</code>
for discovery of paging support on a resource, which is considerably
less than is required for HTTP <code>GET</code>.
- This lowers server implementation effort.
+ This lowers server implementation effor t.
</p>
<!-- TODO: This section is empty - looks weird, and it is linked to from other sections -->
@@ -1566,7 +1567,7 @@
might have additional types</a>, like any RDF resource.
</h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
- <!-- TODO: For LDP-BC, are the empty-container props still needed or infered? -->
+
<section id="ldpc-nordfcontainertypes"><h2 class="normal">LDPC representations SHOULD NOT use RDF container types <code>rdf:Bag</code>,
<code>rdf:Seq</code> or <code>rdf:List</code>.
@@ -1589,9 +1590,6 @@
any kind of resource identified by a URI, LDPR or otherwise.
</h2></section><!-- Was 5.2.3 / #ldpc-5_2_3 -->
- <!-- TODO: Leaving this as-is, refining others as-needed. Do we need an explicit clause for "ldp:contains"?
- -->
-
<section id="ldpc-containres"><h2 class="normal">Each <a title="Linked Data Platform Direct Container">LDP Direct Container</a>
and <a title="Linked Data Platform Indirect Container">LDP Indirect Container</a> representation MUST contain exactly one triple
whose subject is the LDPC URI,
@@ -1833,10 +1831,6 @@
through other means.
</h2></section><!-- Was 5.4.2 / #ldpc-5_4_2 -->
- <!-- TODO: "contained resource" is not the right term here, an example of where ldp:containedResource would be better
- labeled ldp:membershipResource (maybe)-->
- <!-- TODO: Do we need a rule for creation of ldp:contains here? Steve's answer, no...leave to ldp:contains rule. -->
-
<section id="ldpc-post-createbins"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY accept an HTTP <code>POST</code> of non-RDF representations
<a title="Linked Data Platform Binary Resource">(LDP-BRs)</a> for
creation of any kind of resource, for example binary resources. See <a href="#ldpc-post-acceptposthdr">the Accept-Post section</a> for
@@ -1881,8 +1875,8 @@
<section id="ldpc-post-mincontraints"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to create new resources without
requiring detailed knowledge of application-specific constraints.
This is a consequence of the requirement to enable simple creation and modification of LDPRs.
- <!-- TODO: Consider reference to 4.2.13 to include Link rel='desribedBy' header for such constraints.
- Also, should this call out LDPRs explicity? Would think we could just have "resources" statement. -->
+ <!-- TODO: Consider reference to 4.2.13 to include Link rel='desribedBy' header for such constraints. Waiting for common creating-resources section.
+ -->
</h2></section><!-- Was 5.4.9 / #ldpc-5_4_9 -->
<section id="ldpc-post-slug"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY allow clients to suggest the URI for a resource
@@ -1981,8 +1975,8 @@
</p>
<section id="ldpc-del-contremovesmbrtriple"><h2 class="normal">
- When a LDPC contained resource is deleted, the LDPC server MUST also remove it from
- the LDPC by removing the corresponding containment and membership triples.
+ When a LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, the LDPC server MUST also remove
+ the LDPR from the containing LDPC by removing the corresponding containment and membership triples.
</h2>
<blockquote>
Non-normative note: The <a>LDP server</a> might perform additional actions,
@@ -1992,24 +1986,8 @@
</blockquote>
</section><!-- Was 5.6.1 / #ldpc-5_6_1 -->
- <!-- combined with clause above
- <section id="ldpc-del-mbrremovesmbrtriple"><h2 class="normal">
- When a <a>LDP server</a> successfully completes a <code>DELETE</code> request
- on a LDPC member resource, it MUST remove any
- membership triples associated with the deleted member resource identified by the <code>Request-URI</code>.
- </h2> </section><!-- Was 5.6.2 / #ldpc-5_6_2 -->
-
- <!-- TODO: All these constraints apply only to LDPC contained resources being deleted, so clarify that up front of the section hey? -->
-
- <!-- containment now required, handled in clause above
- <section id="ldpc-del-ldpcreated"><h2 class="normal">
- When the conditions in <a href="#ldpc-del-contremovesmbrtriple">previous section</a> hold, and the LDPC tracks member
- resources that it created using the <code>ldp:contains</code> predicate, the LDPC server MUST also remove
- the deleted member's <code>ldp:contains</code> triple.
- </h2></section><!-- Was 5.6.3 / #ldpc-5_6_3 -->
-
<section id="ldpc-del-contremovesmbrres"><h2 class="normal">
- When a LDPC contained resource is deleted, and the LDPC server
+ When a LDPR identified by the object of a <a title="containment triples">containment triple</a> is deleted, and the LDPC server
created an associated LDP-RR (see the <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also remove the associated LDP-RR it created.
</h2></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
@@ -2057,11 +2035,12 @@
header whose target URI is the associated LDP-RR, and whose link relation type is
<code>meta</code> [[!RFC5988]].
- <!-- TODO: Consider some improvement to this:
+ <!-- TODO: Consider some improvement to #ldpc-options-linkmetahdr
Does a LDPC create a non-LDPR? or does and LDPC server do this?
What is "it" in the first sentence?
Adding a Request-URI clause to the last sentence may help clarify a couple things.
+ Metadata resource definition?
-->
</h2></section><!-- Was 5.9.2 / #ldpc-5_9_2 -->
@@ -2372,12 +2351,6 @@
</section> <!-- Prefer specification -->
<section id="prefer-examples" class="informative">
<h3>Examples</h3>
-<!-- TODO: flesh out examples ? not sure how many we really need.
- Ted's email http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jan/0136.html had:
- none, c only, m only, m+c, all
- separate ex's for basic, in/direct, include, exclude?
- ex for complete absence of hint?
--->
<p>
If we assume a container like
the one below:
@@ -2627,6 +2600,7 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130730/">Last Call Draft</a></em></blockquote> -->
<ul>
+ <li>2014-02-10 - Updated LDPC DELETE language and cleanup todos (SS)</li>
<li>2014-02-10 - Resolved a few editoral TODO's (JA)</li>
<li>2014-02-08 - Put final stake in heart of 'informative' (waves to Sandro), update boilerplate for readability per Arnaud (JA)</li>
<li>2014-02-08 - ACTION-132: Use Prefer in place of non-member properties resource (JA)</li>