--- a/ldp.html Tue Nov 12 13:27:44 2013 -0500
+++ b/ldp.html Tue Nov 12 17:18:32 2013 -0500
@@ -1,6 +1,7 @@
<!DOCTYPE html>
<!--
Editor TODO:
+ - Convert cases like 5.4.3 to a sectionRef ... search on sectionRef in case numbers change
- Once companion documents have URLs, link to them. Search on "companion".
- In #ldpr-HTTP_POST, move "Clients can create LDPRs via" content into an intro/overview section and add PATCH.
- Once the membership* names stabilize, take a pass through for "membership consistent value", membership-constant-URI
@@ -21,8 +22,8 @@
- 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?
Various pre-LC comments:
- - 5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicate,
- 5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of ldp:membershipPredicateInverse,
+ - 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.
@@ -233,8 +234,8 @@
</li>
<li>Include links to other URIs, so that they can discover more things</li>
</ol>
- <p>This specification discusses standard HTTP and RDF techniques that you
- should use when constructing clients and servers that
+ <p>This specification discusses standard HTTP and RDF techniques
+ used when constructing clients and servers that
create, read, and write <a title="Linked Data Platform Resource">Linked Data Platform Resources</a>.
A companion document discusses best practices that you
should use, and anti-patterns you should avoid, when constructing these clients and servers.
@@ -242,7 +243,8 @@
<p>This specification provides a widely re-usable pattern to deal with large resources.
Depending on the server’s capabilities, a GET request on a <a title="Paged resource">resource</a> can
return a <a title="Single-page resource">subset of the resource (one page)</a>, that provides access to subsequent pages
- (see <a href="#ldpr-Paging" class="sectionRef"></a>). </p>
+ (see <a href="#ldpr-Paging" class="sectionRef"></a>).
+ </p>
<p>This specification defines a special type of <a>Linked Data Platform Resource</a>: a
<a title="Linked Data Platform Container">Container</a>. Containers are very useful
in building application models involving collections of resources, often homogeneous ones.
@@ -302,23 +304,24 @@
<tr>
<td style="padding:0 0 0 +2ex"> <var style="background:#DDDDDD">membership-constant-URI</var> </td>
<td style="padding:0 0 0 +2ex"> <var>membership-predicate</var> </td>
- <td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-URI</var> </td>
+ <td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-derived-URI</var> </td>
</tr>
<tr>
- <td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-URI</var> </td>
+ <td style="padding:0 0 0 +2ex"> <var style="background:#CCFFFF">member-derived-URI</var> </td>
<td style="padding:0 0 0 +2ex"> <var>membership-predicate</var> </td>
<td style="padding:0 0 0 +2ex"> <var style="background:#DDDDDD">membership-constant-URI</var> </td>
</tr>
</table>
- The difference between the two is simply which position member-URI occupies, which is usually
+ The difference between the two is simply which position member-derived-URI occupies, which is usually
driven by the choice of <var>membership-predicate</var>. Most predicates have a natural forward direction
inherent in their name, and existing vocabularies contain useful examples that read naturally in
each direction. <code>rdfs:member</code> and <code>dcterms:isPartOf</code> are representative examples.
<p>
- Each container exposes properties that allow clients to determine which pattern it
+ Each container exposes properties (see <a href="#ldpc-general" class="sectionRef"></a>)
+ that allow clients to determine which pattern it
uses, what the actual <var>membership-predicate</var> and <var>membership-constant-URI</var> values are,
and (for containers that allow the creation of new members) what value is used
- for the <var>member-URI</var> based on the client's input to the
+ for the <var>member-derived-URI</var> based on the client's input to the
creation process.</p>
<p></p></dd>
@@ -327,7 +330,7 @@
<p></p></dd>
<dt><dfn>Non-member resource</dfn></dt>
- <dd>A resource associated with a LDPC by a server for the purpose of enabling clients to
+ <dd>A HTTP resource associated with a LDPC by a server for the purpose of enabling clients to
retrieve a subset of the LDPC's state, namely the subset that omits the LDPC's membership triples.
In other words, the union of the non-member resource's state and the LDPC's membership triples
exactly equals the LDPC's state.
@@ -343,7 +346,7 @@
a subset of the triples in <var>P</var>.
LDP allows paging of resources other than LDPRs, but does not specify how clients combine
their representations. See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details. For readers
- familiar with paged feeds [[!RFC5005]], a paged resource is similar to a logical feed.
+ familiar with paged feeds [[RFC5005]], a paged resource is similar to a logical feed.
Any resource could be considered to be a paged resource consisting of exactly one page,
although there is no known advantage in doing so.
<p></p></dd>
@@ -353,7 +356,7 @@
each of which contains a subset of the state
of another resource <var>P</var>. <var>P</var> is called the paged resource.
For readers
- familiar with paged feeds [[!RFC5005]], a single-page resource is similar to a feed document and the same
+ familiar with paged feeds [[RFC5005]], a single-page resource is similar to a feed document and the same
coherency/completeness considerations apply.
<a href="#ldpr-pagingGET-sequences-change">LDP provides no guarantees that the sequence is stable</a>.
</p><p>
@@ -375,7 +378,7 @@
<dd>A link to the next <a title="Single-page resource">single-page resource</a>
of a <a title="Paged resource">paged resource</a> <var>P</var>. Syntactically, a
HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='next'</code>
- header [[!RFC5988]] where <var>i=2...n</var>.
+ header [[!RFC5988]] where the target URI is <var>P<sub>i=2...n</sub></var>.
<p></p></dd>
<dt><dfn>last page link</dfn></dt>
@@ -389,7 +392,7 @@
<dd>A link to the previous <a title="Single-page resource">single-page resource</a>
of a <a title="Paged resource">paged resource</a> <var>P</var>. Syntactically, a
HTTP <code>Link <<var>P<sub>i</sub></var>>; rel='prev'</code>
- header [[!RFC5988]] where <var>i=1...n-1</var>.
+ header [[!RFC5988]] where the target URI is <var>P<sub>i=1...n-1</sub></var>.
<p></p></dd>
</dl>
@@ -447,56 +450,6 @@
LDP does not constrain its behavior when serving other HTTP resources.
</p>
-<p>(NEW) LDP defines several classes of LDP servers, and places different conformance requirements on each of them.
-NOTE: "Basic" and "advanced" used here for drafting purposes; they correspond to 'vanilla' and 'chocolate', respectively.
-Final names TBD.
-</p>
-<ul>
- <li><p>A conforming <b><dfn>basic LDP server</dfn></b> is a conforming LDP server that follows the rules defined by LDP
- for basic LDP servers, as shown below. Its content model is generally open and the server typically stores triples on behalf of clients
- with minimal (if any) restrictions.
- </p></li>
- <li><p>A conforming <b><dfn>advanced LDP server</dfn></b> is a conforming LDP server that follows the rules defined by LDP
- for advanced LDP servers, as shown below. Its content model can be open or closed, and the server may impose non-trivial
- restrictions on triples stored on behalf of conforming HTTP clients.
- </p></li>
-</ul>
-
-<section>
-<h5>Example conformance rules</h5>
-
-<p>The following informative examples show how LDP assigns conformance criteria to each class of LDP servers using a single rule.</p>
-
-<section>
-<h6>Example: the same criteria apply to both basic and advanced LDP servers</h6>
-<div class="example">
- <div class="rule">LDP servers SHOULD ... </div>
-</div>
-
-<p>The preceding rule is equivalent to the following pair of rules:</p>
-<div class="example">
- <div class="rule">Basic LDP servers SHOULD ... </div>
- <div class="rule">Advanced LDP servers SHOULD ... </div>
-</div>
-</section>
-
-<section>
-<h6>Example: different criteria apply to basic and advanced LDP servers</h6>
-<p>Trying out different ways of covering each class while minimizing text duplication here. Final format TBD.</p>
-<div class="example">
- <div class="rule">(proposal 1) LDP servers MUST (basic)/SHOULD (advanced) ... </div>
- <div class="rule">(proposal 2) Basic LDP servers MUST, and advanced LDP servers SHOULD, ... </div>
- <div class="rule">(proposal 3) Basic LDP servers MUST ... . Advanced LDP servers SHOULD do so. </div>
-</div>
-
-<p>Each of the preceding rules is equivalent to the following pair of rules:</p>
-<div class="example">
- <div class="rule">4.8.2 Basic LDP servers MUST ...
- </div>
- <div class="rule">4.8.2 Advanced LDP servers SHOULD ...
- </div>
-</div>
-</section>
</div>
@@ -1139,12 +1092,12 @@
be a predicate from the server application vocabulary or the <code>rdfs:member</code> predicate.
</p>
<p>This document includes a set of guidelines for
- using POST to create new resources and add them to the list of
+ creating new resources and adding them to the list of
members of a container. It goes on to explain how to learn about a set of related
- resources, they may have been created using POST or through other means.
- It also defines behavior when POST created resources are deleted, to clean up
- container membership, and deleting containers removes membership information and
- possibly perform some cleanup tasks on unreferenced member resources.</p>
+ resources, regardless of how they were created or added to the container's membership.
+ It also defines behavior when resources created using a container are later deleted;
+ deleting containers removes membership information and
+ possibly performs some cleanup tasks on unreferenced member resources.</p>
<p>The following illustrates a very simple
container with only three members and some information about the
@@ -1160,9 +1113,9 @@
<>
a ldp:Container;
- ldp:membershipSubject <> ;
- ldp:membershipPredicate rdfs:member;
- ldp:membershipObject ldp:MemberSubject;
+ ldp:containerResource <> ;
+ ldp:containsRelation rdfs:member;
+ ldp:insertedContentRelation ldp:MemberSubject;
dcterms:title "A very simple container";
rdfs:member <member1>, <member2>, <member3>.</pre>
@@ -1225,16 +1178,16 @@
<assetContainer/>
a ldp:Container;
dcterms:title "The assets of JohnZSmith";
- ldp:membershipSubject <>;
- ldp:membershipPredicate o:asset;
- ldp:membershipObject ldp:MemberSubject.
+ ldp:containerResource <>;
+ ldp:containsRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
<liabilityContainer/>
a ldp:Container;
dcterms:title "The liabilities of JohnZSmith";
- ldp:membershipSubject <>;
- ldp:membershipPredicate o:liability;
- ldp:membershipObject ldp:MemberSubject.
+ ldp:containerResource <>;
+ ldp:containsRelation o:liability;
+ ldp:insertedContentRelation ldp:MemberSubject.
</pre>
<p>The essential structure of the container is
@@ -1262,9 +1215,9 @@
<>
a ldp:Container;
- ldp:membershipSubject <http://example.org/netWorth/nw1>;
- ldp:membershipPredicate o:asset;
- ldp:membershipObject ldp:MemberSubject.
+ ldp:containerResource <http://example.org/netWorth/nw1>;
+ ldp:containsRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
<http://example.org/netWorth/nw1>
a o:NetWorth;
@@ -1275,54 +1228,8 @@
triples whose subject is the LDPC resource itself.
</p>
- <div id="ldpc-member_data" class="rule informative">5.1.1 Container Member Information</div>
- <p>In many – perhaps most – applications
- involving containers, it is desirable for the client to be able to
- get information about each container member without having to do a
- GET on each one. LDPC allows servers to include this information
- directly in the representation of the container. The server decides
- the amount of data about each member that is provided. Some common
- strategies include providing a fixed number of standard properties,
- or providing the entire RDF representation of each member resource,
- or providing nothing. The server application domain and its use-cases
- will determine how much information is required.</p>
-
- <p>Continuing on from the net worth
- example, there will be additional triples for the member resources
- (assets) in the representation:</p>
-
-<pre class="example"># The following is the representation of
-# http://example.org/netWorth/nw1/assetContainer/
-<!-- @base is here only so it's easier to paste into validators for checking -->
-# @base <http://example.org/netWorth/nw1/assetContainer/>
-@prefix dcterms: <http://purl.org/dc/terms/>.
-@prefix ldp: <http://www.w3.org/ns/ldp#>.
-@prefix o: <http://example.org/ontology/>.
-<>
- a ldp:Container;
- dcterms:title "The assets of JohnZSmith";
- ldp:membershipSubject <http://example.org/netWorth/nw1>;
- ldp:membershipPredicate o:asset;
- ldp:membershipObject ldp:MemberSubject.
-
-<http://example.org/netWorth/nw1>
- a o:NetWorth;
- o:asset <a1>, <a3>, <a2>.
-
-<a1>
- a o:Stock;
- o:value 10000 .
-<a2>
- a o:Bond;
- o:value 20000 .
-<a3>
- a o:RealEstateHolding;
- o:value 300000 .</pre>
- <p>In a similar manner, when the representation for the resource of asset <var>.../<a1></var> is returned a
- server may include the membership triple of the form <var>(.../nw1, o:asset, .../a1).</var></p>
-
- <div id="ldpc-get_non-member_props" class="rule">5.1.2 Retrieving Only Non-member Properties
+ <div id="ldpc-get_non-member_props" class="rule">5.1.1 Retrieving Only Non-member Properties
</div>
<p>The representation of a container
that has many members will be large. There are several important
@@ -1362,15 +1269,15 @@
<http://example.org/container1/>
a ldp:Container;
dcterms:title "A Linked Data Platform Container of Acme Resources";
- ldp:membershipSubject <http://example.org/container1/>;
- ldp:membershipPredicate rdfs:member;
- ldp:membershipObject ldp:MemberSubject;
+ ldp:containerResource <http://example.org/container1/>;
+ ldp:containsRelation rdfs:member;
+ ldp:insertedContentRelation ldp:MemberSubject;
dcterms:publisher <http://acme.com/>.</pre>
<p>While the same non-member resource could be used to update the non-member properties via PUT,
LDP recommends using PATCH for this purpose.</p>
- <div id="ldpc-ordering" class="rule">5.1.3 Ordering</div>
+ <div id="ldpc-ordering" class="rule">5.1.2 Ordering</div>
<p>
There are many cases where an ordering of the members of the
container is important. LDPC does not provide any particular support
@@ -1418,9 +1325,9 @@
<>
a ldp:Container;
dcterms:title "The assets of JohnZSmith";
- ldp:membershipSubject <http://example.org/netWorth/nw1>;
- ldp:membershipPredicate o:asset;
- ldp:membershipObject ldp:MemberSubject.
+ ldp:containerResource <http://example.org/netWorth/nw1>;
+ ldp:containsRelation o:asset;
+ ldp:insertedContentRelation ldp:MemberSubject.
<?firstPage>
a ldp:Page;
@@ -1470,50 +1377,68 @@
</div>
-->
<div id="ldpc-5_2_3" class="rule">5.2.3 <a title="LDP server">LDP servers</a>
- SHOULD use the <code>rdfs:member</code> predicate
- If there is no obvious predicate from an application vocabulary to use.
+ SHOULD use the <code>rdfs:member</code> predicate as an LDPC's <a title="Membership predicate">membership predicate</a>
+ if there is no obvious predicate from an application vocabulary to use.
The state of an LDPC includes information about which
resources are its members, in the form of <a title="Membership triples">membership triples</a> that
follow a consistent pattern. The LDPC's state contains enough information for clients to discern
the <a title="Membership predicate">membership predicate</a>, the other consistent membership
- value used in the container's membership triples, and the position (subject or object) where the member's URI
- occurs in those triples.
+ value used in the container's membership triples (<var>membership-constant-URI</var>),
+ and the position (subject or object) where those URIs
+ occurs in the <a title="Membership triples">membership triples</a>.
Member resources can be
any kind of resource identified by a URI, LDPR or otherwise.
</div>
<div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC representation MUST contain exactly one triple
whose subject is the LDPC URI,
- whose predicate is the <code>ldp:membershipSubject</code>,
- and whose object is the LDPC's membership subject URI.
+ whose predicate is the <code>ldp:containerResource</code>,
+ and whose object is the LDPC's membership-constant-URI.
+ Commonly the LDPC's URI is the membership-constant-URI, but LDP does not require this.
</div>
-<div class="ldp-issue-open">
-<div class="ldp-issue-title">Issue-81: confusing predicate names</div>
-"membership subject" has been removed too. Remove this use of it as part of Issue-81 resolution.
-</div>
<div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC representation MUST contain exactly one triple
whose subject is the LDPC URI,
- and whose predicate is either <code>ldp:membershipPredicate</code> or <code>ldp:membershipPredicateInverse</code>.
+ and whose predicate is either <code>ldp:containsRelation</code> or <code>ldp:containedByRelation</code>.
The object of the triple is constrained by other sections, such as
- <a href="#ldpc-5_2_5_1">5.2.5.1</a> or <a href="#ldpc-5_2_5_2">5.2.5.2</a>.
+ <a href="#ldpc-5_2_5_1">5.2.5.1</a> or <a href="#ldpc-5_2_5_2">5.2.5.2</a>, based on the
+ <a title="Membership triples">membership triple</a>
+ pattern used by the container.
</div>
+ <div id="ldpc-5_2_5_1" class="rule">5.2.5.1 LDPCs whose <a title="Membership triples">membership triple</a>
+ pattern is <var>( membership-constant-URI , membership-predicate , member-derived-URI )</var> MUST
+ contain exactly one triple
+ whose subject is the LDPC URI,
+ whose predicate is either <code>ldp:containsRelation</code>,
+ and whose object is the URI of <var>membership-predicate</var>.
+ </div>
+ <!-- Action-112 rewrote this 2013-11-12, original in this comment
<div id="ldpc-5_2_5_1" class="rule">5.2.5.1 For a given triple <var>T</var> with a subject <var>C</var>
of the LDPC and predicate of
- <code>ldp:membershipPredicate</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
- indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:membershipPredicate</code>, <var>P)</var>.
+ <code>ldp:containsRelation</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
+ indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:containsRelation</code>, <var>P)</var>.
For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
same subject <var>R</var> and same predicate <var>P</var> membership triples of the form:
(<var>R</var>, <var>P</var>, <var>MR</var>), where <var>MR</var> represents URI of
a member resource.
</div>
+ -->
+ <div id="ldpc-5_2_5_2" class="rule">5.2.5.2 LDPCs whose <a title="Membership triples">membership triple</a>
+ pattern is <var>( member-derived-URI , membership-predicate , membership-constant-URI )</var> MUST
+ contain exactly one triple
+ whose subject is the LDPC URI,
+ whose predicate is either <code>ldp:containedByRelation</code>,
+ and whose object is the URI of <var>membership-predicate</var>.
+ </div>
+ <!-- Action-112 rewrote this 2013-11-12, original in this comment
<div id="ldpc-5_2_5_2" class="rule">5.2.5.2 For a given triple <var>T</var> with a subject <var>C</var>
of the LDPC and predicate of
- <code>ldp:membershipPredicateInverse</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
- indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:membershipPredicateInverse</code>, <var>P)</var>.
+ <code>ldp:containedByRelation</code>, the object MUST be the URI of the membership predicate <var>P</var> used to
+ indicate membership to the linked to LDPC, or simply: <var>T = ( C</var>, <code>ldp:containedByRelation</code>, <var>P)</var>.
For the membership predicate URI object used in the triple <var>T</var>, it would be found in a resource's
object subject <var>R</var> and same predicate <var>P</var> membership triples of the form:
(<var>MR</var>, <var>P</var>, <var>R</var>), where <var>MR</var> represents URI of
a member resource.
</div>
+ -->
<!-- Action-108 removed this 2013-10-22
<div id="ldpc-5_2_6" class="rule">5.2.6 The representation of a LDPC MAY include an arbitrary number of
additional triples whose subjects are the members of the container,
@@ -1540,28 +1465,59 @@
scenarios, re-using URIs creates ambiguities for clients that are best avoided.
</div>
-->
+ <div id="ldpc-5_2_10" class="rule">5.2.10 LDPCs MUST contain one triple whose
+ subject is the LDPC URI,
+ whose predicate is <code>ldp:insertedContentRelation</code>, and
+ whose object <var>ICR</var> describes how the <var>member-derived-URI</var> in
+ the container's <a title="Membership triples">membership triples</a> is chosen.
+ <ul>
+ <li>
+ LDP defines the URI <code>ldp:MemberSubject</code> for the common case where
+ <var>member-derived-URI</var> is simply the URI assigned by the server to a
+ document it creates; for example, if the client POSTs RDF content to a container
+ that causes the container to create a new LDPR, <code>ldp:MemberSubject</code> says
+ that the <var>member-derived-URI</var> is the URI assigned to the newly created LDPR.
+ LDPCs MUST use the URI <code>ldp:MemberSubject</code> when the <var>member-derived-URI</var>
+ is chosen in this way.
+ </li>
+ <li>
+ In other cases, the <var>member-derived-URI</var> is taken from some triple
+ <var>( S, P, O)</var> in the document supplied by the client as input to the create request;
+ if <var>ICR</var>'s value is <var>P</var>, then the <var>member-derived-URI</var> is
+ <var>O</var>. LDP does not define the behavior when more than one triple containing
+ the predicate <var>P</var> is present in the client's input.
+ For example, if the client POSTs RDF content to a container
+ that causes the container to create a new LDPR, and that content contains the triple
+ <var>( <> , foaf:primaryTopic , mypet#Zaza )</var>
+ <code>foaf:primaryTopic</code> says
+ that the <var>member-derived-URI</var> is <var>mypet#Zaza</var>.
+ </li>
+ </ul>
+ <!-- Action-112 rewrote this 2013-11-12, original in this comment
<div id="ldpc-5_2_10" class="rule">5.2.10 Some LDPCs have members whose URIs are not directly
URIs minted upon LDPC member creation, for example URIs with a non-empty fragment identifier [[RFC3986]].
- To determine which member URI to use in the membership triple, LDPCs MUST contain one triple whose
- subject is the LDPC URI, whose predicate is <code>ldp:membershipObject</code>, and whose object is <var>MO</var>.
+ To determine which member URI to use as the <var>member-derived-URI</var>
+ in the membership triple, LDPCs MUST contain one triple whose
+ subject is the LDPC URI, whose predicate is <code>ldp:insertedContentRelation</code>, and whose object is <var>MO</var>.
<var>MO</var> and the HTTP URI <var>R</var> from <code>POST</code> create
(as found in HTTP response <code>Location</code> header) are
used to locate a triple in <var>R</var> of the form <var>(R, MO, N)</var>.
- When the LDPC uses <code>ldp:membershipPredicate</code>,
+ When the LDPC uses <code>ldp:containsRelation</code>,
<var>N</var> is then used to construct the membership triple of the form:
<var>(membership consistent value, membership predicate, N)</var>.
- When the LDPC uses <code>ldp:membershipPredicateInverse</code>,
+ When the LDPC uses <code>ldp:containedByRelation</code>,
the membership triple is
of the form: <var>(N, membership predicate, membership consistent value)</var>.
To indicate that the member resource URI is the membership object
(the default or typical case), the object MUST be set to predefined URI <code>ldp:MemberSubject</code>
such that it forms the triple:
- <var>(LDPC URI, <code>ldp:membershipObject</code>, <code>ldp:MemberSubject</code>)</var>.
+ <var>(LDPC URI, <code>ldp:insertedContentRelation</code>, <code>ldp:MemberSubject</code>)</var>.
</div>
+ -->
<!-- NOTE: Saving this sample to help with future editing/understanding or possible insertion directly.
- Let's say this LDPC has a membershipSubject of </people/roger> and membershipPredicate of pets:has_pet. If I POST the following to the LDPC:
+ Let's say this LDPC has a containerResource of </people/roger> and containsRelation of pets:has_pet. If I POST the following to the LDPC:
<> foaf:primaryTopic <#this> .
<#this>
@@ -1576,13 +1532,13 @@
</people/roger> pets:has_pet </people/roger/zaza#this>.
- To do this, you'd have to use ldp:membershipObject such as:
+ To do this, you'd have to use ldp:insertedContentRelation such as:
pets:has_pet
a ldp:Container;
- ldp:membershipPredicate pets:has_pet;
- ldp:membershipSubject </people/roger>;
- ldp:membershipObject foaf:primaryTopic .
+ ldp:containsRelation pets:has_pet;
+ ldp:containerResource </people/roger>;
+ ldp:insertedContentRelation foaf:primaryTopic .
-->
</section>
@@ -1612,7 +1568,8 @@
The first list entry provides the primary
sorting criterion, any second entry provides a secondary criterion used to order members considered
equal according to the primary criterion, and so on.
- See section <a href="#ldpc-ordering">5.1.4 Ordering</a> for
+ <!-- Convert cases like this to a sectionRef -->
+ See section <a href="#ldpc-ordering">5.1.3 Ordering</a> for
an example.
</div>
<div id="ldpc-5_3_3" class="rule">5.3.3 LDPC page representations
@@ -1783,16 +1740,13 @@
</div>
<div id="ldpc-5_5_2" class="rule">5.5.2 <a title="LDP server">LDP servers</a> MAY allow updating LDPC non-membership properties using
HTTP <code>PUT</code> on a corresponding <a>non-member resource</a>, which
- MAY exclude server-managed properties such as <code>ldp:membershipSubject</code>, <code>ldp:membershipPredicate</code>
- and <code>ldp:membershipPredicateInverse</code>.
+ MAY exclude server-managed properties such as <code>ldp:containerResource</code>, <code>ldp:containsRelation</code>
+ and <code>ldp:containedByRelation</code>.
The <a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a> describes the process by which clients
use HTTP <code>OPTIONS</code> to discover whether the server offers such a resource, and if so its URL.
</div>
- <div id="ldpc-5_5_3" class="rule">5.5.3 <a title="LDP server">LDP servers</a> SHOULD NOT allow HTTP <code>PUT</code> requests
- with member resource information in the request representation.
- See section <a href="#ldpc-member_data">5.1.1 Container
- Member Information</a> for additional details.
+ <div id="ldpc-5_5_3" class="rule">5.5.3 removed - inlining
</div>
<div id="ldpc-5_5_4" class="rule">5.5.4 <a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code>
@@ -1869,7 +1823,8 @@
<a>non-member resource</a>
to support requests for information about a LDPC
without retrieving a full representation including all of its members;
- see section <a href="#ldpc-get_non-member_props">5.1.2 Retrieving Only Non-member Properties</a> for
+ <!-- sectionref this -->
+ see section <a href="#ldpc-get_non-member_props">5.1.1 Retrieving Only Non-member Properties</a> for
examples.
In responses to <code>OPTIONS</code> requests with an LDPC as the <code>Request-URI</code>,
<a title="LDP server">LDP servers</a> that define a non-member resource SHOULD provide an HTTP <code>Link</code>
@@ -2207,6 +2162,9 @@
<!-- <blockquote><em><a href="http://www.w3.org/TR/2013/WD-ldp-20130930/">Candidate Recommendation Draft</a></em></blockquote> wah -->
<ul>
+ <li>2013-11-12 - Clean up some remnants of inlining (JA)</li>
+ <li>2013-11-12 - Clean up some overly specific language (implications that POST is the only way to create members, etc) (JA)</li>
+ <li>2013-11-12 - Resolve ACTION-112 Update spec to reflect 10/28 resolution for Issue-81 part 1: new predicate names (JA)</li>
<li>2013-11-12 - Fix respec messages that only show up on remote server, hit paging examples to remove appearance of inlining (JA)</li>
<li>2013-11-11 - Resolve ACTION-113 Update spec to reflect 11/04 resolution to remove 303 and have client use first/next links to detect paging (JA)</li>
<li>2013-10-25 - Resolve ACTION-105 Update spec to reflect 9/30 resolution moving Paging links to HTTP headers (JA)</li>
@@ -2241,7 +2199,7 @@
<li>2013-07-23 - ISSUE-53 4.2.3 changed MUST to SHOULD (SS)</li>
<li>2013-07-22 - ISSUE-53 4.2.2 changed MUST to SHOULD (SS)</li>
<li>2013-07-17 - Various updates from suggests from <a href="http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0067.html">Raúl</a> (SS)</li>
- <li>2013-07-15 - Inserted ldp:membershipObject into examples (SS)</li>
+ <li>2013-07-15 - Inserted ldp:insertedContentRelation into examples (SS)</li>
<li>2013-07-15 - ISSUE-79 ldp:contains => ldp:created (JA)</li>
<li>2013-07-11 - Improving working in <a href="#ldpr-Paging" class="sectionRef"></a> to remove container references (SS)</li>
<li>2013-07-11 - Removed 4.1.5, section number fixup:4.1.8-13->6-11, 4.9.2.* fixup, 5.3.7-10->\2-5 (SS)</li>
@@ -2252,7 +2210,7 @@
<li>2013-07-10 - Removed closed issues that required no new spec changes: 18, 35, 20 (SS)</li>
<li>2013-07-10 - ISSUE-44 move section 4.1.7 (relationships are simple RDF links) to guidance (SS)</li>
<li>2013-07-10 - ISSUE-72 take 2 - added ldp:MemberSubject to handle default case (SS)</li>
- <li>2013-07-10 - ISSUE-72 adding 5.2.10 for ldp:membershipObject (SS)</li>
+ <li>2013-07-10 - ISSUE-72 adding 5.2.10 for ldp:insertedContentRelation (SS)</li>
<li>2013-07-09 - ISSUE-58 inlining - actions 87-89 inclusive (JA)</li>
<li>2013-07-08 - Moved 5.7.* sections out of HEAD and into OPTIONS as 5.9.*, added 4.6.2 (SS)</li>
<li>2013-07-08 - ISSUE-15 Inserted 5.4.12, 5.6.4, 5.7.2 to describe link-relation meta usage (SS)</li>
@@ -2279,7 +2237,7 @@
<li>2013-05-13 - ISSUE-49 Moved section 4.1.4 out of spec to the <a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Predicate_URIs_SHOULD_be_HTTP_URLs">deployment guide</a>. (SS)</li>
<li>2013-05-08 - Removed closed issues 5, 7, 55 and 38 as the don't require edits. Added 64 and 65. (SS)</li>
<li>2013-05-08 - ISSUE-59 5.3.2 limited rdf:type of ldp:Container, removed 5.6.3, reworded 5.6.2, updated 1. (SS)</li>
- <li>2013-04-15 - ISSUE-21 Added ldp:membershipPredicateInverse to 5.2.5 & 5.5.2, created 5.2.5.1 & 5.3.5.2 to indicate difference. (SS)</li>
+ <li>2013-04-15 - ISSUE-21 Added ldp:containedByRelation to 5.2.5 & 5.5.2, created 5.2.5.1 & 5.3.5.2 to indicate difference. (SS)</li>
<li>2013-04-15 - ISSUE-39 Moved informative text from 5.4.5 into 5.4.1, shifted subsections .6-.10 (SS)</li>
<li>2013-04-15 - Expanded on wording for 4.3 to be more consistent (SS)</li>
<li>2013-04-08 - Fixed two old references to BPR (SS)</li>