--- a/ldp.html Mon Feb 17 13:23:43 2014 -0500
+++ b/ldp.html Mon Feb 17 13:38:32 2014 -0500
@@ -299,12 +299,13 @@
<dd>A HTTP resource whose state is represented in any way that conforms to the simple lifecycle
patterns and conventions in <a href="#ldpr" class="sectionRef"></a>.<p></p></dd>
- <dt><dfn>Linked Data Platform RDF Resource</dfn> (<abbr title="Linked Data Platform RDF Resource">LDP-RR</abbr>)</dt>
+ <dt><dfn>Linked Data Platform RDF Source</dfn> (<abbr title="Linked Data Platform RDF Source">LDP-RS</abbr>)</dt>
<dd>An <a title="Linked Data Platform Resource">LDPR</a> whose state is represented in RDF, corresponding to
- an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
+ an RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a>. See also the term
+ <dfn>RDF Source</dfn> from [[rdf11-concepts]].
<p></p></dd>
- <dt><dfn>Linked Data Platform Binary Resource</dfn> (<abbr title="Linked Data Platform Binary Resource">LDP-BR</abbr>)</dt>
+ <dt><dfn>Linked Data Platform Non-RDF Source</dfn> (<abbr title="Linked Data Platform Non-RDF Source">LDP-NR</abbr>)</dt>
<dd>A <a title="Linked Data Platform Resource">LDPR</a> whose state is <em>not</em> represented in RDF.
These are binary or text documents that do not have useful RDF representations.
<p></p></dd>
@@ -335,7 +336,7 @@
<p></p></dd>
<dt><dfn>Membership</dfn></dt>
- <dd>The relationship linking an LDP-RR (LDPCs are also LDP-RRs) and its member LDPRs.
+ <dd>The relationship linking an LDP-RS (LDPCs are also LDP-RSs) and its member LDPRs.
There often is a linked LDPC that assists with managing the member LDPRs.<p></p></dd>
<dt><dfn>Membership triples</dfn></dt>
@@ -391,15 +392,15 @@
<p></p></dd>
<dt><dfn>Paged resource</dfn></dt>
- <dd>A LDP-RR whose representation may be too large to fit in a single HTTP response, for which an
- LDP server offers a sequence of single-page <a title="Linked Data Platform RDF Resource">LDP-RRs</a>.
+ <dd>A LDP-RS whose representation may be too large to fit in a single HTTP response, for which an
+ LDP server offers a sequence of single-page <a title="Linked Data Platform RDF Source">LDP-RSs</a>.
When the representations of the sequence's resources
are combined by a client, the client has a (potentially incomplete or incoherent) copy of the paged resource's
- state. If a paged resource <var>P</var> is a LDP-RR and is broken into a sequence of pages
+ state. If a paged resource <var>P</var> is a LDP-RS and is broken into a sequence of pages
(single-page resources) <var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
the representation of each <var>P<sub>i</sub></var> contains
a subset of the triples in <var>P</var>.
- LDP allows paging of resources other than <a title="Linked Data Platform RDF Resource">LDP-RRs</a>,
+ LDP allows paging of resources other than <a title="Linked Data Platform RDF Source">LDP-RSs</a>,
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.
@@ -408,7 +409,7 @@
<p></p></dd>
<dt><dfn>Single-page resource</dfn></dt>
- <dd>One of a sequence of related <a title="Linked Data Platform RDF Resource">LDP-RRs</a>
+ <dd>One of a sequence of related <a title="Linked Data Platform RDF Source">LDP-RSs</a>
<var>P<sub>1</sub>, P<sub>2</sub>, ...,P<sub>n</sub></var>,
each of which contains a subset of the state
of another resource <var>P</var>. <var>P</var> is called the paged resource.
@@ -501,24 +502,24 @@
<section><h2>General</h2>
<section id="ldp-cli-multitype"><h2 class="normal">In the absence of special knowledge of the application or domain,
- <a title="LDP client">LDP clients</a> MUST assume that any LDP-RR can have multiple values for <code>rdf:type</code>.
+ <a title="LDP client">LDP clients</a> MUST assume that any LDP-RS can have multiple values for <code>rdf:type</code>.
</h2></section> <!-- Was 4.3.5 / #ldpr-4_3_5 -->
<section id="ldpr-cli-typeschange"><h2 class="normal">In the absence of special knowledge of the application or domain,
<a title="LDP client">LDP clients</a> MUST assume that the <code>rdf:type</code> values
- of a given LDP-RR can change over time.
+ of a given LDP-RS can change over time.
</h2></section> <!-- Was 4.3.6 / #ldpr-4_3_6 -->
<section id="ldpr-cli-openpreds"><h2 class="normal"><a title="LDP client">LDP clients</a> SHOULD always assume that the set of predicates for a
- LDP-RR of a particular type at an arbitrary server is open, in the
+ LDP-RS of a particular type at an arbitrary server is open, in the
sense that different resources of the same type may not all have the
same set of predicates in their triples, and the set of predicates that
- are used in the state of any one LDP-RR is not limited to any pre-defined
+ are used in the state of any one LDP-RS is not limited to any pre-defined
set.
</h2></section> <!-- Was 4.5.3 / #ldpr-ldpr-4_5_3 -->
<section id="ldpr-cli-preservetriples"><h2 class="normal">
- A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved from an LDP-RR using HTTP <code>GET</code> that
+ A <a title="LDP client">LDP client</a> MUST preserve all triples retrieved from an LDP-RS using HTTP <code>GET</code> that
it doesn’t change whether it understands the predicates or not, when
its intent is to perform an update using HTTP <code>PUT</code>. The use of HTTP
<code>PATCH</code> instead of HTTP <code>PUT</code> for update avoids this burden for clients
@@ -529,7 +530,7 @@
<a title="LDP client">LDP clients</a> MAY
provide LDP-defined hints that allow servers to optimize the content of responses.
<a href="#prefer-parameters" class="sectionRef"></a> defines hints that apply to
- <a title="Linked Data Platform RDF Resource">LDP-RRs</a>.
+ <a title="Linked Data Platform RDF Source">LDP-RSs</a>.
</h2></section>
<section id="ldpr-cli-hints-ignorable"><h2 class="normal">
@@ -577,21 +578,21 @@
<li>Are there some typical vocabularies that should be reused?</li>
</ul>
<p>The following sections define the conformance rules for LDP servers when serving LDPRs.
- This document also explains <a href="#ldpr-Paging">how a server paginates an LDP-RR's representation</a> if it gets too big.
+ This document also explains <a href="#ldpr-Paging">how a server paginates an LDP-RS's representation</a> if it gets too big.
Companion non-normative documents describe additional guidelines for use when interacting with LDPRs.
</p>
<p>An LDP server manages two kinds of <a title="Linked Data Platform Resources">LDPRs</a>, those resources who whose state
- is represented using RDF (LDP-RR) and those using other formats (LDP-BR). LDP-RRs have the unique
+ is represented using RDF (LDP-RS) and those using other formats (LDP-NR). LDP-RSs have the unique
quality that their representation is based on RDF, which addresses a number of use cases from web metadata, open data
- models, machine processable information, and automated processing by software agents [[!RDF-CONCEPTS]]. LDP-BRs are almost anything
- on the Web today: images, HTML pages, word processing documents, spreadsheets, etc. and LDP-RRs hold
- metadata associated with LDP-BRs in some cases.
+ models, machine processable information, and automated processing by software agents [[!RDF-CONCEPTS]]. LDP-NRs are almost anything
+ on the Web today: images, HTML pages, word processing documents, spreadsheets, etc. and LDP-RSs hold
+ metadata associated with LDP-NRs in some cases.
</p>
<figure id="fig-ldpr-types">
<img src="images/ldpr1.png" alt="Sample separation of Linked Data Platform Resource" />
<figcaption>Samples of different types of LDPRs</figcaption>
</figure>
- <p>The LDP-BRs and LDP-RRs are simply sub-types of LDPRs, as illustrated in <a href="#fig-ldpr-class"></a>.</p>
+ <p>The LDP-NRs and LDP-RSs are simply sub-types of LDPRs, as illustrated in <a href="#fig-ldpr-class"></a>.</p>
<figure id="fig-ldpr-class">
<img src="images/ldpr2.png" alt="Class Diagram of Linked Data Platform Resource" />
<figcaption>Class relationship of types of LDPRs</figcaption>
@@ -605,26 +606,26 @@
<section id="ldpr-gen-http"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST at least be HTTP/1.1 conformant servers [[!HTTP11]].
</h2></section><!-- Was 4.2.1 / #ldpr-4_2_1 -->
- <section id="ldpr-gen-rdf"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide an RDF representation for <a title="Linked Data Platform RDF Resource">LDP-RRs</a>.
- The HTTP <code>Request-URI</code> of the LDP-RR is typically the subject of most triples in the response.
+ <section id="ldpr-gen-rdf"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide an RDF representation for <a title="Linked Data Platform RDF Source">LDP-RSs</a>.
+ The HTTP <code>Request-URI</code> of the LDP-RS is typically the subject of most triples in the response.
</h2></section><!-- Was 4.2.2 / #ldpr-4_2_2 -->
- <section id="ldpr-gen-binary"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs, <a title="Linked Data Platform RDF Resource">LDP-RRs</a>
- and <a title="Linked Data Platform Binary Resource">LDP-BRs</a>. For example, it
+ <section id="ldpr-gen-binary"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY host a mixture of LDPRs, <a title="Linked Data Platform RDF Source">LDP-RSs</a>
+ and <a title="Linked Data Platform Non-RDF Source">LDP-NRs</a>. For example, it
is common for <a title="LDP server">LDP servers</a> to need to host binary or text resources
that do not have useful RDF representations.</h2></section><!-- Was 4.2.3 / #ldpr-4_2_3 -->
- <section id="ldpr-gen-reusevocab"><h2 class="normal"><a title="Linked Data Platform RDF Resource">LDP-RRs</a> SHOULD reuse existing vocabularies instead of creating
+ <section id="ldpr-gen-reusevocab"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> 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.
</h2></section><!-- Was 4.2.4 / #ldpr-4_2_4 -->
- <section id="ldpr-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Resource">LDP-RRs</a> predicates SHOULD use standard vocabularies such as Dublin Core
+ <section id="ldpr-gen-reusevocabsuchas"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> predicates SHOULD use standard vocabularies such as Dublin Core
[[!DC-TERMS]], RDF [[!RDF-CONCEPTS]] and RDF Schema [[!RDF-SCHEMA]], whenever
possible.
</h2></section><!-- Was 4.2.4.1 / #ldpr-4_2_4_1 -->
- <section id="ldpr-gen-atleast1rdftype"><h2 class="normal"><a title="Linked Data Platform RDF Resource">LDP-RRs</a> representations SHOULD have at least one <code>rdf:type</code>
+ <section id="ldpr-gen-atleast1rdftype"><h2 class="normal"><a title="Linked Data Platform RDF Source">LDP-RSs</a> representations SHOULD have at least one <code>rdf:type</code>
set explicitly. This makes the representations much more useful to
client applications that don’t support inferencing.
</h2></section><!-- Was 4.2.5 / #ldpr-4_2_5 -->
@@ -647,7 +648,7 @@
The HTTP <code>Link</code> header is the method by which servers assert their support for the LDP specification
on a specific resource in a way that clients can inspect dynamically at run-time.
This is <strong>not</strong> equivalent to the
- presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in an RDF resource.
+ presence of a <var>(subject-URI, <code>rdf:type</code>, <code>ldp:Resource</code>)</var> triple in an LDP-RS.
The presence of this header asserts that the server complies with the LDP specification's constraints on
HTTP interactions with LDPRs, that is
it asserts that the resource <a href="#ldpr-gen-tags">has Etags</a>, <a href="#ldpr-gen-rdf">has an RDF representation</a>, and so on,
@@ -689,13 +690,13 @@
although machine-readable ones facilitate better client interactions.
</h2></section><!-- Was 4.2.13 / #ldpr-4_2_13 -->
- <section id="ldpr-page-large"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDP-RRs in
+ <section id="ldpr-page-large"><h2 class="normal"><a title="LDP server">LDP servers</a> SHOULD allow clients to retrieve large LDP-RSs in
pages.
See <a href="#ldpr-Paging" class="sectionRef"></a> for additional requirements associated with <a title="Paged resource">paged resources</a>.
</h2></section><!-- Was 4.2.14 / #ldpr-4_2_14 -->
<section id="ldpr-split-any"><h2 class="normal"><a title="LDP server">LDP servers</a> MAY
- treat any resource (LDP-RR or not) as a <a title="Paged resource">paged resource</a>.
+ treat any resource (LDP-RS or not) as a <a title="Paged resource">paged resource</a>.
See <a href="#ldpr-Paging" class="sectionRef"></a> for additional details.
</h2></section><!-- Was 4.2.15 / #ldpr-4_2_15 -->
@@ -711,7 +712,7 @@
</h2></section><!-- Was 4.3.2 / #ldpr-4_3_2 -->
<section id="ldpr-get-turtle"><h2 class="normal"><a title="LDP server">LDP servers</a> MUST provide a <code>text/turtle</code>
- representation of the requested <a title="Linked Data Platform RDF Resource">LDP-RR</a> [[!TURTLE]].
+ representation of the requested <a title="Linked Data Platform RDF Source">LDP-RS</a> [[!TURTLE]].
</h2></section><!-- Was 4.3.3 / #ldpr-4_3_3 -->
</section>
@@ -1295,7 +1296,7 @@
named graph for the net worth resource and then two others for asset and liability containers. This allows for
the membership triples to be represented with the named graph for the net worth resource, while the containment triples
would be represented within the liability and asset containers [[rdf11-concepts]]. Generally, the membership triples belong
- to the representation of a LDP-RR and the containment triples belong to the representation of the LDPC.
+ to the representation of a LDP-RS and the containment triples belong to the representation of the LDPC.
</p>
<p>Additionally, we could extend our net worth example to include a container for
@@ -1363,9 +1364,9 @@
<tr><td>LDPR created in LDPC (any subtype)</td><td>New triple based on type of container (see following rows)</td><td>New triple:
(LDPC, ldp:contains, LDPR)</td></tr>
<tr><td>LDPR created in LDP-BC</td><td>New triple: (LDPC, ldp:contains, LDPR)</td><td>Same</td></tr>
- <tr><td>LDPR created in LDP-DC</td><td>New triple links LDP-RR to created LDPR. LDP-RR URI may be same as LDP-DC</td>
+ <tr><td>LDPR created in LDP-DC</td><td>New triple links LDP-RS to created LDPR. LDP-RS URI may be same as LDP-DC</td>
<td>New triple: (LDPC, ldp:contains, LDPR)</td></tr>
- <tr><td>LDPR created in LDP-IC</td><td>New triple links LDP-RR to content indicated URI</td>
+ <tr><td>LDPR created in LDP-IC</td><td>New triple links LDP-RS to content indicated URI</td>
<td>New triple: (LDPC, ldp:contains, LDPR)</td></tr>
<tr><td>LDPR is deleted</td><td>Triples may be removed</td><td>Triples are removed
</td></tr>
@@ -1530,7 +1531,7 @@
discover <dfn><abbr title="Linked Data Platform Containers">LDPCs</abbr></dfn>.</p>
<section id="ldpc-isldpr"><h2 class="normal">Each Linked Data Platform Container MUST also be
- a conforming <a title="">Linked Data Platform RDF Resource</a>.
+ a conforming <a title="">Linked Data Platform RDF Source</a>.
</h2></section><!-- Was 5.2.1 / #ldpc-5_2_1 -->
<section id="ldpc-typecontainer"><h2 class="normal">The representation of a LDPC MUST have an <code>rdf:type</code>
@@ -1541,7 +1542,7 @@
<li><code>ldp:IndirectContainer</code> for <a title="">Linked Data Platform Indirect Container</a></li>
</ul>
Non-normative note: <a href="#ldp-rdfconcepts-extra-triples-types">LDPCs
- might have additional types</a>, like any RDF resource.
+ might have additional types</a>, like any <a title="Linked Data Platform RDF Source">LDP-RS</a>.
</h2></section><!-- Was 5.2.7 / #ldpc-5_2_7 -->
@@ -1809,7 +1810,7 @@
</h2></section><!-- Was 5.4.2 / #ldpc-5_4_2 -->
<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
+ <a title="Linked Data Platform Non-RDF Source">(LDP-NRs)</a> for
creation of any kind of resource, for example binary resources. See <a href="#ldpc-post-acceptposthdr">the Accept-Post section</a> for
details on how clients can discover whether a LDPC supports this behavior.
</h2></section><!-- Was 5.4.3 / #ldpc-5_4_3 -->
@@ -1867,10 +1868,10 @@
</h2></section><!-- Was 5.4.11 / #ldpc-5_4_11 -->
<section id="ldpc-post-createbinlinkmetahdr"><h2 class="normal">Upon successful creation of a
- <a title="Linked Data Platform Binary Resource">LDP-BR</a> (HTTP status code of
+ <a title="Linked Data Platform Non-RDF Source">LDP-NR</a> (HTTP status code of
201-Created and URI indicated by <code>Location</code> response header), <a title="LDP server">LDP servers</a> MAY create an associated
- <a title="Linked Data Platform RDF Resource">LDP-RR</a>
- to contain data about the newly created LDP-BR. If an LDPC server creates this associated <a title="Linked Data Platform RDF Resource">LDP-RR</a> it MUST indicate
+ <a title="Linked Data Platform RDF Source">LDP-RS</a>
+ to contain data about the newly created LDP-NR. If an LDPC server creates this associated <a title="Linked Data Platform RDF Source">LDP-RS</a> it MUST indicate
its location on the HTTP response using the HTTP <code>Link</code> response header with link relation <code>meta</code>
and <code>href</code> to be the URI of the meta-resource [[!RFC5988]].
</h2></section><!-- Was 5.4.12 / #ldpc-5_4_12 -->
@@ -1934,7 +1935,7 @@
</h2></section><!-- Was 5.5.1 / #ldpc-5_5_1 -->
<section id="ldpc-put-create"><h2 class="normal"><a title="LDP server">LDP servers</a> that allow member creation via <code>PUT</code>
- SHOULD NOT re-use URIs. For RDF representations (LDP-RRs),the created resource
+ SHOULD NOT re-use URIs. For RDF representations (LDP-RSs),the created resource
can be thought of as a RDF <a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph">named graph</a> [[rdf11-concepts]].
</h2></section><!-- Was 5.5.4 / #ldpc-5_5_4 -->
@@ -1963,7 +1964,7 @@
<section id="ldpc-del-contremovesmbrres"><h2 class="normal">
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.
+ created an associated LDP-RS (see the <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>), the LDPC server MUST also remove the associated LDP-RS it created.
</h2></section><!-- Was 5.6.4 / #ldpc-5_6_4 -->
</section>
@@ -2004,10 +2005,10 @@
<p>This specification imposes the following new requirements on HTTP <code>OPTIONS</code> for LDPCs.
</p>
- <section id="ldpc-options-linkmetahdr"><h2 class="normal">When a LDPC creates a <a title="Linked Data Platform Binary Resource">LDP-BR</a> member (for example, one whose
- representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) it might create an associated <a title="Linked Data Platform RDF Resource">LDP-RR</a> to contain data about the
- non-LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>). For LDP-BRs that have this associated LDP-RR, an LDPC server MUST provide an HTTP <code>Link</code>
- header whose target URI is the associated LDP-RR, and whose link relation type is
+ <section id="ldpc-options-linkmetahdr"><h2 class="normal">When a LDPC creates a <a title="Linked Data Platform Non-RDF Source">LDP-NR</a> member (for example, one whose
+ representation was HTTP <code>POST</code>ed to the LDPC and then referenced by a membership triple) it might create an associated <a title="Linked Data Platform RDF Source">LDP-RS</a> to contain data about the
+ non-LDPR (see <a href="#ldpc-post-createbinlinkmetahdr">LDPC POST section</a>). For LDP-NRs that have this associated LDP-RS, an LDPC server MUST provide an HTTP <code>Link</code>
+ header whose target URI is the associated LDP-RS, and whose link relation type is
<code>meta</code> [[!RFC5988]].
<!-- TODO: Consider some improvement to #ldpc-options-linkmetahdr
@@ -2313,7 +2314,7 @@
</table>
<blockquote>
<p>
- Non-normative note: all currently defined URIs are only coherent for LDP-RRs,
+ Non-normative note: all currently defined URIs are only coherent for LDP-RSs,
and in fact only for LDPCs, however in
the future it is possible that additional URIs with other scopes of applicability
could be defined.
@@ -2575,6 +2576,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-17 - Adopted new resource types: LDP RDF Source (LDP-RS) (was LDP RDF Resource) and LDP Non-RDF Source (LDP-NR) (was LDP Binary Resource) (SS)</li>
<li>2014-02-17 - Adopted new predicate names: ldp:membershipResource, ldp:hasMemberRelation and ldp:isMemberOfRelation (SS) </li>
<li>2014-02-12 - Updated LDPR Post reference to Put, which had implied that clients could PUT (to an LDPC) to create an LDPR (JA)</li>
<li>2014-02-12 - Updated containerResource on examples 6 and 7, section 6.1, in resp to public-ldp email (JA)</li>