--- a/ldp.html Wed Jul 24 09:34:52 2013 -0400
+++ b/ldp.html Wed Jul 24 10:30:22 2013 -0400
@@ -20,9 +20,6 @@
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.
- - John A's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0054.html
- http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0056.html
- - P-A's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0071.html
- Sergio's comments http://lists.w3.org/Archives/Public/public-ldp-wg/2013Jul/0072.html
-->
<html>
@@ -199,7 +196,7 @@
read and write Linked Data resources.</p>
<p>A special type of <a title="Linked Data Platform Resource">Linked Data Platform Resource</a> is a
<a title="Linked Data Platform Container">Container</a>. Containers are very useful
- in building application models. For example, universities offer a collection of classes
+ in building application models involving collections of homogeneous resources. For example, universities offer a collection of classes
and have a collection of faculty members, each faculty member teaches a collection of courses, etc.
This specification discusses how to work with containers. Resources can be added to containers in
several ways. As a special case, members can both be created and added to a container by overloading
@@ -254,7 +251,7 @@
<dt><dfn>Membership triples</dfn></dt>
<dd>A set of triples in an LDPC's state that lists its members.
The membership triples of a container all have the same
- subject and predicate, and the objects of the membership triples define
+ subject and predicate, and the objects of the membership triples identify
the container's members.
<p></p></dd>
@@ -355,7 +352,7 @@
<p>The rules for Linked Data Platform Resources address basic
questions such as:</p>
<ul>
- <li>What resource formats should be used?</li>
+ <li>What resource representations should be used?</li>
<li>How is optimistic collision detection handled for updates?</li>
<li>What should client expectations be for changes to linked-to resources,
such as type changes?</li>
@@ -623,7 +620,7 @@
resource is too large to reasonably transmit its representation in a
single HTTP response. This will be especially true if the resource
representation includes many triples both from its own representation and
- from the representations of any of its members. A client could anticipate that a resource will be too large -
+ from the representations of any <a title="Resource inlining">inlined resources</a>. A client could anticipate that a resource will be too large -
for example, a client tool that accesses defects may assume that an
individual defect will usually be of sufficiently constrained size
that it makes sense to request all of it at once, but that the
@@ -938,7 +935,7 @@
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 resoruces.</p>
+ possibly perform 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
@@ -993,8 +990,9 @@
</p>
<pre class="example" id="ldpc-ex-membership-full"># The following is an elaborated representation of
-# http://example.org/netWorth/nw1
+# http://example.org/netWorth/nw1/
@prefix ldp: <http://www.w3.org/ns/ldp#>.
+@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix o: <http://example.org/ontology/>.
<>
a o:NetWorth;
@@ -1010,14 +1008,14 @@
<assetContainer/>
a ldp:Container;
dcterms:title "The assets of JohnZSmith";
- ldp:membershipSubject <.>;
+ ldp:membershipSubject <>;
ldp:membershipPredicate o:asset;
ldp:membershipObject ldp:MemberSubject.
<liabilityContainer/>
a ldp:Container;
dcterms:title "The liabilities of JohnZSmith";
- ldp:membershipSubject <.>;
+ ldp:membershipSubject <>;
ldp:membershipPredicate o:liability;
ldp:membershipObject ldp:MemberSubject.
</pre>
@@ -1038,8 +1036,7 @@
resources allows both assets and liabilities to be created.
</p>
-<pre class="example" id="ldpc-ex-membership-subj">
-# The following is the representation of
+<pre class="example" id="ldpc-ex-membership-subj"># The following is the representation of
# http://example.org/netWorth/nw1/assetContainer/
@prefix ldp: <http://www.w3.org/ns/ldp#>.
@prefix o: <http://example.org/ontology/>.
@@ -1103,7 +1100,7 @@
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>(.../assetContainer/, o:asset, .../a1).</var></p>
+ 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>
@@ -1243,8 +1240,8 @@
<div id="ldpc-5_2_1" class="rule">5.2.1 LDPC servers MUST also be conformant LDPR servers. A Linked Data Platform
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 (LDPR or not) which is identified by its canonical URI, MAY be a member of
+ <div id="ldpc-5_2_2" class="rule">5.2.2 LDPC membership is not exclusive; this means that 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
@@ -1256,12 +1253,12 @@
SHOULD use the <code>rdfs:member</code> predicate. Member resources can be
any kind of resource identified by its URI, LDPR or otherwise.
</div>
- <div id="ldpc-5_2_4" class="rule">5.2.4 An LDPC representation MUST contain one triple
+ <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.
</div>
- <div id="ldpc-5_2_5" class="rule">5.2.5 An LDPC representation MUST contain one triple
+ <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>.
The object of the triple is constrained by other sections, such as
@@ -1502,7 +1499,7 @@
While "POST to create" is a common interaction pattern, LDP clients are not guaranteed, even when
making requests to an LDP server, that every successful <code>POST</code> request will result in the
creation of a new resource; they must rely on out of band information for knowledge of which <code>POST</code> requests,
- if any, will have the "create new resource" semantic.
+ if any, will have the "create new resource" semantics.
This requirement on LDP servers is intentionally stronger than the one levied in the
<a href="#header-accept-post">header registration</a>; it is unrealistic to expect all existing resources
that support <code>POST</code> to suddenly return a new header or for all new specifications constraining