ldp-diff-20130715.html
author Andrei Sambra <andrei@w3.org>
Wed, 19 Nov 2014 20:08:44 -0500
branchldpatch
changeset 887 998408515484
parent 203 79f433ad777f
permissions -rw-r--r--
Added Media Type (mostly from Turtle) section and acknowledgements.
<!-- 
 Editor TODO:
   - Incorporate ISSUE-37 text from Ashok
   - Fix up LDPR paging sample to remove container
   - Should we remove / hide "Change History" section?
   - Generate HTML DIFF version
 -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Linked Data Platform 1.0</title>
<meta http-equiv='Content-Type' content='text/html; charset=utf-8' /><!-- 
      === NOTA BENE ===
      For the three scripts below, if your spec resides on dev.w3 you can check them
      out in the same tree and use relative links so that they'll work offline,
     -->

<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async="" type="text/javascript">
</script>
<script class='remove' type="text/javascript">
//<![CDATA[
      var respecConfig = {
          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
          specStatus:           "ED",
          
          // the specification's short name, as in http://www.w3.org/TR/short-name/
          shortName:            "ldp",

          // if your specification has a subtitle that goes below the main
          // formal title, define it here
          // subtitle   :  "an excellent document",

          // if you wish the publication date to be other than today, set this
          // publishDate:  "2009-08-06",

          // if the specification's copyright date is a range of years, specify
          // the start date here:
          // copyrightStart: "2005"

          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
          // and its maturity status
          previousPublishDate:  "2013-03-07",
          previousMaturity:     "FPWD",
          previousURI:                  "http://www.w3.org/TR/2013/WD-ldp-20130307/",

          // if there a publicly available Editor's Draft, this is the link
          edDraftURI:           "http://www.w3.org/2012/ldp/hg/ldp.html",

          // if this is a LCWD, uncomment and set the end of its review period
          // lcEnd: "2009-08-05",

          // if you want to have extra CSS, append them to this list
          // it is recommended that the respec.css stylesheet be kept
          //extraCSS:             ["https://dvcs.w3.org/hg/ldpwg/css/respec.css"],

          // editors, add as many as you like
          // only "name" is required
          editors:  [
              { name: "Steve Speicher", url: "http://stevespeicher.blogspot.com",
                company: "IBM Corporation", companyURL: "http://ibm.com/" },
              { name: "John Arwe", url: "https://www.ibm.com/developerworks/mydeveloperworks/groups/service/html/allcommunities?userid=120000CAW7",
                company: "IBM Corporation", companyURL: "http://ibm.com/" },
                          {name: "Ashok Malhotra", url: "ashok.malhotra@oracle.com",
                            company: "Oracle Corporation", companyURL: "http://www.oracle.com" },
          ],

          // authors, add as many as you like. 
          // This is optional, uncomment if you have authors as well as editors.
          // only "name" is required. Same format as editors.

          //authors:  [
          //    { name: "Your Name", url: "http://example.org/",
          //      company: "Your Company", companyURL: "http://example.com/" },
          //],
          
          // name of the WG
          wg:           "Linked Data Platform Working Group",
          
          // URI of the public WG page
          wgURI:        "http://www.w3.org/2012/ldp",
          
          // name (without the @w3c.org) of the public mailing to which comments are due
          wgPublicList: "public-ldp-wg",
          
          // URI of the patent status for this WG, for Rec-track documents
          // !!!! IMPORTANT !!!!
          // This is important for Rec-track documents, do not copy a patent URI from a random
          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
          // Team Contact.
          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/55082/status",
          doRDFa: "1.1",
      };
//]]>
</script>
<style type="text/css">
/*<![CDATA[*/
        div.rule {padding-top: 1em;}
        div.ldp-issue-open {
                border-color: #E05252;
                        background: #FBE9E9;
                        padding: 0.5em;
                        margin: 1em 0;
                        position: relative;
                        clear: both;
                        border-left-width: .5em;
                        border-left-style: solid;
        }
        div.ldp-issue-pending {
                border-color: #FAF602;
                        background: #F7F6BC;
                        padding: 0.5em;
                        margin: 1em 0;
                        position: relative;
                        clear: both;
                        border-left-width: .5em;
                        border-left-style: solid;
        }
        div.ldp-issue-closed {
                border-color: #009900;
                        background: #BCF7CF;
                        padding: 0.5em;
                        margin: 1em 0;
                        position: relative;
                        clear: both;
                        border-left-width: .5em;
                        border-left-style: solid;
        }
        div.ldp-issue-title {
            color: #E05252;
            padding-right: 1em;
            min-width: 7.5em;
        }
                .atrisk {
                        padding:    1em;
                        margin: 1em 0em 0em;
                        border: 1px solid #f00;
                        background: #ffc;
                }
                .atrisktext {
                        /* content:    "Feature At Risk"; */
                        display:    block;
                        width:  150px;
                        margin: -1.5em 0 0.5em 0;
                        font-weight:    bold;
                        border: 1px solid #f00;
                        background: #fff;
                        padding:    3px 1em;
                }

/*]]>*/
</style>

<style type="text/css" media="all">
/*<![CDATA[*/
        code {
            font-weight:bold;
                        font-size:larger;
        }
                 /* ReSpec uses color ff4500 for code elements, which does not print well on some black & white printers
                    and is a little hard to read for some folks even on-line. 
                        The default code font size was also somewhat too small/hard to read.
                */
/*]]>*/
</style>
<style type='text/css'>
.diff-old-a {
  font-size: smaller;
  color: red;
}

.diff-new { background-color: yellow; }
.diff-chg { background-color: lime; }
.diff-new:before,
.diff-new:after
    { content: "\2191" }
.diff-chg:before, .diff-chg:after
    { content: "\2195" }
.diff-old { text-decoration: line-through; background-color: #FBB; }
.diff-old:before,
.diff-old:after
    { content: "\2193" }
:focus { border: thin red solid}
</style>
</head>
<body>
<del class="diff-old">Linked
Data
Platform
1.0
W3C
Working
Draft
7
March
2013
This
version:
http://www.w3.org/TR/2013/WD-ldp-20130307/
Latest
version:
http://www.w3.org/TR/ldp/
Previous
version:
http://www.w3.org/TR/2012/WD-ldp-20121025/
Editors:
Steve
Speicher
,
IBM
Corporation
John
Arwe
,
IBM
Corporation
Copyright
©
2013
W3C
®
(
MIT
,
ERCIM
,
Keio
,
Beihang
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
Abstract
</del>
<section id='abstract'>
A
set
of
best
practices
and
simple
approach
for
a
read-write
Linked
Data
architecture,
based
on
HTTP
access
to
web
resources
that
describe
their
state
using
the
<abbr title="Resource Description Framework">
RDF
</abbr>
data
model.
<del class="diff-old">Status
of
This
Document
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
and
the
latest
revision
of
this
technical
report
can
be
found
in
the
W3C
technical
reports
index
at
http://www.w3.org/TR/.
This
Public
Working
Draft
was
published
by
the
Linked
Data
Platform
Working
Group
.
All
known
issues
are
documented
inline
as
well
as
in
the
LDP
WG
Issue
Tracker
.
If
you
wish
to
make
comments
regarding
this
document,
please
send
them
to
public-ldp@w3.org
(
subscribe
,
archives
).
All
comments
are
welcome.
Publication
as
a
Working
Draft
does
not
imply
endorsement
by
the
W3C
Membership.
This
is
a
draft
document
and
may
be
updated,
replaced
or
obsoleted
by
other
documents
at
any
time.
It
is
inappropriate
to
cite
this
document
as
other
than
work
in
progress.
This
document
was
produced
by
a
group
operating
under
the
5
February
2004
W3C
Patent
Policy
.
W3C
maintains
a
public
list
of
any
patent
disclosures
made
in
connection
with
the
deliverables
of
the
group;
that
page
also
includes
instructions
for
disclosing
a
patent.
An
individual
who
has
actual
knowledge
of
a
patent
which
the
individual
believes
contains
Essential
Claim(s)
must
disclose
the
information
in
accordance
with
section
6
of
the
W3C
Patent
Policy
.
Table
of
Contents
1.
Introduction
2.
Terminology
2.1
Conventions
Used
in
This
Document
3.
Conformance
4.
Linked
Data
Platform
Resources
4.1
General
4.2
HTTP
GET
4.3
HTTP
POST
4.4
HTTP
PUT
4.5
HTTP
DELETE
4.6
HTTP
HEAD
4.7
HTTP
PATCH
5.
Linked
Data
Platform
Containers
5.1
Informative
5.2
General
5.3
HTTP
GET
5.4
HTTP
POST
5.5
HTTP
PUT
5.6
HTTP
DELETE
5.7
HTTP
HEAD
5.8
HTTP
PATCH
A.
Acknowledgements
B.
Change
History
C.
Editor
Todos
and
Notes
D.
References
D.1
Normative
references
D.2
Informative
references
1.
</del>
</section>
<section>
<h1 id="intro">
Introduction
</h1>
<p>
This
document
describes
the
use
of
HTTP
for
accessing,
updating,
creating
and
deleting
resources
from
servers
that
expose
their
resources
as
Linked
Data.
<del class="diff-old">It
</del>
<ins class="diff-chg">&#160;It
</ins>
provides
some
new
rules
as
well
as
clarifications
and
extensions
of
the
four
rules
of
Linked
Data
<del class="diff-old">[
LINKED-DATA
]:
</del>
<ins class="diff-chg">[[LINKED-DATA]]:
</ins>
</p>
<p>
1.
Use
URIs
as
names
for
things
</p>
<p>
2.
Use
HTTP
URIs
so
that
people
can
look
up
those
names
</p>
<p>
3.
When
someone
looks
up
a
URI,
provide
useful
information,
using
the
standards
<del class="diff-old">(
RDF
*,
</del>
<ins class="diff-chg">(RDF*,
</ins>
<abbr title="SPARQL Protocol and RDF Query Language">
SPARQL
</abbr>
)
</p>
<p>
4.
Include
links
to
other
URIs.
so
that
they
can
discover
more
things
</p>
<p>
The
best
practices
and
anti-patterns
covered
in
this
document
are:
</p>
<ul>
<li>
<p>
<em>
Resources
</em>
-
a
summary
of
the
HTTP
and
RDF
standard
techniques
and
best
practices
that
you
should
use,
and
anti-patterns
you
should
avoid,
when
constructing
clients
and
servers
that
read
and
write
Linked
Data.
</p>
</li>
<li>
<p>
<em>
Containers
</em>
-
defines
resources
that
allow
new
resources
to
be
created
using
HTTP
POST
and
existing
resources
to
be
found
using
HTTP
<del class="diff-old">GET.
</del>
<ins class="diff-chg">GET.&#160;
</ins>
</p>
</li>
</ul>
<p>
Additionally,
it
is
the
intention
of
this
document
to
enable
additional
rules
and
layered
groupings
of
rules,
such
as
additional
specifications.
<del class="diff-old">The
</del>
<ins class="diff-chg">&#160;The
</ins>
scope
is
intentionally
narrow
to
provide
a
set
of
key
rules
for
reading
and
writing
Linked
Data
that
most,
if
not
all,
other
specifications
will
depend
upon
and
implementations
will
support.
</p>
<div class="ldp-issue-open">
<div class="ldp-issue-title">
<a href="http://www.w3.org/2012/ldp/track/issues/37">
<ins class="diff-new">ISSUE-37
</ins></a>
</div>
<ins class="diff-chg">Additional
introductory
text
on
the
LDP
data
and
interaction
model
</ins><em><ins class="diff-chg">
--
awaiting
contribution
</ins></em>
<del class="diff-old">2.
</del>
</div>
</section>
<section>
<h1 id="terms">
Terminology
</h1>
<p>
Terminology
is
based
on
<del class="diff-old">W3C
's
</del>
<ins class="diff-chg">W3C's
</ins>
Architecture
of
the
World
Wide
Web
<del class="diff-old">[
WEBARCH
]
</del>
<ins class="diff-chg">[[WEBARCH]]
</ins>
and
Hyper-text
Transfer
Protocol
<del class="diff-old">[
HTTP11
].
</del>
<ins class="diff-chg">[[HTTP11]].
</ins>
</p>
<dl class="glossary">
<dt>
Link
</dt>
<dd>
A
relationship
between
two
resources
when
one
resource
(representation)
refers
to
the
other
resource
by
means
of
a
URI
<del class="diff-old">[
WEBARCH
].
</del>
<ins class="diff-chg">[[WEBARCH]].
</ins>
<p>
</p>
</dd>
<dt>
Linked
Data
</dt>
<dd>
As
defined
by
Tim
Berners-Lee
<del class="diff-old">[
LINKED-DATA
].
</del>
<ins class="diff-chg">[[LINKED-DATA]].
</ins>
<p>
</p>
</dd>
<dt>
<dfn>
Linked
Data
Platform
Resource
</dfn>
(
<dfn>
<abbr title="Linked Data Platform Resource">
LDPR
</abbr>
</dfn>
)
</dt>
<dd>
HTTP
resource
<ins class="diff-new">whose
state
is
represented
in
RDF
</ins>
that
conforms
to
the
simple
lifecycle
patterns
and
conventions
in
the
<del class="diff-old">LDPRs
</del>
<a href="#ldpr" class="sectionRef">
<del class="diff-old">section.
</del>
</a>.
<p>
</p>
</dd>
<dt>
<dfn>
Linked
Data
Platform
Container
</dfn>
(
<dfn>
<abbr title="Linked Data Platform Container">
LDPC
</abbr>
</dfn>
)
</dt>
<dd>
<ins class="diff-chg">An
</ins>
LDPR
<ins class="diff-chg">representing
a
collection
of
same-subject,
same-predicate
triples
which
is
uniquely
identified
by
a
URI
</ins>
that
<del class="diff-old">also
conforms
</del>
<ins class="diff-chg">responds
</ins>
to
<del class="diff-old">additional
patterns
and
conventions
</del>
<ins class="diff-chg">client
requests
</ins>
for
<del class="diff-old">managing
membership.
</del>
<ins class="diff-chg">creation,
modification,
and
enumeration
of
its
members.
</ins>
<p>
</p>
</dd>
<dt>
Client
</dt>
<dd>
A
program
that
establishes
connections
for
the
purpose
of
sending
requests
<del class="diff-old">[
HTTP11
].
</del>
<ins class="diff-chg">[[HTTP11]].
</ins>
<p>
</p>
</dd>
<dt>
Server
</dt>
<dd>
An
application
program
that
accepts
connections
in
order
to
service
requests
by
sending
back
responses.
<p>
Any
given
program
may
be
capable
of
being
both
a
client
and
a
server;
our
use
of
these
terms
refers
only
to
the
role
being
performed
by
the
program
for
a
particular
connection,
rather
than
to
the
program's
capabilities
in
general.
Likewise,
any
server
may
act
as
an
origin
server,
proxy,
gateway,
or
tunnel,
switching
behavior
based
on
the
nature
of
each
request
<del class="diff-old">[
HTTP11
].
</del>
<ins class="diff-chg">[[HTTP11]].
</ins>
</p>
</dd>
<dt>
<dfn>
Membership
triples
</dfn>
</dt>
<dd>
A
set
of
triples
in
an
<del class="diff-old">LDPC
's
</del>
<ins class="diff-chg">LDPC's
</ins>
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
the
container's
members.
<p>
</p>
</dd>
<dt>
<dfn>
Membership
subject
</dfn>
</dt>
<dd>
The
subject
of
all
<del class="diff-old">an
LDPC
's
</del>
<ins class="diff-chg">a
LDPC's
</ins>
<a title="Membership triples">
membership
triples
</a>.
<p>
</p>
</dd>
<dt>
<dfn>
Membership
predicate
</dfn>
</dt>
<dd>
The
predicate
of
all
<del class="diff-old">an
LDPC
's
</del>
<ins class="diff-chg">a
LDPC's
</ins>
<a title="Membership triples">
membership
triples
</a>.
<p>
</p>
</dd>
<dt>
<dfn>
<ins class="diff-new">Non-member
resource
</ins></dfn></dt><dd><ins class="diff-new">
A
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.
</ins><p>
</p>
</dd>
<dt>
<del class="diff-old">2.1
</del>
<dfn>
<ins class="diff-chg">Resource
inlining
</ins></dfn></dt><dd><ins class="diff-chg">
The
practice
of
responding
to
a
HTTP
GET
request
made
to
a
request
URI
</ins><var><ins class="diff-chg">
R
</ins><sub><ins class="diff-chg">
0
</ins></sub></var><ins class="diff-chg">
with
a
representation
that
includes
the
state
of
</ins><var><ins class="diff-chg">
R
</ins><sub><ins class="diff-chg">
0
</ins></sub></var>,<ins class="diff-chg">
the
</ins><em><ins class="diff-chg">
entire
</ins></em><ins class="diff-chg">
state
of
resources
accessed
through
</ins><em><ins class="diff-chg">
other
</ins></em><ins class="diff-chg">
request
URI(s)
</ins><var><ins class="diff-chg">
R
</ins><sub><ins class="diff-chg">
1
</ins></sub></var>...<var><ins class="diff-chg">
R
</ins><sub><ins class="diff-chg">
n
</ins></sub></var>,<em><ins class="diff-chg">
and
assertions
</ins></em><ins class="diff-chg">
from
the
server
identifying
the
additional
resources
whose
entire
state
has
been
provided.
</ins><var><ins class="diff-chg">
R
</ins><sub><ins class="diff-chg">
1
</ins></sub></var>...<var><ins class="diff-chg">
R
</ins><sub><ins class="diff-chg">
n
</ins></sub></var><ins class="diff-chg">
identify
the
inlined
resource(s).
See
</ins><a href="#ldpr-inlining" class="sectionRef"></a><ins class="diff-chg">
for
details.
</ins><p></p></dd><dt><dfn><ins class="diff-chg">
Member
inlining
</ins></dfn></dt><dd><ins class="diff-chg">
A
special
case
of
</ins><a title="Resource inlining"><ins class="diff-chg">
resource
inlining
</ins></a>,<ins class="diff-chg">
where
all
members
of
a
container
on
a
given
page
are
inlined.
The
response
page
may
or
may
not
include
all
of
the
container's
members.
See
</ins><a href="#ldpc-inlining" class="sectionRef"></a><ins class="diff-chg">
for
details.
</ins><p></p></dd></dl><section><h2 id="conventions">
Conventions
Used
in
This
Document
</h2>
<p>
Sample
resource
representations
are
provided
in
<code>
text/turtle
</code>
format
<del class="diff-old">[
TURTLE
].
</del>
<ins class="diff-chg">[[TURTLE]].
</ins>
</p>
<p>
Commonly
used
namespace
prefixes:
</p>
<del class="diff-old">		@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
	@prefix rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
	@prefix rdfs:    &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
	@prefix ldp:     &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix
xsd:
&lt;http://www.w3.org/2001/XMLSchema#&gt;.
</del>
<pre style="word-wrap: break-word; white-space: pre-wrap;">
<ins class="diff-chg">     @prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
        @prefix rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
        @prefix rdfs:    &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
        @prefix ldp:     &lt;http://www.w3.org/ns/ldp#&gt;.
        @prefix xsd:     &lt;http://www.w3.org/2001/XMLSchema#&gt;.
</ins>
</pre>
<del class="diff-old">3.
Conformance
As
well
as
sections
marked
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
and
notes
in
this
specification
are
non-normative.
Everything
else
in
this
specification
is
normative.
The
key
words
MUST
,
MUST
NOT
,
REQUIRED
,
SHOULD
,
SHOULD
NOT
,
RECOMMENDED
,
MAY
,
and
OPTIONAL
in
this
specification
are
to
be
interpreted
as
described
in
[
</del>
<del class="diff-old">RFC2119
].
</del>
</section>
</section>
<section id='conformance'>
<p>
The
status
of
the
sections
of
Linked
Data
Platform
1.0
(this
document)
is
as
follows:
</p>
<ul>
<li>
1.
Introduction:
<b>
informative
</b>
</li>
<li>
2.
Terminology:
<b>
informative
</b>
</li>
<li>
3.
Conformance:
<b>
normative
</b>
</li>
<li>
4.
Linked
Data
Platform
Resources:
<b>
normative
</b>
</li>
<li>
5.
Linked
Data
Platform
Containers:
<b>
normative
</b>
</li>
<li>
<ins class="diff-new">6.
HTTP
Header
Definitions:
</ins><b><ins class="diff-new">
normative
</ins></b></li><li>
A.
Acknowledgements:
<b>
<del class="diff-old">normative
</del>
<ins class="diff-chg">informative
</ins>
</b>
</li>
<li>
B.
Change
History:
<b>
<del class="diff-old">normative
</del>
<ins class="diff-chg">informative
</ins>
</b>
</li>
<li>
<del class="diff-old">D.1
</del>
<ins class="diff-chg">C.1
</ins>
Normative
references:
<b>
normative
</b>
</li>
<li>
<del class="diff-old">D.2
</del>
<ins class="diff-chg">C.2
</ins>
Informative
references:
<b>
informative
</b>
</li>
</ul>
<p>
A
conforming
<b>
LDP
<del class="diff-old">Server
</del>
<ins class="diff-chg">server
</ins>
</b>
is
an
application
program
that
processes
HTTP
requests
and
generates
HTTP
responses
that
conform
to
the
rules
defined
in
<del class="diff-old">sections
on
LDPRs
</del>
<a href="#linked-data-platform-resources" class="sectionRef">
</a>
and
<del class="diff-old">LDPCs
</del>
<a href="#linked-data-platform-containers" class="sectionRef">
</a>.
</p>
<p>
A
conforming
<b>
LDP
<del class="diff-old">Client
</del>
<ins class="diff-chg">client
</ins>
</b>
is
an
application
program
that
generates
HTTP
requests
and
processes
HTTP
responses
that
conform
to
the
rules
defined
in
<del class="diff-old">sections
on
LDPRs
</del>
<a href="#linked-data-platform-resources" class="sectionRef">
</a>
and
<del class="diff-old">LDPCs
</del>
<a href="#linked-data-platform-containers" class="sectionRef">
</a>.
</p>
<del class="diff-old">4.
</del>
</section>
<section>
<h1 id="ldpr">
Linked
Data
Platform
Resources
</h1>
<p>
Linked
Data
Platform
Resources
(
<dfn>
<abbr title="Linked Data Platform Resources">
LDPRs
</abbr>
</dfn>
)
are
HTTP
resources
that
conform
to
the
simple
patterns
and
conventions
in
this
section.
HTTP
requests
to
access,
modify,
create
or
delete
LDPRs
are
accepted
and
processed
by
LDPR
servers.
Most
LDPRs
are
domain-specific
resources
that
contain
data
for
an
entity
in
some
domain,
which
could
be
commercial,
governmental,
scientific,
religious,
or
other.
</p>
<p>
Some
of
the
rules
defined
in
this
document
provide
clarification
and
refinement
of
the
base
Linked
Data
rules
<del class="diff-old">[
LINKED-DATA
];
</del>
<ins class="diff-chg">[[LINKED-DATA]];
</ins>
others
address
additional
needs.
</p>
<p>
The
rules
for
Linked
Data
Platform
Resources
address
basic
questions
such
as:
</p>
<ul>
<li>
What
resource
formats
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>
<li>
What
can
servers
do
to
ease
the
burden
of
constraints
for
resource
creation?
</li>
<li>
<ins class="diff-new">How
do
I
GET
the
entries
of
a
large
resources
broken
up
into
pages?
</ins></li>
</ul>
<p>
Additional
informative
guidance
is
available
on
the
<a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide" class="external" title="Deployment Guide" rel="nofollow">
working
group's
wiki
</a>
that
addresses
deployment
questions
such
as:
</p>
<ul>
<li>
What
literal
value
types
should
be
used?
</li>
<li>
Are
there
some
typical
vocabularies
that
should
be
reused?
</li>
</ul>
<p>
The
following
sections
define
the
rules
and
guidelines
for
use
of
<del class="diff-old">LDPRs
.
</del>
<ins class="diff-chg">LDPRs.
This
document
also
explains
how
to
include
information
about
each
member
in
the
resource’s
own
representation
and
how
to
paginate
the
resource
representation
if
it
gets
too
big.
</ins>
</p>
<del class="diff-old">4.1
</del>
<section>
<h2 id="ldpr-general">
General
</h2>
<div id="ldpr-4_1_1" class="rule">
4.1.1
LDPR
servers
MUST
at
least
be
HTTP/1.1
conformant
servers
<del class="diff-old">[
HTTP11
].
</del>
<ins class="diff-chg">[[!HTTP11]].
</ins>
</div>
<div id="ldpr-4_1_2" class="rule">
4.1.2
LDPR
servers
MUST
provide
an
RDF
representation
for
<del class="diff-old">LDPRs
.
</del>
<ins class="diff-chg">LDPRs.
</ins>
The
HTTP
<code>
Request-URI
</code>
of
the
LDPR
is
typically
the
subject
of
most
triples
in
the
response.
</div>
<div id="ldpr-4_1_3" class="rule">
4.1.3
LDPR
servers
MAY
host
a
mixture
of
LDPRs
and
<del class="diff-old">non-
LDPRs
.
</del>
<ins class="diff-chg">non-LDPRs.
</ins>
For
example,
it
is
common
for
LDPR
servers
to
need
to
host
binary
or
text
resources
that
do
not
have
useful
RDF
representations.
</div>
<div id="ldpr-4_1_4" class="rule">
4.1.4
<del class="diff-old">Clients
can
access
an
LDPR
using
multiple
URLs,
for
example
when
DNS
aliasing
is
used.
An
LDPR
server
MUST
respond
to
each
of
those
requests
using
a
single
consistent
URL,
a
canonical
URL,
for
the
LDPR
which
may
be
found
in
the
response's
Location
header
and
potentially
also
in
the
representation
of
the
LDPR
.
Clients
SHOULD
use
the
canonical
URL
as
an
LDPR
's
identity;
for
example,
when
determining
if
two
URLs
refer
to
the
same
resource
clients
need
to
compare
the
canonical
URLs
not
the
URLs
used
to
access
the
resources.
ISSUE-49
Canonical
URL
-
how
to
communicate
its
value
to
clients
4.1.5
</del>
LDPRs
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.
</div>
<del class="diff-old">4.1.5.1
</del>
<div id="ldpr-4_1_4_1" class="rule">
<ins class="diff-chg">4.1.4.1
</ins>
LDPR
predicates
SHOULD
use
standard
vocabularies
such
as
Dublin
Core
<del class="diff-old">[
DC-TERMS
],
</del>
<ins class="diff-chg">[[!DC-TERMS]],
</ins>
RDF
<del class="diff-old">[
RDF-PRIMER
]
</del>
<ins class="diff-chg">[[!RDF-CONCEPTS]]
</ins>
and
RDF
Schema
<del class="diff-old">[
RDF-SCHEMA
],
</del>
<ins class="diff-chg">[[!RDF-SCHEMA]],
</ins>
whenever
possible.
</div>
<del class="diff-old">4.1.6
LDPRs
MUST
use
the
predicate
rdf:type
to
represent
the
concept
of
type.
The
use
of
non-standard
type
predicates,
as
well
as
dcterms:type
,
is
discouraged,
as
it
is
not
recommended
by
the
Dublin
Core
Metadata
Initiative
for
use
with
RDF
resources
[
DC-RDF
].
4.1.7
</del>
<div id="ldpr-4_1_5" class="rule">
<ins class="diff-chg">4.1.5
</ins>
LDPR
representations
SHOULD
have
at
least
one
<code>
rdf:type
</code>
set
explicitly.
<del class="diff-old">This
</del>
<ins class="diff-chg">&#160;This
</ins>
makes
the
representations
much
more
useful
to
client
applications
that
don’t
support
inferencing.
</div>
<del class="diff-old">4.1.8
Predicate
URIs
used
in
LDPR
representations
SHOULD
be
HTTP
URLs.
These
predicate
URIs
MUST
identify
LDPRs
whose
representations
are
retrievable.
LDPR
servers
SHOULD
provide
an
RDF
Schema
[
RDF-SCHEMA
]
representation
of
these
predicates.
ISSUE-9
Should
properties
used
in
LDPR
representations
be
LDPRs
?
4.1.9
LDPRs
MUST
use
at
least
one
RDF
triple
to
represent
a
link
(relationship)
to
another
resource.
In
other
words,
having
the
source
resource’s
URI
as
the
subject
and
the
target
resource’s
URI
as
the
object
of
the
triple
representing
the
link
(relationship)
is
enough
and
does
not
require
the
creation
of
an
intermediate
link
resource
to
describe
the
relationship.
ISSUE-44
4.1.9.
is
obscure
or
too
restrictive
4.1.10
</del>
<div id="ldpr-4_1_6" class="rule">
<ins class="diff-chg">4.1.6
</ins>
LDPR
servers
MAY
support
standard
representations
beyond
those
necessary
to
conform
to
this
specification.
These
could
be
other
RDF
formats,
like
N3
or
NTriples,
but
<del class="diff-old">non-
RDF
</del>
<ins class="diff-chg">non-RDF
</ins>
formats
like
HTML
<del class="diff-old">[
HTML401
]
</del>
<ins class="diff-chg">[[!HTML401]]
</ins>
and
JSON
<del class="diff-old">[
RFC4627
]
</del>
<ins class="diff-chg">[[!RFC4627]]
</ins>
would
<del class="diff-old">be
</del>
likely
be
common.
</div>
<del class="diff-old">4.1.11
</del>
<div id="ldpr-4_1_7" class="rule">
<ins class="diff-chg">4.1.7
</ins>
LDPRs
MAY
be
created,
updated
and
deleted
using
methods
not
defined
in
this
document,
for
example
through
application-specific
means,
SPARQL
UPDATE,
etc.
<del class="diff-old">[
SPARQL-UPDATE
],
</del>
<ins class="diff-chg">[[!SPARQL-UPDATE]],
</ins>
as
long
as
those
methods
do
not
conflict
with
this
specification's
normative
requirements.
</div>
<del class="diff-old">4.1.12
BPR
</del>
<div id="ldpr-4_1_8" class="rule">
<ins class="diff-chg">4.1.8
LDPR
</ins>
server
responses
MUST
use
entity
tags
(either
weak
or
strong
ones)
as
response
<code>
ETag
</code>
header
values.
</div>
<del class="diff-old">ISSUE-15
sharing
binary
resources
and
metadata
ISSUE-16
Redirection
of
non-information
resources
to
LDPRs
ISSUE-19
Adressing
more
error
cases
</del>
<div class="ldp-issue-pending">
<div class="ldp-issue-title">
<a href="http://www.w3.org/2012/ldp/track/issues/32">
ISSUE-32
</a>
</div>
How
can
clients
discover
that
a
resource
is
an
LDPR
or
<del class="diff-old">LDPC
,
</del>
<ins class="diff-chg">LDPC,
</ins>
and
what
features
are
supported?
</div>
<del class="diff-old">ISSUE-33
Pagination
for
non-container
resources
4.1.13
</del>
<div id="ldpr-4_1_9" class="rule">
<ins class="diff-chg">4.1.9
</ins>
LDPR
servers
SHOULD
enable
simple
creation
and
modification
of
<del class="diff-old">LDPRs
.
</del>
<ins class="diff-chg">LDPRs.
</ins>
It
is
common
for
LDPR
servers
to
put
restrictions
on
representations

for
example,
the
range
of
<code>
rdf:type
</code>
predicates,
datatypes
of
the
objects
of
predicates,
and
the
number
of
occurrences
of
predicates
in
an
<del class="diff-old">LDPR
,
</del>
<ins class="diff-chg">LDPR,
</ins>
but
servers
SHOULD
minimize
those
restrictions.
<del class="diff-old">Enforcement
</del>
<ins class="diff-chg">&#160;Enforcement
</ins>
of
more
complex
constraints
will
greatly
restrict
the
set
of
clients
that
can
modify
resources.
For
some
server
applications,
excessive
constraints
on
modification
of
resources
may
be
required.
</div>
<div class="ldp-issue-pending">
<div class="ldp-issue-title">
<a href="http://www.w3.org/2012/ldp/track/issues/57">
<ins class="diff-new">ISSUE-57
</ins></a>
</div>
<ins class="diff-chg">How
can
a
client
determine
that
it
is
in
communication
with
an
LDP
server?
</ins></div><div id="ldpr-4_1_10" class="rule"><ins class="diff-chg">
4.1.10
LDPR
servers
MUST
advertise
their
LDP
support
by
exposing
a
HTTP
</ins><code><ins class="diff-chg">
Link
</ins></code><ins class="diff-chg">
header
with
a
target
URI
of
</ins><code><ins class="diff-chg">
http://www.w3.org/ns/ldp/Resource
</ins></code>,<ins class="diff-chg">
and
a
link
relation
type
of
</ins><code><ins class="diff-chg">
type
</ins></code><ins class="diff-chg">
(that
is,
</ins><code><ins class="diff-chg">
rel="type"
</ins></code><ins class="diff-chg">
)
in
all
responses
to
requests
made
to
the
resource's
HTTP
</ins><code><ins class="diff-chg">
Request-URI
</ins></code>.<ins class="diff-chg">
This
is
notionally
equivalent
to
the
presence
of
a
</ins><var><ins class="diff-chg">
(subject-URI,
</ins><code><ins class="diff-chg">
rdf:type
</ins></code>,<code><ins class="diff-chg">
ldp:Resource
</ins></code><ins class="diff-chg">
)
</ins></var><ins class="diff-chg">
triple
in
the
resource.
The
HTTP
</ins><code><ins class="diff-chg">
Link
</ins></code><ins class="diff-chg">
header
is
the
method
by
which
servers
assert
their
support
for
the
LDP
spec
in
a
way
that
clients
can
introspect
dynamically
at
run-time.
Conservative
clients
should
note
that
a
server
can
host
a
mixture
of
LDPRs
and
other
resources,
and
therefore
there
is
no
implication
that
LDP
support
advertised
on
one
HTTP
</ins><code><ins class="diff-chg">
Request-URI
</ins></code><ins class="diff-chg">
means
that
other
resources
on
the
same
server
are
also
LDPRs.
Each
HTTP
</ins><code><ins class="diff-chg">
Request-URI
</ins></code><ins class="diff-chg">
needs
to
be
individually
introspected
by
a
conservative
client,
in
the
absence
of
outside
information.
</ins></div><div class="ldp-issue-pending"><div class="ldp-issue-title">
<del class="diff-old">4.2
</del>
<a href="http://www.w3.org/2012/ldp/track/issues/78">
<ins class="diff-chg">ISSUE-78
</ins></a></div><ins class="diff-chg">
inferencing
levels
</ins></div><div id="ldpr-4_1_11" class="rule"><ins class="diff-chg">
4.1.11
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
[[!RDF-CONCEPTS]].
The
practical
implication
is
that
all
content
defined
by
LDP
must
be
explicitly
represented.
</ins></div></section><section><h2 id="ldpr-HTTP_GET">
HTTP
GET
</h2>
<div id="ldpr-4_2_1" class="rule">
4.2.1
LDPR
servers
MUST
support
the
HTTP
<code>
GET
</code>
Method
for
<del class="diff-old">LDPRs
.
</del>
<ins class="diff-chg">LDPRs.
</ins>
</div>
<div id="ldpr-4_2_2" class="rule">
4.2.2
LDPR
servers
MUST
provide
a
<code>
text/turtle
</code>
representation
of
the
requested
LDPR
<del class="diff-old">[
TURTLE
].
</del>
<ins class="diff-chg">[[!TURTLE]].
</ins>
</div>
<div id="ldpr-4_2_3" class="rule">
4.2.3
LDPR
servers
MAY
provide
representations
of
the
requested
LDPR
beyond
those
necessary
to
conform
to
this
specification,
using
standard
HTTP
content
negotiation.
If
the
client
does
not
indicate
a
preference,
<code>
text/turtle
</code>
MUST
be
returned.
</div>
<div id="ldpr-4_2_4" class="rule">
4.2.4
In
the
absence
of
special
knowledge
of
the
application
or
domain,
LDPR
clients
MUST
assume
that
any
LDPR
can
have
multiple
values
for
<code>
rdf:type
</code>.
</div>
<div id="ldpr-4_2_5" class="rule">
4.2.5
In
the
absence
of
special
knowledge
of
the
application
or
domain,
LDPR
clients
MUST
assume
that
the
<code>
rdf:type
</code>
values
of
a
given
LDPR
can
change
over
time.
</div>
<del class="diff-old">4.3
</del>
</section>
<section>
<h2 id="ldpr-HTTP_POST">
HTTP
POST
</h2>
<p>
This
specification
adds
no
new
requirements
on
HTTP
<code>
POST
</code>
for
LDPRs
<del class="diff-old">.
</del>
<ins class="diff-chg">only
when
the
LDPR
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
[[!HTTP11]]
makes
it
optional
</ins>
</p>
<p>
<ins class="diff-chg">Creation
of
LDPRs
is
done
via
HTTP
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
to
a
LDPC,
see
the
</ins><a href="#ldpc-HTTP_POST" class="sectionRef">
<del class="diff-old">4.4
</del>
</a>
<ins class="diff-chg">in
the
LDPC
parent
section
for
more
details.
</ins></p></section><section><h2 id="ldpr-HTTP_PUT">
HTTP
PUT
</h2>
<p>
This
specification
imposes
the
following
new
requirements
on
HTTP
<code>
PUT
</code>
for
LDPRs
only
when
the
LDPR
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
<del class="diff-old">[
HTTP11
]
</del>
<ins class="diff-chg">[[!HTTP11]]
</ins>
makes
it
optional.
</p>
<div id="ldpr-4_4_1" class="rule">
4.4.1
If
HTTP
<code>
PUT
</code>
is
performed
on
an
existing
resource,
LDPR
servers
MUST
replace
the
entire
persistent
state
of
the
identified
resource
with
the
entity
representation
in
the
body
of
the
request.
<del class="diff-old">BPR
</del>
<ins class="diff-chg">LDPR
</ins>
servers
MAY
ignore
server
managed
properties
such
as
<code>
dcterms:modified
</code>
and
<code>
dcterms:creator
</code>
if
they
are
not
under
client
control.
Any
LDPR
servers
that
wish
to
support
a
more
sophisticated
merge
of
data
provided
by
the
client
with
existing
state
stored
on
the
server
for
a
resource
MUST
use
HTTP
<del class="diff-old">PATCH,
</del>
<code>
<ins class="diff-chg">PATCH
</ins></code>,
not
HTTP
<del class="diff-old">PUT.
</del>
<code>
<ins class="diff-chg">PUT
</ins></code>.
</div>
<div id="ldpr-4_4_2" class="rule">
4.4.2
LDPR
clients
SHOULD
use
the
HTTP
<code>
If-Match
</code>
header
and
HTTP
<code>
ETags
</code>
to
ensure
it
isn’t
modifying
a
resource
that
has
changed
since
the
client
last
retrieved
its
representation.
LDPR
servers
SHOULD
require
the
HTTP
<code>
If-Match
</code>
header
and
HTTP
<code>
ETags
</code>
to
detect
collisions.
LDPR
servers
MUST
respond
with
status
code
412
(Condition
Failed)
if
<code>
ETag
</code>
s
fail
to
match
<del class="diff-old">if
</del>
<ins class="diff-chg">when
</ins>
there
are
no
other
errors
with
the
request
<del class="diff-old">[
HTTP11
].
</del>
<ins class="diff-chg">[[!HTTP11]].
LDPR
servers
that
require
conditional
requests
MUST
respond
with
status
code
428
(Precondition
Required)
when
the
absence
of
a
precondition
is
the
only
reason
for
rejecting
the
request
[[!RFC6585]].
</ins>
</div>
<div id="ldpr-4_4_3" class="rule">
4.4.3
LDPR
clients
SHOULD
always
assume
that
the
set
of
predicates
for
a
resource
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
resource
is
not
limited
to
any
pre-defined
set.
</div>
<div id="ldpr-4_4_4" class="rule">
4.4.4
LDPR
clients
SHOULD
assume
that
an
LDPR
server
could
discard
triples
whose
predicates
the
server
does
not
recognize
or
otherwise
chooses
not
to
persist.
In
other
words,
LDPR
servers
MAY
restrict
themselves
to
a
known
set
of
predicates,
but
LDPR
clients
MUST
NOT
restrict
themselves
to
a
known
set
of
predicates
when
their
intent
is
to
perform
a
later
HTTP
<code>
PUT
</code>
to
update
the
resource.
</div>
<div id="ldpr-4_4_5" class="rule">
4.4.5
An
LDPR
client
MUST
preserve
all
triples
retrieved
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
<del class="diff-old">PUT.
The
</del>
<code>
<ins class="diff-chg">PUT
</ins></code>.<ins class="diff-chg">
&#160;The
</ins>
use
of
HTTP
<code>
PATCH
</code>
instead
of
HTTP
<code>
PUT
</code>
for
update
avoids
this
burden
for
clients
<del class="diff-old">[
RFC5789
].
</del>
<ins class="diff-chg">[[RFC5789]].
</ins>
</div>
<div id="ldpr-4_4_6" class="rule">
4.4.6
LDPR
servers
MAY
choose
to
allow
the
creation
of
new
resources
using
HTTP
<del class="diff-old">PUT.
</del>
<code>
<ins class="diff-chg">PUT
</ins></code>.
</div>
<div id="ldpr-4_4_7" class="rule">
4.4.7
LDPR
servers
SHOULD
allow
clients
to
update
resources
without
requiring
detailed
knowledge
of
server-specific
constraints.
<ins class="diff-new">&#160;
</ins>
This
is
a
consequence
of
the
requirement
to
<a href="#ldpr-4_1_9">
enable
simple
creation
and
modification
</a>
of
LPDRs.
</div>
<del class="diff-old">4.5
</del>
</section>
<section>
<h2 id="ldpr-HTTP_DELETE">
HTTP
DELETE
</h2>
<p>
This
specification
imposes
the
following
new
requirements
on
HTTP
<code>
DELETE
</code>
for
LDPRs
only
when
the
LDPR
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
<del class="diff-old">[
HTTP11
]
</del>
<ins class="diff-chg">[[!HTTP11]]
</ins>
makes
it
optional.
</p>
<p>
<ins class="diff-chg">Additional
requirements
on
HTTP
</ins><code><ins class="diff-chg">
DELETE
</ins></code><ins class="diff-chg">
of
LDPRs
within
containers
can
be
found
in
</ins><a href="ldpc-HTTP_DELETE"><ins class="diff-chg">
section
5.6
</ins></a>.</p><div id="ldpr-4_5_1" class="rule">
4.5.1
LDPR
servers
MUST
remove
the
resource
identified
by
the
<del class="diff-old">Request-URI.
</del>
<code>
<ins class="diff-chg">Request-URI
</ins></code>.
After
a
successful
HTTP
<del class="diff-old">DELETE,
</del>
<code>
<ins class="diff-chg">DELETE
</ins></code>,
a
subsequent
HTTP
<code>
GET
</code>
on
the
same
<code>
Request-URI
</code>
MUST
result
in
a
404
(Not
found)
or
410
(Gone)
status
code.
Clients
SHOULD
note
that
servers
MAY
reuse
a
URI
under
some
circumstances.
</div>
<div id="ldpr-4_5_2" class="rule">
4.5.2
LDPR
servers
MAY
alter
the
state
of
other
resources
as
a
result
of
an
HTTP
<code>
DELETE
</code>
request.
For
example,
it
is
acceptable
for
the
server
to
remove
triples
from
other
resources
whose
subject
or
object
is
the
deleted
resource.
It
is
also
acceptable
and
common
for
LDPR
servers
to
not
do
this

behavior
is
server
application
specific.
</div>
<del class="diff-old">4.6
</del>
</section>
<section>
<h2 id="ldpr-HTTP_HEAD">
HTTP
HEAD
</h2>
<p>
<ins class="diff-chg">Note
that
certain
LDP
mechanisms,
such
as
paging,
rely
on
HTTP
headers,
and
HTTP
generally
requires
that
</ins><code><ins class="diff-chg">
HEAD
</ins></code><ins class="diff-chg">
responses
include
the
same
headers
as
</ins><code><ins class="diff-chg">
GET
</ins></code><ins class="diff-chg">
responses.
Thus,
implementers
should
also
carefully
read
</ins><a href="#ldpr-HTTP_GET" class="sectionRef"></a>.</p><div id="ldpr-4_6_1" class="rule">
4.6.1
LDPR
servers
MUST
support
the
HTTP
<code>
HEAD
</code>
method.
</div>
<div id="ldpr-4_6_2" class="rule">
4.6.2
LDPR
servers
MUST
<del class="diff-old">indicate
their
</del>
support
<del class="diff-old">for
HTTP
Methods
by
responding
to
a
HTTP
HEAD
request
on
the
LDPR
’s
URL
with
the
HTTP
Method
tokens
in
</del>
the
HTTP
response
<del class="diff-old">header

Allow
”.
</del>
<ins class="diff-chg">headers
defined
in
</ins><a href="#ldpr-HTTP_OPTIONS" class="sectionRef">
<del class="diff-old">4.7
</del>
</a>.
</div>
</section>
<section>
<h2 id="ldpr-HTTP_PATCH">
HTTP
PATCH
</h2>
<p>
This
specification
imposes
the
following
new
requirements
on
HTTP
<code>
PATCH
</code>
for
LDPRs
only
when
the
LDPR
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
<del class="diff-old">[
HTTP11
]
</del>
<ins class="diff-chg">[[!HTTP11]]
</ins>
makes
it
optional.
</p>
<div id="ldpr-4_7_1" class="rule">
4.7.1
LDPR
servers
MAY
implement
HTTP
<code>
PATCH
</code>
to
allow
modifications,
especially
partial
replacement,
of
their
resources
<del class="diff-old">[
RFC5789
].
</del>
<ins class="diff-chg">[[!RFC5789]].
</ins>
No
minimal
set
of
patch
document
formats
is
mandated
by
this
document.
</div>
<div id="ldpr-4_7_2" class="rule">
4.7.2
LDPR
servers
SHOULD
allow
clients
to
update
resources
without
requiring
detailed
knowledge
of
server-specific
constraints.
<ins class="diff-new">&#160;
</ins>
This
is
a
consequence
of
the
requirement
to
<a href="#ldpr-4_1_9">
enable
simple
creation
and
modification
</a>
of
LPDRs.
</div>
<div id="ldpr-4_7_3" class="rule">
4.7.3
LDPR
servers
SHOULD
NOT
allow
clients
to
create
new
resources
using
<del class="diff-old">PATCH.
</del>
<code>
<ins class="diff-chg">PATCH
</ins></code>.<a href="#ldpc-HTTP_POST"><code>
POST
</code>
(to
an
<del class="diff-old">LDPC
)
</del>
<ins class="diff-chg">LDPC)
</ins>
</a>
and/or
<a href="#ldpc-HTTP_PUT">
<code>
PUT
</code>
</a>
should
be
used
as
the
standard
way
to
create
new
<del class="diff-old">LDPRs
.
</del>
<ins class="diff-chg">LDPRs.
</ins>
</div>
<div class="ldp-issue-pending">
<div class="ldp-issue-title">
<del class="diff-old">ISSUE-17
</del>
<a href="http://www.w3.org/2012/ldp/track/issues/32">
<ins class="diff-chg">ISSUE-32
</ins>
</a>
</div>
<del class="diff-old">changesets
as
</del>
<ins class="diff-chg">How
can
clients
discover
that
</ins>
a
<del class="diff-old">recommended
</del>
<ins class="diff-chg">resource
is
an
LDPR
or
LDPC,
and
what
features
are
supported?
</ins></div><div id="ldpr-4_7_4" class="rule"><ins class="diff-chg">
4.7.4
LDPR
servers
that
support
</ins><code>
PATCH
<del class="diff-old">format
</del>
</code>
<ins class="diff-chg">MUST
include
an
</ins><code><ins class="diff-chg">
Accept-Patch
</ins></code><ins class="diff-chg">
HTTP
response
header
[[!RFC5789]]
on
HTTP
</ins><code><ins class="diff-chg">
OPTIONS
</ins></code><ins class="diff-chg">
requests,
listing
patch
document
media
type(s)
supported
by
the
server.
</ins>
</div>
</section>
<section>
<h2 id="ldpr-HTTP_OPTIONS">
<ins class="diff-chg">HTTP
OPTIONS
</ins></h2><p><ins class="diff-chg">
This
specification
imposes
the
following
new
requirements
on
HTTP
</ins><code><ins class="diff-chg">
OPTIONS
</ins></code><ins class="diff-chg">
for
LDPRs
beyond
those
in
[[!HTTP11]].
Other
sections
of
this
specification,
for
example
</ins><a href="#ldpr-HTTP_PATCH"><ins class="diff-chg">
PATCH
</ins></a>,<a href="#header-accept-post"><ins class="diff-chg">
Accept-Post
</ins></a><ins class="diff-chg">
and
</ins><a href="#ldpr-paging-HTTP_OPTIONS"><ins class="diff-chg">
Paging
</ins></a>,<ins class="diff-chg">
add
other
requirements
on
</ins><code><ins class="diff-chg">
OPTIONS
</ins></code><ins class="diff-chg">
responses.
</ins></p><div class="ldp-issue-pending">
<div class="ldp-issue-title">
<del class="diff-old">ISSUE-27
</del>
<a href="http://www.w3.org/2012/ldp/track/issues/32">
<ins class="diff-chg">ISSUE-32
</ins>
</a>
</div>
<del class="diff-old">Should
</del>
<ins class="diff-chg">How
can
clients
discover
that
a
resource
is
an
LDPR
or
LDPC,
and
what
features
are
supported?
</ins></div><div id="ldpr-4_8_1" class="rule"><ins class="diff-chg">
4.8.1
LDPR
servers
MUST
support
</ins>
the
<del class="diff-old">PATCH
method
</del>
<ins class="diff-chg">HTTP
</ins><code><ins class="diff-chg">
OPTIONS
</ins></code><ins class="diff-chg">
method.
</ins></div><div id="ldpr-4_8_2" class="rule"><ins class="diff-chg">
4.8.2
LDPR
servers
MUST
indicate
their
support
for
HTTP
Methods
by
responding
to
a
HTTP
</ins><code><ins class="diff-chg">
OPTIONS
</ins></code><ins class="diff-chg">
request
on
the
LDPR’s
URL
with
the
HTTP
Method
tokens
in
the
HTTP
response
header
</ins><code><ins class="diff-chg">
Allow
</ins></code>.</div></section><section><h2 id="ldpr-Paging"><ins class="diff-chg">
Paging
</ins></h2><section class="informative"><h3 id="ldpr-PagingIntro"><ins class="diff-chg">
Introduction
</ins></h3><p><ins class="diff-chg">
It
sometimes
happens
that
a
resource
is
too
large
to
reasonably
transmit
its
representation
in
a
single
HTTP
response.
This
will
</ins>
be
<del class="diff-old">used,
</del>
<ins class="diff-chg">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
-
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
container
of
all
the
defects
ever
created
will
typically
be
too
big.
Alternatively,
a
server
could
recognize
that
a
resource
that
has
been
requested
is
too
big
to
return
in
a
single
message.
</ins></p><p><ins class="diff-chg">
To
address
this
problem,
LDPRs
should
support
a
technique
called
Paging.
&#160;Paging
can
be
achieved
with
a
simple
RDF
pattern.
For
each
resource,
</ins><code><ins class="diff-chg">
&lt;resourceURL&gt;
</ins></code>,<ins class="diff-chg">
we
define
a
new
'first
page'
resource.
In
this
example,
its
URL
will
be
</ins><code><ins class="diff-chg">
&lt;containerURL&gt;?firstPage
</ins></code>,<ins class="diff-chg">
but
servers
are
free
to
construct
the
URL
</ins>
as
<del class="diff-old">opposed
</del>
<ins class="diff-chg">they
see
fit.
The
triples
in
the
representation
of
the
each
page
are
a
subset
of
the
triples
in
the
resource
-
same
subject,
predicate
and
object.
</ins></p><p><ins class="diff-chg">
LDPR
servers
may
respond
</ins>
to
<del class="diff-old">POST
</del>
<ins class="diff-chg">requests
for
a
resource
by
redirecting
the
client
to
the
first
page
resource

using
a
303
“See
Other”
redirect
to
the
actual
URL
for
the
page
resource.
</ins></p><p><ins class="diff-chg">
Looking
at
an
example
resource
representing
JohnZSmith's
net
worth,
we’ll
split
the
response
across
two
pages.
&#160;
To
find
the
URL
of
the
first
page,
the
client
makes
a
</ins><code><ins class="diff-chg">
OPTIONS
</ins></code><ins class="diff-chg">
request
to
the
resource's
URL,
and
in
the
response
looks
for
a
HTTP
</ins><code><ins class="diff-chg">
Link
</ins></code><ins class="diff-chg">
header
</ins>
with
<code>
<ins class="diff-new">rel="first"
</ins></code><ins class="diff-new">
;
the
target
URI
in
the
header
is
the
URL
of
the
first
page
resource.
The
client
then
requests
the
first
page
as
</ins><code><ins class="diff-new">
http://example.org/netWorth/nw1/assetContainer/?firstPage
</ins></code>:</p><pre class="example"><ins class="diff-new">
# The following is the representation of
#    http://example.org/netWorth/nw1/assetContainer/?firstPage
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/&gt;
   a ldp:Container;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   ldp:membershipPredicate o:asset.
&lt;http://example.org/netWorth/nw1/assetContainer/?firstPage&gt;
   a ldp:Page;
   ldp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer/&gt;;
   ldp:nextPage &lt;http://example.org/netWorth/nw1/assetContainer/?p=2&gt;.
 
&lt;http://example.org/netWorth/nw1&gt;
    a o:NetWorth;
        o:asset
        &lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;,
        &lt;http://example.org/netWorth/nw1/assetContainer/a4&gt;,
        &lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;,
        &lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;
   a o:Stock;
   o:value 100.00.
&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;
   a o:Cash;
   o:value 50.00.
# server initially supplied no data for a3 and a4 in this response
</ins></pre><p><ins class="diff-new">
The
following
example
is
the
result
of
retrieving
the
representation
for
the
next
page:
</ins></p><pre class="example"><ins class="diff-new">
# The following is the representation of
#  http://example.org/netWorth/nw1/assetContainer/?p=2
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/&gt;
   a ldp:Container;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   ldp:membershipPredicate o:asset.
&lt;http://example.org/netWorth/nw1/assetContainer/?p=2&gt;
   a ldp:Page;
   ldp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer/&gt;;
   ldp:nextPage rdf:nil.
&lt;http://example.org/netWorth/nw1&gt;
   a o:NetWorth;
   o:asset 
      &lt;http://example.org/netWorth/nw1/assetContainer/a5&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/a5&gt;
   a o:Stock;
   dcterms:title "Big Co.";
   o:value 200.02.
</ins></pre><p><ins class="diff-new">
In
this
example,
there
is
only
one
member
in
the
container
in
the
final
page.
&#160;To
indicate
this
is
the
last
page,
</ins>
a
<del class="diff-old">given
mime
type?
</del>
<ins class="diff-chg">value
of
</ins><code><ins class="diff-chg">
rdf:nil
</ins></code><ins class="diff-chg">
is
used
for
the
</ins><code><ins class="diff-chg">
ldp:nextPage
</ins></code><ins class="diff-chg">
predicate
of
the
page
resource.
</ins></p><p><ins class="diff-chg">
LDPC
guarantees
that
any
and
all
the
triples
about
the
members
will
be
on
the
same
page
as
the
membership
triple
for
the
member.
</ins></p></section><section><h3 id="ldpr-PagingGET"><ins class="diff-chg">
HTTP
GET
</ins></h3><p><ins class="diff-chg">
In
addition
to
the
requirements
set
forth
in
section
(HTTP
</ins><code><ins class="diff-chg">
GET
</ins></code><ins class="diff-chg">
),
LDPR
servers
that
support
paging
must
also
follow
the
requirements
in
this
section
</ins></p><div id="ldpr-pagingGET-1" class="rule"><ins class="diff-chg">
4.9.2.1
LDPR
servers
SHOULD
allow
clients
to
retrieve
large
LDPRs
in
pages.
In
responses
to
</ins><code><ins class="diff-chg">
GET
</ins></code><ins class="diff-chg">
requests
with
an
LDPR
as
the
</ins><code><ins class="diff-chg">
Request-URI
</ins></code>,<ins class="diff-chg">
LDPR
servers
that
support
paging
SHOULD
provide
an
HTTP
</ins><code><ins class="diff-chg">
Link
</ins></code><ins class="diff-chg">
header
whose
target
URI
is
the
first
page
resource,
and
whose
link
relation
type
is
</ins><code><ins class="diff-chg">
first
</ins></code><ins class="diff-chg">
[[!RFC5988]].
This
is
the
mechanism
by
which
clients
discover
the
URL
of
the
first
page.
If
no
such
</ins><code><ins class="diff-chg">
Link
</ins></code><ins class="diff-chg">
header
is
present,
then
conservative
clients
will
assume
that
the
LDPR
does
not
support
paging.
For
example,
if
there
is
a
LDPR
with
URL
</ins><code><ins class="diff-chg">
&lt;resourceURL&gt;
</ins></code><ins class="diff-chg">
that
supports
paging
and
whose
first
page
URL
is
</ins><code><ins class="diff-chg">
&lt;resourceURL&gt;?theFirstPage
</ins></code>,<ins class="diff-chg">
then
the
corresponding
link
header
would
be
</ins><code><ins class="diff-chg">
Link:
&lt;?theFirstPage&gt;;rel="first"
</ins></code>.<ins class="diff-chg">
The
representation
for
any
page,
including
the
first,
will
include
the
URL
for
the
next
page.&#160;See
</ins><a href="#ldpr-paging" class= "sectionRef"></a><ins class="diff-chg">
for
additional
details.
</ins></div><div id="ldpr-pagingGET-2" class="rule"><ins class="diff-chg">
4.9.2.2
LDPR
servers
MAY
split
the
response
representation
of
any
LDPR.
This
is
known
as
server-initiated
paging.
See
</ins><a href="#ldpr-paging" class="sectionRef"></a><ins class="diff-chg">
for
additional
details.
</ins>
</div>
<div id="ldpr-pagingGET-3" class="rule">
<ins class="diff-new">4.9.2.3
LDPR
servers
that
initiate
paging
SHOULD
respond
to
requests
for
a
LDPR
by
redirecting
the
client
to
the
first
page
resource
using
a
</ins><code><ins class="diff-new">
303
See
Other
</ins></code><ins class="diff-new">
response
with
an
HTTP
</ins><code><ins class="diff-new">
Location
</ins></code><ins class="diff-new">
header
providing
the
first
page
resource
URL.
</ins>
</div>
<div id="ldpr-pagingGET-4" class="rule">
<ins class="diff-new">4.9.2.4
LDPR
servers
that
support
paging
MUST
include
in
the
page
representation
a
representation
for
the
LDPR,
such
that:
</ins>
</div>
<div id="ldpr-pagingGET-5" class="rule">
<ins class="diff-chg">4.9.2.5
The
page
resource
representation
SHOULD
have
one
triple
to
indicate
its
type,
whose
subject
is
the
URL
of
the
page,
whose
predicate
is
</ins><code><ins class="diff-chg">
rdf:type
</ins></code><ins class="diff-chg">
and
object
is
</ins><code><ins class="diff-chg">
ldp:Page
</ins></code>.<ins class="diff-chg">
It
also
SHOULD
have
1
triple
to
indicate
the
resource
it
is
paging,
whose
&#160;subject
is
the
URL
of
the
page,
predicate
is
</ins><code><ins class="diff-chg">
ldp:pageOf
</ins></code>,<ins class="diff-chg">
and
object
is
the
URL
of
the
LDPC.
</ins></div><div id="ldpr-pagingGET-6" class="rule"><ins class="diff-chg">
4.9.2.6
The
page
resource
representation
MUST
have
one
triple
with
the
subject
of
the
page,
predicate
of
</ins><code><ins class="diff-chg">
ldp:nextPage
</ins></code><ins class="diff-chg">
and
object
being
the
URL
for
the
subsequent
page.
</ins></div><div id="ldpr-pagingGET-7" class="rule"><ins class="diff-chg">
4.9.2.7
The
last
page
resource
representation
MUST
have
one
triple
with
the
subject
of
the
last
page,
predicate
of
</ins><code><ins class="diff-chg">
ldp:nextPage
</ins></code><ins class="diff-chg">
and
object
being
</ins><code><ins class="diff-chg">
rdf:nil
</ins></code>.</div></section><section><h3 id="ldpr-paging-HTTP_OPTIONS"><ins class="diff-chg">
HTTP
OPTIONS
</ins></h3><div class="ldp-issue-pending"><div class="ldp-issue-title">
<del class="diff-old">5.
Linked
Data
Platform
Containers
</del>
<a href="http://www.w3.org/2012/ldp/track/issues/32">
<ins class="diff-chg">ISSUE-32
</ins></a>
<del class="diff-old">5.1
Informative
</del>
</div>
<ins class="diff-chg">How
can
clients
discover
that
a
resource
is
an
LDPR
or
LDPC,
and
what
features
are
supported?
</ins></div><div id="ldpr-4_9_3_1" class="rule"><ins class="diff-chg">
4.9.3.1
LDPR
servers
MUST
indicate
their
support
for
client-initiated
paging
by
responding
to
a
HTTP
</ins><code><ins class="diff-chg">
OPTIONS
</ins></code><ins class="diff-chg">
request
on
the
LDPR’s
URL
with
the
HTTP
response
header
for
link
relations
using
the
header
name
of
</ins><code><ins class="diff-chg">
Link
</ins></code><ins class="diff-chg">
and
link
relation
type
</ins><code><ins class="diff-chg">
first
</ins></code><ins class="diff-chg">
[[!RFC5988]].
</ins></div></section></section><section><h2 id="ldpr-inlining"><ins class="diff-chg">
Resource
Inlining:
Representing
Multiple
Resources
in
a
Response
</ins></h2><div class="atrisk"><p class="atrisktext"><ins class="diff-chg">
Feature
At
Risk
</ins></p><p><ins class="diff-chg">
The
LDP
Working
Group
proposes
incorporation
of
the
features
described
in
this
section.
</ins></p><ul><li><ins class="diff-chg">
The
addition
of
</ins><a><ins class="diff-chg">
resource
inlining
</ins></a><ins class="diff-chg">
to
save
application
latency
and
server/network
load
in
controlled
environments.
</ins></li></ul><p><ins class="diff-chg">
Feedback,
both
positive
and
negative,
is
invited
by
sending
email
to
the
mailing
list
in
</ins><a href="#sotd"><ins class="diff-chg">
Status
of
This
Document
</ins></a>.</p></div><section class="informative"><h3 id="ldpr-InliningIntro"><ins class="diff-chg">
Introduction
</ins>
</h3>
<p>
<ins class="diff-new">Servers
whose
resources
are
relatively
granular
may
wish
to
optimistically
provide
more
information
in
a
response
than
what
the
client
actually
requested,
in
order
to
reduce
the
average
number
of
client
application
HTTP
flows.
LDP
provides
some
basic
building
blocks
to
enable
this,
that
implementations
can
re-use
to
build
complete
solutions,
and
they
may
serve
as
complete
solutions
in
applications
with
sufficient
controls
on
resource
content.
These
building
blocks
are
</ins><a><ins class="diff-new">
resource
inlining
</ins></a><ins class="diff-new">
and
</ins><a><ins class="diff-new">
member
inlining
</ins></a>.</p><p><ins class="diff-new">
LDP
does
not
provide
clients
with
any
way
to
detect
whether
or
not
the
server
is
capable
of
inlining
(all
its
resources
or
any
specific
resource),
nor
does
it
provide
clients
with
any
way
to
influence
which
(if
any)
resources
are
inlined
in
any
given
response.
</ins></p><p><ins class="diff-new">
Servers
can
return
extra
triples
on
any
response,
but
fail
to
meet
the
definition
of
</ins><a><ins class="diff-new">
resource
inlining
</ins></a>,<ins class="diff-new">
by
either
returning
a
subset
of
the
other
resource(s)
triples
or
by
failing
to
assert
that
all
triples
were
included
(even
through
they
were).
Clients
might
still
find
the
extra
information
useful,
but
the
only
way
for
clients
to
be
sure
they
had
all
available
information
would
be
to
make
a
HTTP
</ins><code><ins class="diff-new">
GET
</ins></code><ins class="diff-new">
request
against
all
the
other
resource(s).
In
some
applications,
knowing
that
these
requests
are
unnecessary
saves
significant
latency
and
server/network
load.
</ins></p></section><section class="informative"><h3 id="ldpr-InliningWarnings"><ins class="diff-new">
Use
with
Care
</ins></h3><div class="ldp-issue-pending"><div class="ldp-issue-title">
<del class="diff-old">This
</del>
<a href="http://www.w3.org/2012/ldp/track/issues/58">
<ins class="diff-chg">ISSUE-58
</ins></a></div><ins class="diff-chg">
Action
87:
Add
an
informative
</ins>
section
<del class="diff-old">is
non-normative.
</del>
<ins class="diff-chg">on
the
possible
dangers
of
inlining
resources
</ins></div><p><ins class="diff-chg">
The
building
blocks
LDP
provides
can
only
be
safely
used
if
certain
assumptions
hold.
Said
another
way,
resource
inlining
solves
a
subset
of
scenarios,
not
all
scenarios
in
the
general
case

so
if
you
care
about
any
of
the
following
in
a
given
application,
your
server
should
avoid
returning
</ins><em><ins class="diff-chg">
any
</ins>
</em>
<ins class="diff-chg">triples
beyond
those
found
at
the
HTTP
</ins><code><ins class="diff-chg">
Request-URI
</ins></code>.</p><ul><li><p><ins class="diff-chg">
Provenance
is
lost:
because
RDF
graphs
from
multiple
HTTP
resources
are
merged
in
the
response
without
attributing
each
statement
to
its
originating
graph
(i.e.
without
quotation),
it
is
impossible
for
a
client
to
reliably
know
which
triples
came
from
which
HTTP
resource(s).
A
general
solution
allowing
quotation
is
RDF
Datasets;
that
is
expected
to
be
standardized
independently,
and
can
be
used
in
these
cases
once
it
is
available.
</ins></p></li><li><p><ins class="diff-chg">
The
response
may
contain
contradictions
that
are
trivially
obvious
(or
subtle),
and
those
may
or
may
not
be
a
problem
at
the
application
level.
For
a
trivial
example,
two
triples
may
have
identical
subjects
and
predicates
but
different
objects:
"75F
is
too
hot";
"75F
is
too
cold".
Again,
quotation
via
RDF
Datasets
(or
any
equivalent
mechanism)
is
believed
to
provide
a
long
term
solution
once
standardized.
</ins>
</p>
</li>
</ul>
</section>
<section>
<h3 id="ldpr-InliningGET">
<ins class="diff-new">HTTP
GET
</ins></h3><p><ins class="diff-new">
In
addition
to
the
requirements
set
forth
in
other
sections,
LDPR
servers
that
support
</ins><a><ins class="diff-new">
resource
inlining
</ins></a><ins class="diff-new">
must
also
follow
the
requirements
in
this
section.
</ins></p><div class="ldp-issue-pending"><div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58"><ins class="diff-new">
ISSUE-58
</ins></a></div><ins class="diff-new">
Action
89:
Add
a
predicate
ldp:inlinedResource
the
object
of
which
is
a
URI
of
a
linked
resource
that
is
fully
inlined,
marked
as
AT
RISK.
</ins></div><div id="ldpr-4_10_3_1" class="rule"><ins class="diff-new">
4.10.3.1
LDPR
servers
that
support
</ins><a><ins class="diff-new">
resource
inlining
</ins></a><ins class="diff-new">
MUST
include
a
</ins><code><ins class="diff-new">
ldp:Page
</ins></code><ins class="diff-new">
resource
in
the
representation
describing
the
set
of
inlined
resources,
whether
or
not
the
representation
contains
subsequent
pages.
The
</ins><code><ins class="diff-new">
ldp:Page
</ins></code><ins class="diff-new">
resource
conceptually
contains
metadata
about
the
representation;
it
is
usually
not
part
of
the
HTTP
resource's
state,
and
its
presence
does
not
indicate
that
the
LDPR
server
supports
</ins><a href="#ldpr-Paging"><ins class="diff-new">
paging
</ins></a><ins class="diff-new">
in
general.
LDPR
servers
that
include
the
</ins><code><ins class="diff-new">
ldp:Page
</ins></code><ins class="diff-new">
resource
for
inlining
and
also
support
paging
MUST
use
the
same
</ins><code><ins class="diff-new">
ldp:Page
</ins></code><ins class="diff-new">
resource
for
the
triples
required
by
both,
in
order
to
minimize
client
code
complexity.
The
</ins><code><ins class="diff-new">
ldp:Page
</ins></code><ins class="diff-new">
resource's
triples
are
the
LDP-defined
means
by
which
the
servers
communicate
to
LDP
clients
the
set
of
HTTP
resources
whose
state
is
included
in
a
representation,
allowing
clients
to
avoid
HTTP
</ins><code><ins class="diff-new">
GET
</ins></code><ins class="diff-new">
requests
for
them.
</ins></div><div id="ldpr-4_10_3_2" class="rule"><ins class="diff-new">
4.10.3.2
LDPR
servers
that
support
</ins><a><ins class="diff-new">
resource
inlining
</ins></a><ins class="diff-new">
MUST
include
the
</ins><code><ins class="diff-new">
ldp:Page
</ins></code><ins class="diff-new">
resource
described
in
</ins><a href="#ldpr-4_10_3_1"><ins class="diff-new">
section
4.10.3.1
</ins></a><ins class="diff-new">
one
triple
for
each
inlined
resource,
whose
subject
is
the
</ins><code><ins class="diff-new">
ldp:Page
</ins></code><ins class="diff-new">
resource
URI,
whose
predicate
is
</ins><code><ins class="diff-new">
ldp:inlinedResource
</ins></code>,<ins class="diff-new">
and
whose
object
is
the
HTTP
</ins><code><ins class="diff-new">
Request-URI
</ins></code><ins class="diff-new">
of
an
inlined
resource
[[!HTTP11]].
</ins></div><div id="ldpc-4_10_3_3" class="rule"><ins class="diff-new">
4.10.3.3
LDPR
clients
SHOULD
avoid
making
HTTP
</ins><code><ins class="diff-new">
GET
</ins></code><ins class="diff-new">
requests
against
any
resource
whose
HTTP
</ins><code><ins class="diff-new">
Request-URI
</ins></code><ins class="diff-new">
is
the
object
of
a
triple
of
the
form
described
in
</ins><a href="#ldpc-4_10_3_2"><ins class="diff-new">
section
4.10.3.2
</ins></a>,<ins class="diff-new">
unless
there
are
application-specific
reasons
for
doing
so.
Clients
should
note
that
by
the
time
the
representation
is
received,
the
actual
state
of
any
inlined
resource(s)
may
have
changed
due
to
subsequent
requests.
</ins></div><div id="ldpc-4_10_3_4" class="rule"><ins class="diff-new">
4.10.3.4
LDPR
clients
MUST
NOT
assume
that
LDPR
representations
lacking
a
</ins><code><ins class="diff-new">
ldp:Page
</ins></code><ins class="diff-new">
resource
or
lacking
the
triple
described
in
</ins><a href="#ldpc-4_10_3_2"><ins class="diff-new">
section
4.10.3.2
</ins></a><ins class="diff-new">
contain
all
the
triples
for
any
resource(s)
listed
in
the
representation
whose
HTTP
</ins><code><ins class="diff-new">
Request-URI
</ins></code><ins class="diff-new">
differs
from
the
HTTP
</ins><code><ins class="diff-new">
Request-URI
</ins></code><ins class="diff-new">
used
by
the
client.
The
representation
might
in
fact
contain
all
such
triples,
or
some
subset
of
them,
and
that
might
or
might
not
be
completely
adequate
for
the
client's
intended
usage,
but
an
LDP
client
has
no
way
to
discern
from
such
a
representation
which
interpretation
is
accurate.
</ins></div></section></section></section><section><h1 id="ldpc"><ins class="diff-new">
Linked
Data
Platform
Containers
</ins></h1><section class="informative"><h2 id="ldpc-informative"><ins class="diff-new">
Informative
</ins></h2>
<p>
Many
HTTP
applications
and
sites
have
organizing
concepts
that
partition
the
overall
space
of
resources
into
smaller
containers.
Blog
posts
are
grouped
into
blogs,
wiki
pages
are
grouped
into
wikis,
and
products
are
grouped
into
catalogs.
Each
resource
created
in
the
application
or
site
is
created
within
an
instance
of
one
of
these
container-like
entities,
and
users
can
list
the
existing
artifacts
within
one.
Containers
answer
some
basic
questions,
which
are:
</p>
<ol>
<li>
To
which
URLs
can
I
POST
to
create
new
resources?
</li>
<li>
Where
can
I
GET
a
list
of
existing
resources?
</li>
<li>
How
is
the
order
of
the
container
entries
expressed?
</li>
<li>
How
do
I
get
information
about
the
members
along
with
the
container?
</li>
<li>
How
<del class="diff-old">do
I
GET
the
entries
of
a
large
container
broken
up
into
pages?
How
</del>
can
I
ensure
the
resource
data
is
easy
to
query?
</li>
</ol>
<p>
This
document
defines
the
representation
and
behavior
of
containers
that
address
these
issues.
The
set
of
members
of
a
container
is
defined
by
a
set
of
triples
in
its
representation
(and
state)
called
the
membership
triples.
The
membership
triples
of
a
container
all
have
the
same
subject
and
predicate

the
objects
of
the
membership
triples
define
the
members
of
the
container.
The
subject
of
the
membership
triples
is
called
the
membership
subject
and
the
predicate
is
called
the
membership
predicate.
In
the
simplest
cases,
the
membership
subject
will
be
the
LDPC
resource
itself,
but
it
does
not
have
to
be.
The
membership
predicate
is
also
variable
and
will
often
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
members
of
a
container.
<del class="diff-old">This
document
also
explains
how
</del>
<ins class="diff-chg">It
goes
on
</ins>
to
<del class="diff-old">include
information
about
each
member
in
the
container’s
own
representation
and
</del>
<ins class="diff-chg">explain
</ins>
how
to
<del class="diff-old">paginate
the
container
representation
if
it
gets
too
big.
The
model
for
containers
follow
that
of
two
distinct
types:
composition
and
aggregation.
Due
to
composition
constraints,
the
lifespan
of
the
member
resource
must
match
that
of
its
container
and
it
a
member
resource
can
not
be
</del>
<ins class="diff-chg">learn
about
</ins>
a
<del class="diff-old">member
of
more
than
one
container.
For
both
types
</del>
<ins class="diff-chg">set
</ins>
of
<del class="diff-old">containers,
members
are
only
added
by
</del>
<ins class="diff-chg">related
resources,
they
may
have
been
created
</ins>
using
<del class="diff-old">POST,
which
both
creates
the
resource
and
inserts
a
membership
triple.
A
request
</del>
<ins class="diff-chg">POST
or
through
other
means.
It
also
defines
behavior
when
POST
created
resources
are
deleted,
</ins>
to
<del class="diff-old">delete
a
composite
</del>
<ins class="diff-chg">clean
up
</ins>
container
<del class="diff-old">that
has
members,
will
result
in
all
the
members
</del>
<ins class="diff-chg">membership,
</ins>
and
<del class="diff-old">the
container
itself
will
be
deleted.
A
member
resource
is
removed
from
a
composite
container
by
</del>
deleting
<del class="diff-old">the
resource
directly,
which
</del>
<ins class="diff-chg">containers
</ins>
removes
<del class="diff-old">the
</del>
membership
<del class="diff-old">triple
from
the
container.
</del>
<ins class="diff-chg">information
and
possibly
perform
some
cleanup
tasks
on
unreferenced
member
resoruces.
</ins>
</p>
<p>
The
following
illustrates
a
very
simple
container
with
only
three
members
and
some
information
about
the
container
(the
fact
that
it
is
a
container
and
a
brief
title):
</p>
<del class="diff-old"># The following is the representation of
</del>
<pre class="example">
<ins class="diff-chg"># The following is the representation of
</ins>
#    http://example.org/container1/
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
&lt;&gt;
   a ldp:Container;
<del class="diff-old">   dcterms:title &quot;A very simple container&quot;;
rdfs:member
&lt;member1&gt;,
&lt;member2&gt;,
&lt;member3&gt;.
</del>
<ins class="diff-chg">   ldp:membershipSubject &lt;&gt;
   ldp:membershipPredicate rdfs:member;
   dcterms:title "A very simple container";
   rdfs:member &lt;member1&gt;, &lt;member2&gt;, &lt;member3&gt;.
</ins>
</pre>
<p>
This
example
is
very
straightforward
-
the
membership
predicate
is
<code>
rdfs:member
</code>
and
the
membership
subject
is
the
container
itself.
A
POST
to
this
container
will
create
a
new
resource
and
add
it
to
the
list
of
members
by
adding
a
new
membership
triple
to
the
container.
</p>
<p>
Sometimes
it
is
useful
to
use
a
subject
other
than
the
container
itself
as
the
membership
subject
and
to
use
a
predicate
other
than
<code>
rdfs:member
</code>
as
the
membership
<del class="diff-old">predicate,
</del>
<ins class="diff-chg">predicate.
Let's
start
with
a
domain
resource
for
a
person's
net
worth,
</ins>
as
illustrated
<del class="diff-old">below.
</del>
<ins class="diff-chg">below:
</ins>
</p>
<del class="diff-old"># The following is the representation of
#   http://example.org/netWorth/nw1/assetContainer/
</del>
<pre class="example" id="ldpc-ex-membership-full">
<ins class="diff-chg"># The following is a partial representation of
#   http://example.org/netWorth/nw1
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a o:NetWorth;
   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
   o:asset 
      &lt;assetContainer/a1&gt;,
      &lt;assetContainer/a2&gt;;
   o:liability 
      &lt;liabilityContainer/l1&gt;,
      &lt;liabilityContainer/l2&gt;,
      &lt;liabilityContainer/l3&gt;.
</ins></pre><p><ins class="diff-chg">
From
this
example,
there
is
a
</ins><code><ins class="diff-chg">
rdf:type
</ins></code><ins class="diff-chg">
of
</ins><code><ins class="diff-chg">
o:NetWorth
</ins></code><ins class="diff-chg">
indicating
the
resource
represents
an
instance
of
a
person's
net
worth
and
</ins><code><ins class="diff-chg">
o:netWorthOf
</ins></code><ins class="diff-chg">
predicate
indicating
the
associated
person.
There
are
two
sets
of
same-subject,
same-predicate
pairings;
one
for
assets
and
one
for
liabilities.
It
would
be
helpful
to
be
able
to
associate
these
multi-valued
sets
using
a
URL
for
them
to
assist
with
managing
these,
this
is
done
by
associating
containers
with
them
as
illustrated
below:
</ins></p><pre class="example" id="ldpc-ex-membership-full"><ins class="diff-chg">
# The following is an elaborated representation of
#   http://example.org/netWorth/nw1
</ins>
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
<ins class="diff-new">   a o:NetWorth;
   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
   o:asset 
      &lt;assetContainer/a1&gt;,
      &lt;assetContainer/a2&gt;;
   o:liability 
      &lt;liabilityContainer/l1&gt;,
      &lt;liabilityContainer/l2&gt;,
      &lt;liabilityContainer/l3&gt;.
&lt;assetContainer/&gt;
</ins>
   a ldp:Container;
<del class="diff-old">   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
</del>
<ins class="diff-chg">   dcterms:title "The assets of JohnZSmith";
   ldp:membershipSubject &lt;.&gt;;
</ins>
   ldp:membershipPredicate o:asset.
<del class="diff-old">&lt;http://example.org/netWorth/nw1&gt;
   a o:NetWorth;
o:asset
&lt;a1&gt;,
&lt;a2&gt;.
</del>
<ins class="diff-chg">&lt;liabilityContainer/&gt;
   a ldp:Container;
   dcterms:title "The liabilities of JohnZSmith";
   ldp:membershipSubject &lt;.&gt;;
   ldp:membershipPredicate o:liability.
</ins>
</pre>
<p>
The
essential
structure
of
the
container
is
the
same,
but
in
this
example,
the
membership
subject
is
not
the
container
itself

it
is
a
separate
net
worth
resource.
The
membership
<del class="diff-old">predicate
is
</del>
<ins class="diff-chg">predicates
are
</ins>
<code>
o:asset
</code>
<ins class="diff-new">and
</ins><code><ins class="diff-new">
o:liability
</ins></code>

<del class="diff-old">a
predicate
</del>
<ins class="diff-chg">predicates
</ins>
from
the
domain
model.
A
POST
<ins class="diff-new">of
an
asset
representation
</ins>
to
<del class="diff-old">this
</del>
<ins class="diff-chg">the
asset
</ins>
container
will
create
a
new
asset
and
add
it
to
the
list
of
members
by
adding
a
new
membership
triple
to
the
container.
You
might
wonder
why
<del class="diff-old">we
didn’t
just
make
</del>
<code>
http://example.org/netWorth/nw1
</code>
<ins class="diff-new">isn't
made
</ins>
a
container
<ins class="diff-new">itself
</ins>
and
POST
the
new
asset
directly
there.
That
would
be
a
fine
design
if
<code>
http://example.org/netWorth/nw1
</code>
had
only
assets,
but
if
it
has
separate
predicates
for
assets
and
liabilities,
that
design
will
not
work
because
it
is
unspecified
to
which
predicate
the
POST
should
add
a
membership
triple.
Having
separate
<code>
http://example.org/netWorth/nw1/assetContainer/
</code>
and
<code>
http://example.org/netWorth/nw1/liabilityContainer/
</code>
container
resources
allows
both
assets
and
liabilities
to
be
created.
</p>
<pre class="example" id="ldpc-ex-membership-subj">
<ins class="diff-new"># The following is the representation of
#   http://example.org/netWorth/nw1/assetContainer/
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a ldp:Container;
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   ldp:membershipPredicate o:asset.
&lt;http://example.org/netWorth/nw1&gt;
   a o:NetWorth;
   o:asset &lt;a1&gt;, &lt;a2&gt;.
</ins></pre>
<p>
In
this
example,
clients
cannot
simply
guess
which
resource
is
the
membership
subject
and
which
predicate
is
the
membership
predicate,
so
the
example
includes
this
information
in
triples
whose
subject
is
the
LDPC
resource
itself.
</p>
<div id="ldpc-member_data" class="rule informative">
5.1.1
Container
Member
Information
</div>
<del class="diff-old">This
section
is
non-normative
</del>
<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>
<del class="diff-old"># The following is the representation of
#	 http://example.org/netWorth/nw1/assetContainer/
</del>
<pre class="example">
<ins class="diff-chg"># The following is the representation of
#        http://example.org/netWorth/nw1/assetContainer/
</ins>
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp:      &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o:       &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a ldp:Container;
<del class="diff-old">   dcterms:title &quot;The assets of JohnZSmith&quot;;
</del>
<ins class="diff-chg">   dcterms:title "The assets of JohnZSmith";
</ins>
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   ldp:membershipPredicate o:asset.
&lt;http://example.org/netWorth/nw1&gt;
   a o:NetWorth;
   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
&lt;a1&gt;
   a o:Stock;
   o:value 10000.
&lt;a2&gt;
   a o:Bond;
   o:value 20000.
&lt;a3&gt;
   a o:RealEstateHolding;
<del class="diff-old">o:value
300000.
</del>
<ins class="diff-chg">   o:value 300000.
</ins>
</pre>
<p>
<ins class="diff-new">In
a
similar
manner,
when
the
representation
for
the
resource
of
asset
</ins><var>.../&lt;a1&gt;</var><ins class="diff-new">
is
returned
a
server
may
include
the
membership
triple
of
the
form
</ins><var><ins class="diff-new">
(.../assetContainer/,
o:asset,
.../a1).
</ins></var>
<del class="diff-old">5.1.2
Retrieving
</del>
</p>
<div id="ldpc-get_non-member_props" class="rule">
<ins class="diff-chg">5.1.2&#160;Retrieving
</ins>
Only
Non-member
Properties
</div>
<em>
This
section
is
non-normative
</em>
<p>
The
representation
of
a
container
that
has
many
members
will
be
large.
There
are
several
important
cases
where
clients
need
to
access
only
the
non-member
properties
of
the
container.
Since
retrieving
the
whole
container
representation
to
get
this
information
may
be
onerous
for
clients
and
cause
unnecessary
overhead
on
servers,
it
is
desired
to
define
a
way
to
retrieve
only
the
non-member
property
values.
Defining
for
each
LDPC
a
corresponding
resource,
called
the
<del class="diff-old">“non-member
resource”,
</del>
<ins class="diff-chg">“
</ins><a><ins class="diff-chg">
non-member
resource
</ins></a><ins class="diff-chg">
”,
</ins>
whose
state
is
a
subset
of
the
state
of
the
container,
does
this.
</p>
<p>
The
example
listed
here
only
show
a
simple
case
where
only
a
few
simple
non-member
properties
are
retrieved.
In
real
world
situations
more
complex
cases
are
likely,
such
as
those
that
add
other
predicates
to
containers,
for
example
providing
validation
information
and
associating
SPARQL
endpoints.
<del class="diff-old">[
SPARQL-QUERY
]
</del>
<ins class="diff-chg">[[SPARQL-QUERY]]
</ins>
</p>
<p>
Here
is
an
example
requesting
the
non-member
properties
of
a
container
identified
by
the
URL
<code>
http://example.org/container1/
<del class="diff-old">and
adding
</del>
</code>.
<ins class="diff-chg">In
this
case,
</ins>
the
<del class="diff-old">query
string
</del>
<ins class="diff-chg">non-member
resource
is
identified
by
the
URL
</ins>
<code>
<del class="diff-old">?non-member-properties
:
</del>
<ins class="diff-chg">http://example.org/container1?non-member-properties
</ins></code>:
</p>
<p>
Request:
</p>
<del class="diff-old">GET /container1?non-member-properties HTTP/1.1
</del>
<pre class="example">
<ins class="diff-chg">GET /container1?non-member-properties HTTP/1.1
</ins>
Host: example.org
<del class="diff-old">Accept:
text/turtle;
charset=UTF-8
</del>
<ins class="diff-chg">Accept: text/turtle; charset=UTF-8
</ins>
</pre>
<p>
Response:
</p>
<del class="diff-old">HTTP/1.1 200 OK
</del>
<pre class="example">
<ins class="diff-chg">HTTP/1.1 200 OK
</ins>
Content-Type: text/turtle; charset=UTF-8
<del class="diff-old">ETag: &quot;_87e52ce291112&quot;
</del>
<ins class="diff-chg">ETag: "_87e52ce291112"
</ins>
Content-Length: 325
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
&lt;http://example.org/container1/&gt;
   a ldp:Container;
<del class="diff-old">   dcterms:title &quot;A Linked Data Platform Container of Acme Resources&quot;;
</del>
<ins class="diff-chg">   dcterms:title "A Linked Data Platform Container of Acme Resources";
   ldp:membershipSubject http://example.org/container1/;
</ins>
   ldp:membershipPredicate rdfs:member;
<del class="diff-old">dcterms:publisher
&lt;http://acme.com/&gt;.
</del>
<ins class="diff-chg">   dcterms:publisher &lt;http://acme.com/&gt;.
</ins>
</pre>
<del class="diff-old">5.1.3
Paging
This
section
is
non-normative
</del>
<p>
<del class="diff-old">It
sometimes
happens
that
a
container
is
too
large
to
reasonably
transmit
its
representation
in
a
single
HTTP
response.
This
will
be
especially
true
if
the
container
representation
includes
many
triples
from
the
representations
of
its
members.
A
client
could
anticipate
that
a
container
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
container
of
all
</del>
<ins class="diff-chg">While
</ins>
the
<del class="diff-old">defects
ever
created
will
typically
be
too
big.
Alternatively,
a
server
</del>
<ins class="diff-chg">same
non-member
resource
</ins>
could
<del class="diff-old">recognize
that
a
container
that
has
been
requested
is
too
big
to
return
in
a
single
message.
To
address
this
problem,
LDPCs
should
support
a
technique
called
Paging.
Paging
can
</del>
be
<del class="diff-old">achieved
with
a
simple
RDF
pattern.
For
each
container
resource,
&lt;containerURL&gt;
,
we
define
a
new
resource
&lt;containerURL&gt;?firstPage
.
The
triples
in
the
representation
of
&lt;containerURL&gt;?firstPage
are
a
subset
of
the
triples
in
&lt;containerURL&gt;
-
same
subject,
predicate
and
object.
LDPC
servers
may
respond
to
requests
for
a
container
by
redirecting
the
client
</del>
<ins class="diff-chg">used
</ins>
to
<ins class="diff-new">update
</ins>
the
<del class="diff-old">first
page
resource

</del>
<ins class="diff-chg">non-member
properties
via
PUT,
LDP
recommends
</ins>
using
<del class="diff-old">a
303
“See
Other”
redirect
to
the
actual
URL
for
the
page
resource.
Continuing
on
from
the
member
information
from
the
JohnZSmith
net
worth
example,
we’ll
split
the
response
across
two
pages.
The
client
requests
the
first
page
as
http://example.org/netWorth/nw1/assetContainer/?firstPage
:
# The following is the representation of
#    http://example.org/netWorth/nw1/assetContainer/?firstPage
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/&gt;
   a ldp:Container;
   dcterms:title &quot;The assets of JohnZSmith&quot;;
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   ldp:membershipPredicate o:asset.
&lt;http://example.org/netWorth/nw1/assetContainer/?firstPage&gt;
   a ldp:Page;
   ldp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer/&gt;;
   ldp:nextPage &lt;http://example.org/netWorth/nw1/assetContainer/?p=2&gt;.
 
&lt;http://example.org/netWorth/nw1&gt;
    a o:NetWorth;
	o:asset
	&lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;,
	&lt;http://example.org/netWorth/nw1/assetContainer/a4&gt;,
	&lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;,
	&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;
   a o:Stock;
   o:value 100.00.
&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;
   a o:Cash;
   o:value 50.00.
#
server
initially
supplied
no
data
for
a3
and
a4
in
this
response
The
following
example
is
the
result
of
retrieving
the
representation
</del>
<ins class="diff-chg">PATCH
</ins>
for
<del class="diff-old">the
next
page:
# The following is the representation of
#  http://example.org/netWorth/nw1/assetContainer/?p=2
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/&gt;
   a ldp:Container;
   dcterms:title &quot;The assets of JohnZSmith&quot;;
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   ldp:membershipPredicate o:asset.
&lt;http://example.org/netWorth/nw1/assetContainer/?p=2&gt;
   a ldp:Page;
   ldp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer/&gt;;
   ldp:nextPage rdf:nil.
&lt;http://example.org/netWorth/nw1&gt;
   a o:NetWorth;
   o:asset 
      &lt;http://example.org/netWorth/nw1/assetContainer/a5&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/a5&gt;
   a o:Stock;
   dcterms:title &quot;Big Co.&quot;;
o:value
200.02.
In
this
example,
there
is
only
one
member
in
the
container
in
the
final
page.
To
indicate
</del>
this
<del class="diff-old">is
the
last
page,
a
value
of
rdf:nil
is
used
for
the
ldp:nextPage
predicate
of
the
page
resource.
LDPC
guarantees
that
any
and
all
the
triples
about
the
members
will
be
on
the
same
page
as
the
membership
triple
for
the
member.
</del>
<ins class="diff-chg">purpose.
</ins>
</p>
<div id="ldpc-ordering" class="rule">
5.1.4
Ordering
</div>
<em>
This
section
is
non-normative
</em>
<p>
There
are
many
cases
where
an
ordering
of
the
members
of
the
container
is
important.
LDPC
does
not
provide
any
particular
support
for
server
ordering
of
members
in
containers,
because
any
client
can
order
the
members
in
any
way
it
chooses
based
on
the
value
of
any
available
property
of
the
members.
In
the
example
below,
the
value
of
the
<code>
o:value
</code>
predicate
is
present
for
each
member,
so
the
client
can
easily
order
the
members
according
to
the
value
of
that
property.
In
this
way,
LDPC
avoids
the
use
of
RDF
constructs
like
Seq
and
List
for
expressing
order.
</p>
<p>
Order
<del class="diff-old">only
</del>
becomes
<ins class="diff-new">more
</ins>
important
for
LDPC
servers
when
containers
are
paginated.
If
the
server
does
not
respect
ordering
when
constructing
pages,
the
client
<del class="diff-old">is
</del>
<ins class="diff-chg">would
be
</ins>
forced
to
retrieve
all
pages
before
sorting
the
members,
which
would
defeat
the
purpose
of
pagination.
In
cases
where
ordering
is
important,
an
LDPC
server
exposes
all
the
members
on
a
page
with
<ins class="diff-new">the
proper
sort
order
with
relation
to
all
members
on
the
next
and
previous
pages.
When
the
sort
is
ascending,
all
the
members
on
a
current
page
have
</ins>
a
higher
sort
order
than
all
members
on
the
previous
page
and
lower
sort
order
than
all
the
members
on
the
next
page.
<del class="diff-old">The
LDPC
specification
provides
a
predicate
-
ldp:containerSortPredicates
-
that
</del>
<ins class="diff-chg">When
</ins>
the
<del class="diff-old">server
</del>
<ins class="diff-chg">sort
is
descending,
the
opposite
order
is
used.
Since
more
than
one
value
</ins>
may
<del class="diff-old">use
</del>
<ins class="diff-chg">be
used
</ins>
to
<del class="diff-old">communicate
</del>
<ins class="diff-chg">sort
members,
the
LDPC
specification
allows
servers
</ins>
to
<ins class="diff-new">assert
</ins>
the
<del class="diff-old">client
which
predicates
were
used
for
page
ordering.
Multiple
predicate
values
may
have
been
</del>
<ins class="diff-chg">ordered
list
of
sort
criteria
</ins>
used
<del class="diff-old">for
sorting,
so
</del>
<ins class="diff-chg">to
sort
</ins>
the
<del class="diff-old">value
</del>
<ins class="diff-chg">members,
using
the
</ins><code><ins class="diff-chg">
ldp:containerSortCriteria
</ins></code><ins class="diff-chg">
relation.
Each
member
</ins>
of
<del class="diff-old">this
predicate
is
an
</del>
<ins class="diff-chg">the
</ins>
ordered
<del class="diff-old">list.
</del>
<ins class="diff-chg">list
exposes
one
</ins><code><ins class="diff-chg">
ldp:containerSortCriterion
</ins></code>,<ins class="diff-chg">
consisting
of
a
</ins><code><ins class="diff-chg">
ldp:containerSortPredicate
</ins></code>,<code><ins class="diff-chg">
ldp:containerSortPredicate
</ins></code>,<ins class="diff-chg">
and
optionally
a
</ins><code><ins class="diff-chg">
ldp:containerSortCollation
</ins></code>.
</p>
<p>
Here
is
an
example
container
described
previously,
with
representation
for
ordering
of
the
assets:
</p>
<del class="diff-old"># The following is the ordered representation of
</del>
<pre class="example">
<ins class="diff-chg"># The following is the ordered representation of
</ins>
#   http://example.org/netWorth/nw1/assetContainer/
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a ldp:Container;
<del class="diff-old">   dcterms:title &quot;The assets of JohnZSmith&quot;;
</del>
<ins class="diff-chg">   dcterms:title "The assets of JohnZSmith";
</ins>
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   ldp:membershipPredicate o:asset.
&lt;?firstPage&gt;
   a ldp:Page;
   ldp:pageOf &lt;&gt;;
<del class="diff-old">   ldp:containerSortPredicates (o:value).
</del>
<ins class="diff-chg">   ldp:ContainerSortCriteria (#SortValueAscending).
&lt;#SortValueAscending&gt;
   a ldp:ContainerSortCriterion;
   ldp:containerSortOrder ldp:ascendingOrder;
   ldp:containerSortPredicate o:value.
</ins>
&lt;http://example.org/netWorth/nw1&gt;
   a o:NetWorth;
   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
&lt;a1&gt;
   a o:Stock;
   o:value 100.00.
&lt;a2&gt;
   a o:Cash;
   o:value 50.00.
&lt;a3&gt;
   a o:RealEstateHolding;
<del class="diff-old">o:value
300000.
</del>
<ins class="diff-chg">   o:value 300000.
</ins>
</pre>
<p>
As
you
can
see
by
the
addition
of
the
<code>
<del class="diff-old">ldp:containerSortPredicates
</del>
<ins class="diff-chg">ldp:ContainerSortCriteria
</ins>
</code>
predicate,
the
<code>
o:value
</code>
predicate
is
used
to
<del class="diff-old">define
the
ordering
of
</del>
<ins class="diff-chg">order
</ins>
the
<del class="diff-old">results.
It
</del>
<ins class="diff-chg">page
members
in
ascending
order.
&#160;It
</ins>
is
up
to
the
domain
model
and
server
to
determine
the
appropriate
predicate
to
indicate
the
resource’s
order
within
a
page,
and
up
to
the
client
receiving
this
representation
to
use
that
order
in
whatever
way
is
appropriate,
for
example
to
sort
the
data
prior
to
presentation
on
a
user
interface.
</p>
<del class="diff-old">5.2
</del>
</section>
<section>
<h2 id="ldpc-general">
General
</h2>
<p>
The
Linked
Data
Platform
does
not
define
how
clients
discover
<dfn>
<abbr title="Linked Data Platform Containers">
LDPCs
</abbr>
</dfn>.
</p>
<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
<del class="diff-old">The
</del>
<ins class="diff-chg">For
an
LDPC,
the
</ins>
same
<del class="diff-old">resource,
</del>
<ins class="diff-chg">resource
(LDPR
or
not)
which
is
</ins>
identified
by
its
canonical
URI,
<del class="diff-old">MUST
be
a
member
of
only
a
single
LDPC
.
The
same
resource
can
not
</del>
<ins class="diff-chg">MAY
</ins>
be
a
member
of
<del class="diff-old">mutliple
LDPCs
.
</del>
<ins class="diff-chg">more
than
one
LDPC.
</ins>
</div>
<div id="ldpc-5_2_3" class="rule">
5.2.3
The
state
of
an
LDPC
includes
information
about
which
resources
are
its
members.
In
the
simplest
cases,
the
membership
subject
will
be
the
LDPC
resource
itself,
but
it
does
not
have
to
be.
The
membership
predicate
is
also
variable
and
will
often
be
a
predicate
from
the
server
application
vocabulary.
If
there
is
no
obvious
predicate
from
the
server
application
vocabulary
to
use,
LDPC
servers
SHOULD
use
the
<code>
rdfs:member
</code>
predicate.
<del class="diff-old">ISSUE-21
container
affordances
</del>
<ins class="diff-chg">Member
resources
can
be
any
kind
of
resource
identified
by
its
URI,
LDPR
or
otherwise.
</ins>
</div>
<div id="ldpc-5_2_4" class="rule">
5.2.4
An
LDPC
MUST
contain
one
triple
<del class="diff-old">containing
the
ldp:membershipSubject
predicate
when
the
membership
</del>
<ins class="diff-chg">whose
</ins>
subject
is
<del class="diff-old">not
</del>
the
LDPC
<del class="diff-old">itself.
This
triple's
</del>
<ins class="diff-chg">URI,
whose
predicate
is
the
</ins><code><ins class="diff-chg">
ldp:membershipSubject
</ins></code>,<ins class="diff-chg">
and
whose
</ins>
object
<del class="diff-old">provides
clients
with
</del>
<ins class="diff-chg">is
</ins>
the
<del class="diff-old">LDPC
's
</del>
<ins class="diff-chg">LDPC's
</ins>
membership
subject
URI.
</div>
<div id="ldpc-5_2_5" class="rule">
5.2.5
An
LDPC
MUST
contain
one
triple
<del class="diff-old">containing
</del>
<ins class="diff-chg">whose
subject
is
</ins>
the
<ins class="diff-new">LDPC
URI,
and
whose
predicate
is
either
</ins>
<code>
ldp:membershipPredicate
</code>
<ins class="diff-new">or
</ins><code><ins class="diff-new">
ldp:membershipPredicateInverse
</ins></code>.<ins class="diff-new">
The
object
of
the
triple
is
constrained
by
other
sections,
such
as
</ins><a href="ldpc-5_2_5_1"><ins class="diff-new">
5.2.5.1
</ins></a><ins class="diff-new">
or
</ins><a href="ldpc-5_2_5_2"><ins class="diff-new">
5.2.5.2
</ins></a>.</div><div class="ldp-issue-pending"><div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/75"><ins class="diff-new">
ISSUE-75
</ins></a></div><ins class="diff-new">
non-monotonic
ldp:membershipXXX
relations.
Drafted
per
2013-06-18
F2F
resolution.
</ins></div><div id="ldpc-5_2_5_1" class="rule"><ins class="diff-new">
5.2.5.1
For
a
given
triple
</ins><var><ins class="diff-new">
T
</ins></var><ins class="diff-new">
with
a
subject
</ins><var><ins class="diff-new">
C
</ins></var><ins class="diff-new">
of
the
LDPC
and
</ins>
predicate
<del class="diff-old">when
</del>
<ins class="diff-chg">of
</ins><code><ins class="diff-chg">
ldp:membershipPredicate
</ins></code>,
the
<del class="diff-old">container
</del>
<ins class="diff-chg">object
MUST
be
the
URI
of
the
membership
</ins>
predicate
<del class="diff-old">is
not
</del>
<var>
<ins class="diff-chg">P
</ins></var><ins class="diff-chg">
used
to
indicate
membership
to
the
linked
to
LDPC,
or
simply:
</ins><var><ins class="diff-chg">
T
=
(
C
</ins></var>,
<code>
<del class="diff-old">rdfs:member
.
This
triple's
</del>
<ins class="diff-chg">ldp:membershipPredicate
</ins></code>,<var><ins class="diff-chg">
P)
</ins></var>.<ins class="diff-chg">
For
the
membership
predicate
URI
</ins>
object
<del class="diff-old">provides
clients
</del>
<ins class="diff-chg">used
in
the
triple
</ins><var><ins class="diff-chg">
T
</ins></var>,<ins class="diff-chg">
it
would
be
found
in
a
resource's
same
subject
</ins><var><ins class="diff-chg">
R
</ins></var><ins class="diff-chg">
and
same
predicate
</ins><var><ins class="diff-chg">
P
</ins></var><ins class="diff-chg">
membership
triples
of
the
form:
(
</ins><var><ins class="diff-chg">
R
</ins></var>,<var><ins class="diff-chg">
P
</ins></var>,<var><ins class="diff-chg">
MR
</ins></var><ins class="diff-chg">
),
where
</ins><var><ins class="diff-chg">
MR
</ins></var><ins class="diff-chg">
represents
URI
of
a
member
resource.
</ins></div><div id="ldpc-5_2_5_2" class="rule"><ins class="diff-chg">
5.2.5.2
For
a
given
triple
</ins><var><ins class="diff-chg">
T
</ins></var>
with
<ins class="diff-new">a
subject
</ins><var><ins class="diff-new">
C
</ins></var><ins class="diff-new">
of
</ins>
the
LDPC
<del class="diff-old">'s
</del>
<ins class="diff-chg">and
predicate
of
</ins><code><ins class="diff-chg">
ldp:membershipPredicateInverse
</ins></code>,<ins class="diff-chg">
the
object
MUST
be
the
URI
of
the
</ins>
membership
predicate
<del class="diff-old">URI.
</del>
<var>
<ins class="diff-chg">P
</ins></var><ins class="diff-chg">
used
to
indicate
membership
to
the
linked
to
LDPC,
or
simply:
</ins><var><ins class="diff-chg">
T
=
(
C
</ins></var>,<code><ins class="diff-chg">
ldp:membershipPredicateInverse
</ins></code>,<var><ins class="diff-chg">
P)
</ins></var>.<ins class="diff-chg">
For
the
membership
predicate
URI
object
used
in
the
triple
</ins><var><ins class="diff-chg">
T
</ins></var>,<ins class="diff-chg">
it
would
be
found
in
a
resource's
object
subject
</ins><var><ins class="diff-chg">
R
</ins></var><ins class="diff-chg">
and
same
predicate
</ins><var><ins class="diff-chg">
P
</ins></var><ins class="diff-chg">
membership
triples
of
the
form:
(
</ins><var><ins class="diff-chg">
MR
</ins></var>,<var><ins class="diff-chg">
P
</ins></var>,<var><ins class="diff-chg">
R
</ins></var><ins class="diff-chg">
),
where
</ins><var><ins class="diff-chg">
MR
</ins></var><ins class="diff-chg">
represents
URI
of
a
member
resource.
</ins>
</div>
<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,
or
that
are
from
the
representations
of
the
members
(if
they
have
RDF
representations).
This
allows
a
LDPC
server
to
provide
clients
with
information
about
the
members
without
the
client
having
to
do
a
<code>
GET
</code>
on
each
member
individually.
See
section
<a href="#ldpc-member_data">
5.1.1
Container
Member
Information
</a>
for
additional
details.
<del class="diff-old">ISSUE-13
</del>
</div>
<del class="diff-old">Include
clarifications
about
LDPC
representations
that
include
member
triples
</del>
<div id="ldpc-5_2_7" class="rule">
5.2.7
The
representation
of
a
LDPC
MUST
have
<code>
rdf:type
</code>
of
<code>
ldp:Container
</code>,
but
it
MAY
have
additional
<code>
rdf:type
</code>
s.
</div>
<div id="ldpc-5_2_8" class="rule">
5.2.8
LDPCs
SHOULD
NOT
use
RDF
container
types
<code>
rdf:Bag
</code>,
<code>
rdf:Seq
</code>
or
<code>
rdf:List
</code>.
</div>
<div id="ldpc-5_2_9" class="rule">
<ins class="diff-chg">5.2.9
LDPC
servers
SHOULD
NOT
re-use
URIs,
regardless
of
the
mechanism
by
which
members
are
created
(
</ins><code><ins class="diff-chg">
POST
</ins></code>,<code><ins class="diff-chg">
PUT
</ins></code>,<ins class="diff-chg">
etc.).
Certain
specific
cases
exist
where
a
LDPC
server
MAY
delete
a
resource
and
then
later
re-use
the
URI
when
it
identifies
the
same
resource,
but
only
when
consistent
with
Web
architecture
[[WEBARCH]].
While
it
is
difficult
to
provide
absolute
implementation
guarantees
of
non-reuse
in
all
failure
scenarios,
re-using
URIs
creates
ambiguities
for
clients
that
are
best
avoided.
</ins></div><div id="ldpc-5_2_10" class="rule"><ins class="diff-chg">
5.2.10
Some
LDPC's
have
membership
object's
that
are
not
directly
URIs
minted
upon
LDPC
member
creation,
for
example
URIs
with
non-empty
fragment
identifier
[[RFC3986]].
To
determine
which
object
URI
to
use
for
the
membership
triple,
LDPC's
MUST
contain
triple
whose
subject
is
the
LDPC
URI,
predicate
is
</ins><code><ins class="diff-chg">
ldp:membershipObject
</ins></code>,<ins class="diff-chg">
with
an
object
</ins><var><ins class="diff-chg">
MO
</ins></var>.<ins class="diff-chg">
Where
</ins><var><ins class="diff-chg">
MO
</ins></var><ins class="diff-chg">
and
the
HTTP
URI
</ins><var><ins class="diff-chg">
R
</ins></var><ins class="diff-chg">
from
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
create
(as
found
in
HTTP
response
</ins><code><ins class="diff-chg">
Location
</ins></code><ins class="diff-chg">
header)
can
be
used
to
locate
a
triple
of
the
form:
</ins><var><ins class="diff-chg">
(R,
MO,
N)
</ins></var><ins class="diff-chg">
and
where
</ins><var><ins class="diff-chg">
N
</ins></var><ins class="diff-chg">
can
be
used
to
construct
the
membership
triple
of
the
form:
</ins><var><ins class="diff-chg">
(membership
subject,
membership
predicate,
N)
</ins></var>.<ins class="diff-chg">
When
</ins><code><ins class="diff-chg">
ldp:membershipPredicateInverse
</ins></code><ins class="diff-chg">
is
used
instead
of
</ins><code><ins class="diff-chg">
ldp:membershipPredicate
</ins></code>,<ins class="diff-chg">
the
membership
triple
MUST
be
of
the
form:
</ins><var><ins class="diff-chg">
(N,
membership
predicate,
membership
subject)
</ins></var>.<ins class="diff-chg">
To
indicate
that
the
member
resource
URI
is
the
membership
object
(the
default
or
typical
case),
the
object
MUST
be
set
to
predefined
URI
</ins><code><ins class="diff-chg">
ldp:MemberSubject
</ins></code><ins class="diff-chg">
such
that
it
forms
the
triple:
</ins><var><ins class="diff-chg">
(LDPC
URI,
</ins><code><ins class="diff-chg">
ldp:membershipObject
</ins></code>,<code><ins class="diff-chg">
ldp:MemberSubject
</ins></code><ins class="diff-chg">
)
</ins></var>.</div><div class="ldp-issue-pending">
<div class="ldp-issue-title">
<del class="diff-old">ISSUE-38
</del>
<a href="http://www.w3.org/2012/ldp/track/issues/72">
<ins class="diff-chg">ISSUE-72
</ins>
</a>
</div>
<del class="diff-old">filtered
representations
and
inlining
</del>
<ins class="diff-chg">edited
in
ldp:membershipObject
in
new
previous
section
</ins>
</div>
<del class="diff-old">5.3
</del>
</section>
<section>
<h2 id="ldpc-HTTP_GET">
HTTP
GET
</h2>
<div id="ldpc-5_3_1" class="rule">
5.3.1
The
representation
of
a
LDPC
MUST
contain
a
set
of
triples
with
a
consistent
subject
and
predicate
whose
objects
indicate
members
of
the
container.
The
subject
of
the
triples
MAY
be
the
container
itself
or
MAY
be
another
resource
(as
in
the
<a href="#ldpc-ex-membership-subj">
example
</a>
).
<del class="diff-old">See
</del>
<ins class="diff-chg">&#160;See
</ins>
also
<a href="#ldpc-5_2_3">
5.2.3
</a>.
</div>
<div id="ldpc-5_3_2" class="rule">
5.3.2
LDPC
servers
<del class="diff-old">SHOULD
support
requests
for
information
about
a
known
LDPC
without
retrieving
a
full
representation
including
all
of
its
members,
by
the
existence
of
the
token
&quot;
non-member-properties
&quot;
on
</del>
<ins class="diff-chg">MAY
represent
</ins>
the
<del class="diff-old">query
component
</del>
<ins class="diff-chg">members
</ins>
of
<del class="diff-old">the
LDPC
URL.
For
example,
if
there
is
</del>
a
<ins class="diff-chg">paged
</ins>
LDPC
<del class="diff-old">URL
&lt;containerURL&gt;,
the
URL
to
request
</del>
<ins class="diff-chg">in
a
sequential
order.
&#160;If
</ins>
the
<del class="diff-old">non-membership
properties
would
be
&lt;containerURL&gt;?non-member-properties
.
See
section
5.1.2
Retrieving
Only
Non-member
Properties
for
examples.
An
LDPC
</del>
server
<del class="diff-old">that
</del>
does
<del class="diff-old">not
support
a
request
to
retrieve
non-member
resource
properties
via
a
Request-URI
of

&lt;containerURL&gt;?non-member-properties
”,
MUST
return
a
HTTP
status
code
404
(Not
Found).
An
LDPC
server
that
supports
a
request
to
retrieve
non-member
resource
properties
via
a
different
Request-URI
than

&lt;containerURL&gt;?non-member-properties
”,
</del>
<ins class="diff-chg">so,
it
</ins>
MUST
<del class="diff-old">return
a
HTTP
Redirection
3xx
status
code
such
as
301
(Moved
Permanently)
or
302
(Found).
5.3.3
An
LDPC
server
that
does
not
support
</del>
<ins class="diff-chg">be
specify
the
order
using
</ins>
a
<del class="diff-old">request
to
retrieve
</del>
<ins class="diff-chg">triple
whose
subject
is
</ins>
the
<del class="diff-old">first
</del>
page
<del class="diff-old">resource
representation
from
a
known
LDPC
</del>
<ins class="diff-chg">URI,
</ins>
whose
<del class="diff-old">URL
</del>
<ins class="diff-chg">predicate
</ins>
is
<del class="diff-old">“
</del>
<code>
<del class="diff-old">&lt;containerURL&gt;

by
using
the
Request-URI

</del>
<ins class="diff-chg">ldp:containerSortCriteria
</ins></code>,<ins class="diff-chg">
and
whose
object
is
a
</ins>
<code>
<del class="diff-old">&lt;containerURL&gt;?firstPage
</del>
<ins class="diff-chg">rdf:List
</ins>
</code>
<del class="diff-old">”,
MUST
return
a
HTTP
status
code
404
(Not
Found).
An
LDPC
server
that
supports
that
request
using
a
different
Request-URI
than

</del>
<ins class="diff-chg">of
</ins>
<code>
<del class="diff-old">&lt;containerURL&gt;?firstPage
</del>
<ins class="diff-chg">ldp:containerSortCriterion
</ins>
</code>
<del class="diff-old">”,
</del>
<ins class="diff-chg">resources.
The
resulting
order
</ins>
MUST
<del class="diff-old">return
a
HTTP
Redirection
3xx
status
code
such
</del>
<ins class="diff-chg">be
</ins>
as
<del class="diff-old">301
(Moved
Permanently)
or
302
(Found).
5.3.4
LDPC
servers
SHOULD
support
requests
for
splitting
large
LDPCs
into
pages
indicated
</del>
<ins class="diff-chg">defined
</ins>
by
<del class="diff-old">a
client
supplying
the
token

</del>
<ins class="diff-chg">SPARQL
</ins>
<code>
<del class="diff-old">firstPage
</del>
<ins class="diff-chg">SELECT
</ins>
</code>
<del class="diff-old">”
on
</del>
<ins class="diff-chg">’s
</ins><code><ins class="diff-chg">
ORDER
BY
</ins></code><ins class="diff-chg">
clause
[[!SPARQL-QUERY]].
Sorting
criteria
MUST&#160;be
</ins>
the
<del class="diff-old">query
component
</del>
<ins class="diff-chg">same
for
all
pages
</ins>
of
<del class="diff-old">the
LDPC
URL.
For
example,
if
there
is
</del>
a
<del class="diff-old">LDPC
URL
&lt;containerURL&gt;
,
</del>
<ins class="diff-chg">representation;
if
</ins>
the
<del class="diff-old">URL
</del>
<ins class="diff-chg">criteria
were
allowed
</ins>
to
<del class="diff-old">request
</del>
<ins class="diff-chg">vary,
</ins>
the
<del class="diff-old">first
page
</del>
<ins class="diff-chg">ordering
among
members
of
a
container
across
pages
</ins>
would
be
<del class="diff-old">&lt;containerURL&gt;?firstPage
.
</del>
<ins class="diff-chg">undefined.
</ins>
The
<del class="diff-old">representation
for
any
page,
including
the
first,
will
include
the
URL
for
the
next
page.
See
section
5.1.3
Paging
for
additional
details.
5.3.5
LDPC
servers
MAY
split
</del>
<ins class="diff-chg">first
list
entry
provides
</ins>
the
<del class="diff-old">response
representation
of
</del>
<ins class="diff-chg">primary
sorting
criterion,
any
second
entry
provides
</ins>
a
<del class="diff-old">LDPC
regardless
of
what
</del>
<ins class="diff-chg">secondary
criterion
used
to
order
members
considered
equal
according
to
</ins>
the
<del class="diff-old">client
requested
(such
as
when
a
client
omits
a

firstPage

query
component
of
a
request
URL).
This
is
also
known
as
server-initiated
paging.
</del>
<ins class="diff-chg">primary
criterion,
and
so
on.
</ins>
See
section
<del class="diff-old">5.1.3
Paging
</del>
<a href="#ldpc-ordering">
<ins class="diff-chg">5.1.4
Ordering
</ins>
</a>
for
<del class="diff-old">additional
details.
</del>
<ins class="diff-chg">an
example.
</ins>
</div>
<del class="diff-old">5.3.5.1
LDPC
servers
that
initiate
paging
SHOULD
respond
to
requests
for
a
</del>
<div id="ldpc-5_3_3" class="rule">
<ins class="diff-chg">5.3.3
</ins>
LDPC
<del class="diff-old">by
redirecting
the
client
to
the
</del>
page
<del class="diff-old">resource

</del>
<ins class="diff-chg">representations
ordered
</ins>
using
<del class="diff-old">a
303
“See
Other”
redirect
to
the
actual
URL
for
the
page
resource.
5.3.6
LDPC
servers
that
support
paging
</del>
<code>
<ins class="diff-chg">ldp:containerSortCriteria
</ins></code>
MUST
<del class="diff-old">include
</del>
<ins class="diff-chg">contain,
</ins>
in
<del class="diff-old">the
page
representation
</del>
<ins class="diff-chg">every
</ins><code><ins class="diff-chg">
ldp:containerSortCriterion
</ins></code><ins class="diff-chg">
list
entry,
</ins>
a
<del class="diff-old">representation
for
the
LDPC
,
such
that:
5.3.6.1
The
page
resource
representation
SHOULD
have
one
</del>
triple
<del class="diff-old">to
indicate
its
type,
</del>
whose
subject
is
the
<del class="diff-old">URL
of
the
page,
</del>
<ins class="diff-chg">sort
criterion
identifier,
</ins>
whose
predicate
is
<code>
<del class="diff-old">rdf:type
</del>
<ins class="diff-chg">ldp:containerSortPredicate
</ins>
</code>
and
<ins class="diff-new">whose
</ins>
object
is
<del class="diff-old">ldp:Page
.
It
also
SHOULD
have
1
triple
to
indicate
</del>
the
<del class="diff-old">container
it
is
paging,
</del>
<ins class="diff-chg">predicate
</ins>
whose
<del class="diff-old">subject
</del>
<ins class="diff-chg">value
</ins>
is
<del class="diff-old">the
URL
of
the
page,
</del>
<ins class="diff-chg">used
to
order
members
between
pages
(the
</ins><dfn><ins class="diff-chg">
page-ordering
values
</ins></dfn><ins class="diff-chg">
).
The
only
</ins>
predicate
<del class="diff-old">is
</del>
<ins class="diff-chg">data
types
whose
behavior
LDP
constrains
are
those
defined
by
SPARQL
</ins>
<code>
<del class="diff-old">ldp:pageOf
,
</del>
<ins class="diff-chg">SELECT
</ins></code><ins class="diff-chg">
’s
</ins><code><ins class="diff-chg">
ORDER
BY
</ins></code><ins class="diff-chg">
clause
[[!SPARQL-QUERY]].
Other
data
types
can
be
used,
but
LDP
assigns
no
meaning
to
them
</ins>
and
<del class="diff-old">object
is
the
URL
of
the
LDPC
.
</del>
<ins class="diff-chg">interoperability
will
be
limited.
</ins>
</div>
<del class="diff-old">5.3.6.2
The
</del>
<div id="ldpc-5_3_4" class="rule">
<ins class="diff-chg">5.3.4
LDPC
</ins>
page
<del class="diff-old">resource
representation
</del>
<ins class="diff-chg">representations
ordered
using
</ins><code><ins class="diff-chg">
ldp:containerSortCriteria
</ins></code>
MUST
<del class="diff-old">have
one
</del>
<ins class="diff-chg">contain,
in
every
</ins><code><ins class="diff-chg">
ldp:containerSortCriterion
</ins></code><ins class="diff-chg">
list
entry,
a
</ins>
triple
<del class="diff-old">with
the
</del>
<ins class="diff-chg">whose
</ins>
subject
<del class="diff-old">of
</del>
<ins class="diff-chg">is
</ins>
the
<del class="diff-old">page,
</del>
<ins class="diff-chg">sort
criterion
identifier,
whose
</ins>
predicate
<del class="diff-old">of
</del>
<ins class="diff-chg">is
</ins>
<code>
<del class="diff-old">ldp:nextPage
</del>
<ins class="diff-chg">ldp:containerSortOrder
</ins>
</code>
and
<ins class="diff-new">whose
</ins>
object
<del class="diff-old">being
the
URL
for
the
subsequent
page.
5.3.6.3
The
last
page
resource
representation
MUST
have
one
triple
with
the
subject
of
</del>
<ins class="diff-chg">describes
</ins>
the
<del class="diff-old">last
page,
predicate
of
</del>
<ins class="diff-chg">order
used.
LDP
defines
two
values,
</ins>
<code>
<del class="diff-old">ldp:nextPage
</del>
<ins class="diff-chg">ldp:ascending
</ins>
</code>
and
<del class="diff-old">object
being
</del>
<code>
<del class="diff-old">rdf:nil
.
</del>
<ins class="diff-chg">ldp:descending
</ins></code>,<ins class="diff-chg">
for
use
as
the
object
of
this
triple.
Other
values
can
be
used,
but
LDP
assigns
no
meaning
to
them
and
interoperability
will
be
limited.
</ins>
</div>
<div class="ldp-issue-pending">
<div class="ldp-issue-title">
<del class="diff-old">ISSUE-18
</del>
<a href="http://www.w3.org/2012/ldp/track/issues/14">
<ins class="diff-chg">ISSUE-14
</ins>
</a>
</div>
<del class="diff-old">container
membership
and
robust
pagination
</del>
<ins class="diff-chg">Include
clarifications
about
ordering
in
LDPC
representations.
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?
</ins>
</div>
<del class="diff-old">5.3.7
</del>
<div id="ldpc-5_3_5" class="rule">
<ins class="diff-chg">5.3.5
</ins>
LDPC
<del class="diff-old">servers
</del>
<ins class="diff-chg">page
representations
ordered
using
</ins><code><ins class="diff-chg">
ldp:containerSortCriteria
</ins></code>
MAY
<del class="diff-old">represent
the
members
of
a
paged
LDPC
</del>
<ins class="diff-chg">contain,
</ins>
in
<del class="diff-old">a
sequential
order.
The
order
MUST
be
specified
using
the
</del>
<ins class="diff-chg">any
</ins>
<code>
<del class="diff-old">ldp:containerSortPredicates
</del>
<ins class="diff-chg">ldp:containerSortCriterion
</ins>
</code>
<del class="diff-old">predicate
</del>
<ins class="diff-chg">list
entry,
a
triple
</ins>
whose
subject
is
<del class="diff-old">that
of
</del>
the
<del class="diff-old">page
</del>
<ins class="diff-chg">sort
criterion
identifier,
whose
predicate
is
</ins><code><ins class="diff-chg">
ldp:containerSortCollation
</ins></code>
and
<ins class="diff-new">whose
object
identifies
the
collation
used.
LDP
defines
no
values
for
use
as
the
</ins>
object
<del class="diff-old">is
a
list
</del>
of
<del class="diff-old">LDPC
ordinal
predicates.
Ordering
</del>
<ins class="diff-chg">this
triple.
While
it
</ins>
is
<del class="diff-old">only
ascending.
The
only
ordinal
predicate
literal
data
types
supported
</del>
<ins class="diff-chg">better
for
interoperability
to
use
open
standardized
values,
any
value
can
be
used.
When
the
</ins><code><ins class="diff-chg">
ldp:containerSortCollation
</ins></code><ins class="diff-chg">
triple
is
absent
and
the
</ins><a title="page-ordering values"><ins class="diff-chg">
page-ordering
values
</ins></a>
are
<del class="diff-old">those
</del>
<ins class="diff-chg">strings
or
simple
literals
[[!SPARQL-QUERY]],
the
resulting
order
is
</ins>
as
defined
by
SPARQL
SELECT’s
ORDER
BY
clause
<del class="diff-old">[
SPARQL-QUERY
</del>
<ins class="diff-chg">[[!SPARQL-QUERY]]
using
two-argument
</ins><code><ins class="diff-chg">
fn:compare
</ins></code>,<ins class="diff-chg">
that
is,
it
behaves
as
if
</ins><code><ins class="diff-chg">
http://www.w3.org/2005/xpath-functions/collation/codepoint
</ins></code><ins class="diff-chg">
was
the
specified
collation.
When
the
</ins><code><ins class="diff-chg">
ldp:containerSortCollation
</ins></code><ins class="diff-chg">
triple
is
present
and
the
</ins><a title="page-ordering values"><ins class="diff-chg">
page-ordering
values
</ins>
</a>
<del class="diff-old">].
</del>
<ins class="diff-chg">are
strings
or
simple
literals
[[!SPARQL-QUERY]],
the
resulting
order
is
as
defined
by
SPARQL
SELECT’s
ORDER
BY
clause
[[!SPARQL-QUERY]]
using
three-argument
</ins><code><ins class="diff-chg">
fn:compare
</ins></code>,<ins class="diff-chg">
that
is,
the
specified
collation.
When
the
</ins><code><ins class="diff-chg">
ldp:containerSortCollation
</ins></code><ins class="diff-chg">
triple
SHOULD
be
omitted
for
comparisons
involving
</ins><a title="page-ordering values"><ins class="diff-chg">
page-ordering
values
</ins></a><ins class="diff-chg">
for
which
[[!SPARQL-QUERY]]
does
not
use
collations.
</ins></div><div class="ldp-issue-pending">
<div class="ldp-issue-title">
<del class="diff-old">ISSUE-14
</del>
<a href="http://www.w3.org/2012/ldp/track/issues/63">
<ins class="diff-chg">ISSUE-63
</ins>
</a>
</div>
<del class="diff-old">Include
clarifications
about
ordering
in
LDPC
representations
5.3.7.1
The
object
of
ldp:containerSortPredicates
,
the
predicate
used
</del>
<ins class="diff-chg">Need
</ins>
to
<del class="diff-old">indicate
ordering,
MUST
NOT
change
between
subsequent
pages.
If
it
does,
ordering
among
members
of
a
</del>
<ins class="diff-chg">be
able
to
specify
collation
with
</ins>
container
<del class="diff-old">across
pages
is
undefined.
See
section
5.1.4
Ordering
for
additional
details.
</del>
<ins class="diff-chg">ordering.
Drafted
per
2013-06-18
F2F
resolution.
</ins>
</div>
<del class="diff-old">5.4
</del>
</section>
<section>
<h2 id="ldpc-HTTP_POST">
HTTP
POST
</h2>
<p>
This
specification
imposes
the
following
new
requirements
on
HTTP
<code>
POST
</code>
for
LDPCs
only
when
an
LDPC
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
<del class="diff-old">[
HTTP11
]
</del>
<ins class="diff-chg">[[!HTTP11]]
</ins>
makes
it
optional.
</p>
<div id="ldpc-5_4_1" class="rule">
5.4.1
LDPC
clients
SHOULD
create
member
resources
by
submitting
a
representation
as
the
entity
body
of
the
HTTP
<code>
POST
</code>
to
a
known
<del class="diff-old">LDPC
.
</del>
<ins class="diff-chg">LDPC.
If
the
resource
was
created
successfully,
</ins>
LDPC
servers
MUST
respond
with
status
code
201
(Created)
and
the
<code>
Location
</code>
header
set
to
the
new
resource’s
URL.
<ins class="diff-new">Clients
shall
not
expect
any
representation
in
the
response
entity
body
on
a
201
(Created)
response.
</ins>
</div>
<div id="ldpc-5_4_2" class="rule">
5.4.2
After
a
successful
HTTP
<code>
POST
</code>
request
to
a
<del class="diff-old">LDPC
,
</del>
<ins class="diff-chg">LDPC,
</ins>
the
new
resource
MUST
appear
as
a
member
of
the
LDPC
until
the
new
resource
is
deleted
or
removed
by
other
methods.
An
LDPC
MAY
also
contain
resources
that
were
added
through
other
means
-
for
example
through
the
user
interface
of
the
site
that
implements
the
<del class="diff-old">LDPC
.
ISSUE-35
POSTing
to
a
container
MUST
yield
a
fresh
URI
</del>
<ins class="diff-chg">LDPC.
</ins>
</div>
<div id="ldpc-5_4_3" class="rule">
5.4.3
LDPC
servers
MAY
accept
an
HTTP
<code>
POST
</code>
of
<del class="diff-old">non-
RDF
</del>
<ins class="diff-chg">non-RDF
</ins>
representations
for
creation
of
any
kind
of
resource,
for
example
binary
resources.
</div>
<div id="ldpc-5_4_4" class="rule">
5.4.4
For
servers
that
support
create,
LDPC
servers
MUST
create
an
LDPR
from
a
RDF
representation
in
the
request
entity
body.
The
<ins class="diff-chg">newly
created
</ins>
LDPR
could
also
be
a
<del class="diff-old">LDPC
,
</del>
<ins class="diff-chg">LDPC,
</ins>
therefore
servers
may
allow
the
creations
of
LDPCs
within
a
<del class="diff-old">LDPC
.
</del>
<ins class="diff-chg">LDPC.
</ins>
</div>
<div id="ldpc-5_4_5" class="rule">
5.4.5
<del class="diff-old">LDPC
servers
SHOULD
NOT
include
the
representation
of
the
created
resource
in
the
entity
body
of
a
201
(Created)
response.
In
other
words,
clients
should
not
expect
any
representation
in
the
response
entity
body
on
a
201
(Created)
response.
ISSUE-39
HTTP
status
codes
used
for
creation
5.4.6
</del>
LDPC
servers
MUST
accept
a
request
entity
body
with
a
request
header
of
<code>
Content-Type
</code>
with
value
of
<code>
text/turtle
</code>
<del class="diff-old">[
TURTLE
].
</del>
<ins class="diff-chg">[[!TURTLE]].
</ins>
</div>
<del class="diff-old">5.4.7
</del>
<div id="ldpc-5_4_6" class="rule">
<ins class="diff-chg">5.4.6
</ins>
LDPC
servers
SHOULD
use
the
<code>
Content-Type
</code>
request
header
to
determine
the
representation
format
when
the
request
has
an
entity
body.
When
the
header
is
absent,
LDPC
servers
MAY
infer
the
content
type
by
inspecting
the
entity
body
contents
<del class="diff-old">[
HTTP11
].
</del>
<ins class="diff-chg">[[!HTTP11]].
</ins>
</div>
<del class="diff-old">5.4.8
</del>
<div id="ldpc-5_4_7" class="rule">
<ins class="diff-chg">5.4.7
</ins>
In
RDF
representations,
LDPC
servers
MUST
interpret
the
null
relative
URI
for
the
subject
of
triples
in
the
LDPR
representation
in
the
request
entity
body
as
referring
to
the
entity
in
the
request
body.
Commonly,
that
entity
is
the
model
for
the
“to
be
created”
<del class="diff-old">LDPR
,
</del>
<ins class="diff-chg">LDPR,
</ins>
so
triples
whose
subject
is
the
null
relative
URI
will
usually
result
in
triples
in
the
created
resource
whose
subject
is
the
created
resource.
<del class="diff-old">ISSUE-20
Identifying
and
naming
POSTed
resources
</del>
<ins class="diff-chg">&#160;
</ins>
</div>
<del class="diff-old">5.4.9
</del>
<div id="ldpc-5_4_8" class="rule">
<ins class="diff-chg">5.4.8
</ins>
LDPC
servers
SHOULD
assign
the
subject
URI
for
the
resource
to
be
created
using
server
application
specific
<del class="diff-old">rules.
ISSUE-43
hint
at
naming
</del>
<ins class="diff-chg">rules
in
the
absence
of
</ins>
a
<del class="diff-old">resource
on
creation
</del>
<a href="#ldpc-5_4_10">
<ins class="diff-chg">client
hint
</ins></a>.
</div>
<del class="diff-old">5.4.10
</del>
<div id="ldpc-5_4_8_1" class="rule">
<ins class="diff-chg">5.4.8.1
For
RDF
representations,
LDPC
servers
MUST
assign
the
base-URI
for
[[!RFC3987]]
relative-URI
resolution
to
be
the
URI
of
the
created
subject
resource.
</ins></div><div id="ldpc-5_4_9" class="rule"><ins class="diff-chg">
5.4.9
</ins>
LDPC
servers
SHOULD
allow
clients
to
create
new
resources
without
requiring
detailed
knowledge
of
application-specific
constraints.
This
is
a
consequence
of
the
requirement
to
<a href="#ldpr-4_1_9">
enable
simple
creation
and
modification
</a>
of
LPDRs.
</div>
<div id="ldpc-5_4_10" class="rule">
<ins class="diff-new">5.4.10
LDPC
servers
MAY
allow
clients
to
suggest
the
URI
for
a
resource
created
through
</ins><code><ins class="diff-new">
POST
</ins></code>,<ins class="diff-new">
using
the
HTTP
</ins><code><ins class="diff-new">
Slug
</ins></code><ins class="diff-new">
header
as
defined
in
[[!RFC5023]].
LDP
adds
no
new
requirements
to
this
usage,
so
its
presence
functions
as
a
client
hint
to
the
server
providing
a
desired
string
to
be
incorporated
into
the
server's
final
choice
of
resource
URI.
</ins></div><div id="ldpc-5_4_11" class="rule"><ins class="diff-new">
5.4.11
LDPC
servers
that
allow
member
creation
via
</ins><code><ins class="diff-new">
POST
</ins></code><ins class="diff-new">
SHOULD
NOT
re-use
URIs,
per
the
</ins><a href="#ldpc-5_2_9"><ins class="diff-new">
general
requirements
on
LDPCs
</ins></a>.
</div>
<div id="ldpc-5_4_12" class="rule">
<ins class="diff-chg">5.4.12
Upon
successful
creation
of
a
non-RDF
and
therefore
non-LDPR
member
(HTTP
status
code
of
201-Created
and
URI
indicated
by
</ins><code><ins class="diff-chg">
Location
</ins></code><ins class="diff-chg">
response
header),
LDPC
servers
MAY
create
an
associated
LDPR
to
contain
data
about
the
created
resource.
If
an
LDPC
server
creates
this
associated
LDPR
it
MUST
indicate
its
location
on
the
HTTP
response
using
the
HTTP
response
header
</ins><code><ins class="diff-chg">
Link
</ins></code><ins class="diff-chg">
and
relationship
type
</ins><code><ins class="diff-chg">
meta
</ins></code><ins class="diff-chg">
and
</ins><code><ins class="diff-chg">
href
</ins></code><ins class="diff-chg">
to
be
the
URI
of
the
meta-resource
[[!RFC5988]].
</ins></div><div class="ldp-issue-pending"><div class="ldp-issue-title">
<del class="diff-old">5.5
</del>
<a href="http://www.w3.org/2012/ldp/track/issues/80">
<ins class="diff-chg">ISSUE-80
</ins></a></div><ins class="diff-chg">
How
does
a
client
know
which
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
requests
create
new
resources.
</ins><p><ins class="diff-chg">
Note
from
editor:
the
MUST
here
keeps
this
aligned
with
what
we
decided
for
OPTIONS
on
PATCH;
in
both
cases
the
header
registration
says
SHOULD,
and
the
LDP
spec
says
MUST.
What
makes
that
look
a
bit
odd
is
that
in
the
Accept-Post
case,
the
registration
and
LDP
are
the
same
document.
Thus
I
added
informative
text
here
explicitly
talking
to
the
apparent
discrepancy.
</ins></p></div><div id="ldpr-5_4_13" class="rule"><ins class="diff-chg">
5.4.13
LDPR
servers
that
support
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
MUST
include
an
</ins><a href="#header-accept-post"><code><ins class="diff-chg">
Accept-Post
</ins></code><ins class="diff-chg">
response
header
</ins></a><ins class="diff-chg">
on
HTTP
</ins><code><ins class="diff-chg">
OPTIONS
</ins></code><ins class="diff-chg">
responses,
listing
post
document
media
type(s)
supported
by
the
server.
LDP
only
specifies
the
use
of
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
for
the
purpose
of
creating
new
resources,
but
a
server
can
accept
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
requests
with
other
semantics.
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
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
request
will
result
in
the
creation
of
a
new
resource;
they
must
rely
on
out
of
band
information
for
knowledge
of
which
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
requests,
if
any,
will
have
the
"create
new
resource"
semantic.
This
requirement
on
LDP
servers
is
intentionally
stronger
than
the
one
levied
in
the
</ins><a href="#header-accept-post"><ins class="diff-chg">
header
registration
</ins></a><ins class="diff-chg">
;
it
is
unrealistic
to
expect
all
existing
resources
that
support
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
to
suddenly
return
a
new
header
or
for
all
new
specifications
constraining
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
to
be
aware
of
its
existence
and
require
it,
but
it
is
a
reasonable
requirement
for
new
specifications
such
as
LDP.
</ins></div><div class="ldp-issue-pending"><div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/79"><ins class="diff-chg">
ISSUE-79
</ins></a></div><ins class="diff-chg">
ldp:contains
</ins></div><div id="ldpr-5_4_14" class="rule"><ins class="diff-chg">
5.4.14
LDPCs
that
create
new
member
resources
MAY
add
triples
to
the
container
as
part
of
member
creation
to
reflect
its
factory
role.
LDP
defines
the
</ins><code><ins class="diff-chg">
ldp:contains
</ins></code><ins class="diff-chg">
predicate
for
this
purpose.
An
LDPC
that
tracks
members
created
through
the
LDPC
MUST
add
a
triple
whose
subject
is
the
container's
URI,
whose
predicate
is
</ins><code><ins class="diff-chg">
ldp:contains
</ins></code>,<ins class="diff-chg">
and
whose
object
is
the
newly
created
member
resource's
URI;
it
MAY
add
other
triples
as
well.
</ins></div></section><section><h2 id="ldpc-HTTP_PUT">
HTTP
PUT
</h2>
<p>
This
specification
imposes
the
following
new
requirements
on
HTTP
<code>
PUT
</code>
for
LDPCs
only
when
an
LDPC
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
<del class="diff-old">[
HTTP11
]
</del>
<ins class="diff-chg">[[!HTTP11]]
</ins>
makes
it
optional.
</p>
<div id="ldpc-5_5_1" class="rule">
5.5.1
LDPC
servers
SHOULD
NOT
allow
HTTP
<code>
PUT
</code>
to
update
a
<del class="diff-old">LDPC
’s
</del>
<ins class="diff-chg">LDPC’s
</ins>
members;
if
the
server
receives
such
a
request,
it
SHOULD
respond
with
a
409
(Conflict)
status
code.
</div>
<div id="ldpc-5_5_2" class="rule">
5.5.2
LDPC
servers
MAY
allow
updating
LDPC
non-membership
properties
using
HTTP
<code>
PUT
</code>
on
<del class="diff-old">&lt;containerURL&gt;?non-member-properties
,
</del>
<ins class="diff-chg">a
corresponding
</ins><a><ins class="diff-chg">
non-member
resource
</ins></a>,
which
MAY
exclude
server-managed
properties
such
as
<code>
ldp:membershipSubject
</code>,
<code>
<ins class="diff-new">ldp:membershipPredicate
</ins>
</code>
and
<code>
<del class="diff-old">ldp:membershipPredicate
</del>
<ins class="diff-chg">ldp:membershipPredicateInverse
</ins>
</code>.
<ins class="diff-new">Section
</ins><a href="#ldpc-5_7_1"><ins class="diff-new">
5.7.1
HTTP
HEAD
</ins></a><ins class="diff-new">
describes
the
process
by
which
clients
discover
whether
the
server
offers
such
a
resource,
and
if
so
its
URL.
</ins></div><div id="ldpc-5_5_3" class="rule"><ins class="diff-new">
5.5.3
LDPC
servers
SHOULD
NOT
allow
HTTP
</ins><code><ins class="diff-new">
PUT
</ins></code><ins class="diff-new">
requests
with
member
information
in
the
request
representation.
See
section
</ins><a href="#ldpc-member_data"><ins class="diff-new">
5.1.1
Container
Member
Information
</ins></a><ins class="diff-new">
for
additional
details.
</ins>
</div>
<div id="ldpc-5_5_4" class="rule">
<ins class="diff-new">5.5.4
LDPC
servers
that
allow
member
creation
via
</ins><code><ins class="diff-new">
PUT
</ins></code><ins class="diff-new">
SHOULD
NOT
re-use
URIs,
per
the
</ins><a href="#ldpc-5_2_9"><ins class="diff-new">
general
requirements
on
LDPCs
</ins></a>.
</div>
<del class="diff-old">5.6
</del>
</section>
<section>
<h2 id="ldpc-HTTP_DELETE">
HTTP
DELETE
</h2>
<p>
This
specification
imposes
the
following
new
requirements
on
HTTP
<code>
DELETE
</code>
for
LDPRs
only
when
a
LDPC
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
<del class="diff-old">[
HTTP11
]
</del>
<ins class="diff-chg">[[!HTTP11]]
</ins>
makes
it
optional.
</p>
<div id="ldpc-5_6_1" class="rule">
5.6.1
When
a
LDPC
member
resource
originally
created
by
the
LDPC
(for
example,
one
<ins class="diff-new">whose
representation
was
HTTP
</ins><code><ins class="diff-new">
POST
</ins></code><ins class="diff-new">
'd
to
the
LDPC
and
then
</ins>
referenced
by
a
membership
triple)
is
deleted,
and
the
LDPC
server
is
aware
of
the
member's
deletion
(for
example,
the
member
is
managed
by
the
same
server),
the
LDPC
server
MUST
also
remove
it
from
the
LDPC
by
removing
the
corresponding
membership
triple.
</div>
<div id="ldpc-5_6_2" class="rule">
5.6.2
When
the
LDPC
<del class="diff-old">includes
an
</del>
<ins class="diff-chg">server
successfully
completes
the
</ins>
<code>
<del class="diff-old">rdf:type
</del>
<ins class="diff-chg">DELETE
</ins>
</code>
<del class="diff-old">predicate
</del>
<ins class="diff-chg">request
on
a
LDPC,
it
MUST
remove
any
membership
triples
associated
</ins>
with
<del class="diff-old">an
object
of
ldp:AggregateContainer
,
</del>
the
<ins class="diff-new">LDPC
as
indicated
by
the
canonical
</ins><code><ins class="diff-new">
Request-URI
</ins></code>.<ins class="diff-new">
The
LDPC
</ins>
server
MAY
<del class="diff-old">also
delete
</del>
<ins class="diff-chg">perform
additional
removal
of
member
resources.
For
example,
</ins>
the
<ins class="diff-new">server
could
perform
additional
cleanup
tasks
for
</ins>
resources
<del class="diff-old">that
</del>
<ins class="diff-chg">it
knows
</ins>
are
<ins class="diff-new">no
longer
</ins>
referenced
<del class="diff-old">as
its
contents.
The
LDPC
membership
triple
MUST
also
be
updated
as
defined
by
5.6.1
</del>
<ins class="diff-chg">or
have
not
been
accessed
for
some
period
of
time.
</ins></div><div class="ldp-issue-pending"><div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/79"><ins class="diff-chg">
ISSUE-79
</ins>
</a>
<del class="diff-old">above.
</del>
</div>
<ins class="diff-chg">ldp:contains
</ins></div><div id="ldpc-5_6_3" class="rule">
5.6.3
When
the
<ins class="diff-chg">conditions
in
</ins><a href="#ldpc-5_6_1"><ins class="diff-chg">
5.6.1
</ins></a><ins class="diff-chg">
hold,
and
the
</ins>
LDPC
<del class="diff-old">includes
an
</del>
<ins class="diff-chg">tracks
member
resources
that
it
created
using
the
</ins>
<code>
<del class="diff-old">rdf:type
</del>
<ins class="diff-chg">ldp:contains
</ins>
</code>
<del class="diff-old">predicate
with
an
object
of
ldp:CompositeContainer
,
</del>
<ins class="diff-chg">predicate,
</ins>
the
<ins class="diff-new">LDPC
</ins>
server
MUST
also
<del class="diff-old">delete
</del>
<ins class="diff-chg">remove
</ins>
the
<del class="diff-old">resources
that
are
referenced
as
its
contents.
The
LDPC
membership
triple
MUST
also
be
updated
as
defined
by
5.6.1
above.
ISSUE-28
</del>
<ins class="diff-chg">deleted
member's
</ins><code><ins class="diff-chg">
ldp:contains
</ins></code><ins class="diff-chg">
triple.
</ins>
</div>
<del class="diff-old">transaction/rollback
when
deleting
resources
from
</del>
<div id="ldpc-5_6_4" class="rule">
<ins class="diff-chg">5.6.4
When
</ins>
a
LDPC
<del class="diff-old">.
note
also
that
5.6.2's
reminder
about
5.6.1
is
only
sensible
if
there
is
no
transactional
behavior
in
</del>
<ins class="diff-chg">member
resource
originally
created
by
</ins>
the
<del class="diff-old">recursive
delete.
in
</del>
<ins class="diff-chg">LDPC
(for
example,
one
whose
representation
was
HTTP
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
'd
to
</ins>
the
<del class="diff-old">case
where
</del>
<ins class="diff-chg">LDPC
and
then
referenced
by
a
membership
triple)
is
deleted,
and
</ins>
the
<del class="diff-old">only
observable
results
are
all/nothing,
</del>
<ins class="diff-chg">LDPC
server
created
an
associated
LDPR
(see
</ins><a href="#ldpc-5_4_12"><ins class="diff-chg">
5.4.12
</ins></a><ins class="diff-chg">
),
</ins>
the
<del class="diff-old">reminder's
effect
is
unobservable.
</del>
<ins class="diff-chg">LDPC
server
must
also
remove
the
associated
LDPR
it
created.
</ins>
</div>
<del class="diff-old">5.7
</del>
</section>
<section>
<h2 id="ldpc-HTTP_HEAD">
HTTP
HEAD
</h2>
<p>
<del class="diff-old">There
are
no
additional
requirements
</del>
<ins class="diff-chg">Note
that
certain
LDP
mechanisms,
such
as
paging,
rely
</ins>
on
HTTP
<del class="diff-old">HEAD.
</del>
<ins class="diff-chg">headers,
and
HTTP
generally
requires
that
</ins><code><ins class="diff-chg">
HEAD
</ins></code><ins class="diff-chg">
responses
include
the
same
headers
as
</ins><code><ins class="diff-chg">
GET
</ins></code><ins class="diff-chg">
responses.
Also
LDPR
servers
must
also
include
HTTP
headers
on
response
to
</ins><code><ins class="diff-chg">
OPTIONS
</ins></code>,<ins class="diff-chg">
see
</ins><a href="#ldpr-4_6_2"><ins class="diff-chg">
4.6.2
</ins></a>.<ins class="diff-chg">
Thus,
implementers
supporting
</ins><code><ins class="diff-chg">
HEAD
</ins></code><ins class="diff-chg">
should
also
carefully
read
the
</ins><a href="#ldpc-HTTP_GET" class="sectionRef">
<del class="diff-old">5.8
</del>
</a>
<ins class="diff-chg">and
</ins><a href="#ldpc-HTTP_OPTIONS" class="sectionRef"></a>.</p></section><section><h2 id="ldpc-HTTP_PATCH">
HTTP
PATCH
</h2>
<p>
This
specification
imposes
the
following
new
requirements
on
HTTP
<code>
PATCH
</code>
for
LDPCs
only
when
a
LDPC
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
<del class="diff-old">[
HTTP11
]
</del>
<ins class="diff-chg">[[!HTTP11]]
</ins>
makes
it
optional.
</p>
<div id="ldpc-5_8_1" class="rule">
5.8.1
LDPC
servers
are
RECOMMENDED
to
support
HTTP
<code>
PATCH
</code>
as
the
preferred
method
for
updating
LDPC
non-membership
properties.
</div>
</section>
<section>
<h2 id="ldpc-HTTP_OPTIONS">
<ins class="diff-new">HTTP
OPTIONS
</ins></h2><p><ins class="diff-new">
This
specification
imposes
the
following
new
requirements
on
HTTP
</ins><code><ins class="diff-new">
OPTIONS
</ins></code><ins class="diff-new">
for
LDPCs.
</ins></p><div id="ldpc-5_9_1" class="rule"><ins class="diff-new">
5.9.1
LDPC
servers
SHOULD
define
a
corresponding
</ins><a><ins class="diff-new">
non-member
resource
</ins></a><ins class="diff-new">
to
support
requests
for
information
about
a
LDPC
without
retrieving
a
full
representation
including
all
of
its
members;
see
section
</ins><a href="#ldpc-get_non-member_props"><ins class="diff-new">
5.1.2
Retrieving
Only
Non-member
Properties
</ins></a><ins class="diff-new">
for
examples.
In
responses
to
</ins><code><ins class="diff-new">
OPTIONS
</ins></code><ins class="diff-new">
requests
with
an
LDPC
as
the
</ins><code><ins class="diff-new">
Request-URI
</ins></code>,<ins class="diff-new">
LDPC
servers
that
define
a
non-member
resource
SHOULD
provide
an
HTTP
</ins><code><ins class="diff-new">
Link
</ins></code><ins class="diff-new">
header
whose
target
URI
is
the
</ins><a><ins class="diff-new">
non-member
resource
</ins></a>,<ins class="diff-new">
and
whose
link
relation
type
is
</ins><code><ins class="diff-new">
http://www.w3.org/ns/ldp#non-member-resource
</ins></code><ins class="diff-new">
[[!RFC5988]].
This
is
the
mechanism
by
which
clients
discover
the
URL
of
the
non-member
resource.
If
no
such
</ins><code><ins class="diff-new">
Link
</ins></code><ins class="diff-new">
header
is
present,
then
conservative
clients
will
assume
that
the
LDPC
does
not
have
a
corresponding
non-member
resource.
For
example,
if
there
is
a
LDPC
with
URL
</ins><code><ins class="diff-new">
&lt;containerURL&gt;
</ins></code><ins class="diff-new">
whose
corresponding
non-member
resource
URL
is
</ins><code><ins class="diff-new">
&lt;containerURL&gt;?nonMemberProperties
</ins></code>,<ins class="diff-new">
then
the
corresponding
link
header
would
be
</ins><code><ins class="diff-new">
Link:
&lt;?nonMemberProperties&gt;;rel="http://www.w3.org/ns/ldp#non-member-resource"
</ins></code>
</div>
<div id="ldpc-5_9_2" class="rule">
<ins class="diff-chg">5.9.2
When
a
LDPC
creates
a
non-LDPR
(e.g.
binary)
member
(for
example,
one
whose
representation
was
HTTP
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
'd
to
the
LDPC
and
then
referenced
by
a
membership
triple)
it
might
create
an
associated
LDPR
to
contain
data
about
the
non-LDPR
(see
</ins><a href="#ldpc-5_4_12"><ins class="diff-chg">
5.4.12
</ins></a><ins class="diff-chg">
).
For
non-LDPRs
that
have
this
associated
LDPR,
an
LDPC
server
MUST
provide
an
HTTP
</ins><code><ins class="diff-chg">
Link
</ins></code><ins class="diff-chg">
header
whose
target
URI
is
the
associated
LDPR,
and
whose
link
relation
type
is
</ins><code><ins class="diff-chg">
meta
</ins></code><ins class="diff-chg">
[[!RFC5988]].
</ins></div></section><section><h2 id="ldpc-inlining"><ins class="diff-chg">
Member
Inlining:
Returning
All
of
a
Container
Page's
Members
in
a
Response
</ins></h2><div class="atrisk"><p class="atrisktext"><ins class="diff-chg">
Feature
At
Risk
</ins></p><p><ins class="diff-chg">
The
LDP
Working
Group
proposes
incorporation
of
the
features
described
in
this
section.
</ins></p><ul><li><ins class="diff-chg">
The
addition
of
</ins><a><ins class="diff-chg">
resource
inlining
</ins></a><ins class="diff-chg">
to
save
application
latency
and
server/network
load
in
controlled
environments.
</ins></li></ul><p><ins class="diff-chg">
Feedback,
both
positive
and
negative,
is
invited
by
sending
email
to
the
mailing
list
in
</ins><a href="#sotd"><ins class="diff-chg">
Status
of
This
Document
</ins></a>.</p></div><section class="informative"><h3 id="ldpc-InliningIntro"><ins class="diff-chg">
Introduction
</ins></h3><p><ins class="diff-chg">
One
of
the
most
commonly
cited
scenarios
for
resource
inlining
is
to
save
clients
enumerating
a
container
of
</ins><i><ins class="diff-chg">
m
</ins></i><ins class="diff-chg">
members
from
having
to
perform
</ins><i><ins class="diff-chg">
m+1
</ins></i><ins class="diff-chg">
HTTP
requests
(or
</ins><i><ins class="diff-chg">
m+p
</ins></i>,<ins class="diff-chg">
if
the
container
is
paged
into
</ins><i><ins class="diff-chg">
p
</ins></i><ins class="diff-chg">
pages).
The
desire
is
to
allow
the
server
to
reduce
the
number
of
HTTP
round-trips
by
returning
some
(perhaps
all)
members'
content
as
part
of
the
container's
representation.
In
addition
to
the
general
</ins><a><ins class="diff-chg">
resource
inlining
</ins></a><ins class="diff-chg">
mechanism
useful
in
cases
where
only
a
subset
of
the
members'
content
is
inlined,
LDP
also
provides
a
predicate
for
the
special
case
where
</ins><i><ins class="diff-chg">
all
</ins></i><ins class="diff-chg">
of
a
container's
or
page's
members
are
inlined.
Rather
than
forcing
the
server
to
add
a
triple
for
each
inlined
member,
forcing
clients
to
compare
the
list
of
inlined
members
against
the
set
of
members
in
the
representation,
and
enlarging
the
representation
needlessly,
a
single
triple
can
be
used.
This
is
called
</ins><a><ins class="diff-chg">
member
inlining
</ins></a>.</p><p><ins class="diff-chg">
LDP
does
not
provide
clients
with
any
way
to
detect
whether
or
not
the
server
is
capable
of
resource
inlining
(all
its
resources
or
any
specific
resource),
nor
does
it
provide
clients
with
any
way
to
influence
which
(if
any)
resources
are
inlined
in
any
given
response.
</ins></p><div class="ldp-issue-pending">
<div class="ldp-issue-title">
<del class="diff-old">ISSUE-7
</del>
<a href="http://www.w3.org/2012/ldp/track/issues/58">
<ins class="diff-chg">ISSUE-58
</ins>
</a>
</div>
<del class="diff-old">What
operations
are
permitted
</del>
<ins class="diff-chg">Action
87:
Add
an
informative
section
</ins>
on
<ins class="diff-new">the
possible
dangers
of
inlining
resources
</ins></div><p><ins class="diff-new">
The
inlining
building
blocks
LDP
provides
can
only
be
safely
used
if
certain
assumptions
hold.
This
is
no
less
true
for
</ins>
containers
<ins class="diff-new">than
for
LDPRs
in
general.
See
the
general
</ins><a href="#ldpr-InliningWarnings"><ins class="diff-new">
cautions
on
resource
inlining
</ins></a>.</p></section><section><h3 id="ldpc-InliningGET"><ins class="diff-new">
HTTP
GET
</ins></h3><p><ins class="diff-new">
In
addition
to
the
requirements
set
forth
in
other
sections,
LDPC
servers
that
support
</ins><a><ins class="diff-new">
member
inlining
</ins></a>,
and
<del class="diff-old">how
</del>
<ins class="diff-chg">LDP
clients
aware
of
the
same
facility,
must
also
follow
the
requirements
in
this
section.
</ins></p><div class="ldp-issue-pending"><div class="ldp-issue-title"><a href="http://www.w3.org/2012/ldp/track/issues/58"><ins class="diff-chg">
ISSUE-58
</ins></a></div><ins class="diff-chg">
Action
88:
Add
a
property
ldp:membersInlined
true/false.
The
default
(if
not
specified)
is
false.
If
true,
it
means
that
a
complete
description
of
all
members
[on
the
current
page]
are
inlined
with
the
container
document
[or
page],
and
therefore
clients
SHOULD
NOT
</ins>
do
<code>
<ins class="diff-new">GET
</ins></code><ins class="diff-new">
on
the
member
URIs
to
retrieve
additional
triples.
marked
as
AT
RISK.
</ins></div><div id="ldpc-5_10_2_1" class="rule"><ins class="diff-new">
5.10.2.1
LDPC
representations
that
are
</ins><a title="member inlining"><ins class="diff-new">
member
inlined
</ins></a><ins class="diff-new">
MUST
include
a
</ins><code><ins class="diff-new">
ldp:Page
</ins></code><ins class="diff-new">
resource
in
the
representation,
whether
or
not
the
representation
contains
multiple
pages,
as
described
in
</ins><a href="#ldpr-4_10_3_1"><ins class="diff-new">
section
4.10.3.1
</ins></a>.<ins class="diff-new">
In
addition
to
satisfying
those
requirements,
the
representation
MUST
contain
a
triple
whose
subject
is
the
</ins><code><ins class="diff-new">
ldp:Page
</ins></code><ins class="diff-new">
resource
URI,
whose
predicate
is
</ins><code><ins class="diff-new">
ldp:membersInlined
</ins></code>,<ins class="diff-new">
and
whose
object
is
</ins><code><ins class="diff-new">
true
</ins></code>.<ins class="diff-new">
This
is
means
by
which
the
server
communicates
to
LDP
clients
that
</ins>
they
<del class="diff-old">get
invoked?
</del>
<ins class="diff-chg">can
avoid
HTTP
</ins><code><ins class="diff-chg">
GET
</ins></code><ins class="diff-chg">
requests
for
the
members
listed
on
the
page.
</ins></div><div id="ldpc-5_10_2_2" class="rule"><ins class="diff-chg">
5.10.2.2
LDPC
clients
SHOULD
avoid
making
HTTP
</ins><code><ins class="diff-chg">
GET
</ins></code><ins class="diff-chg">
requests
against
any
members
in
a
LDPC
representation
containing
a
</ins><code><ins class="diff-chg">
ldp:Page
</ins></code><ins class="diff-chg">
resource
with
the
triple
described
in
</ins><a href="#ldpc-5_10_2_1"><ins class="diff-chg">
section
5.10.2.1
</ins></a>,<ins class="diff-chg">
unless
there
are
application-specific
reasons
for
doing
so.
Clients
should
note
that
by
the
time
the
representation
is
received,
the
actual
state
of
inlined
members
may
have
changed
due
to
subsequent
requests.
</ins>
</div>
<div id="ldpc-5_10_2_3" class="rule">
<ins class="diff-new">5.10.2.3
LDPC
clients
MUST
NOT
assume
that
LDPC
representations
lacking
a
</ins><code><ins class="diff-new">
ldp:Page
</ins></code><ins class="diff-new">
resource
or
lacking
the
triple
described
in
</ins><a href="#ldpc-5_10_2_1"><ins class="diff-new">
section
5.10.2.1
</ins></a><ins class="diff-new">
contain
all
the
triples
for
all
members
listed
in
the
representation.
The
representation
might
in
fact
contain
all
those
triples,
or
some
subset
of
them,
that
might
or
might
not
be
completely
adequate
for
the
client's
intended
usage,
but
an
LDP
client
has
no
way
to
discern
from
such
a
representation
which
interpretation
is
accurate.
</ins>
</div>
<del class="diff-old">A.
Acknowledgements
</del>
</section>
</section>
</section>
<section>
<h1>
<ins class="diff-chg">HTTP
Header
Definitions
</ins></h1><section><h2 id="header-accept-post"><ins class="diff-chg">
The
Accept-Post
Response
Header
</ins>
</h2>
<div class="ldp-issue-pending">
<div class="ldp-issue-title">
<a href="http://www.w3.org/2012/ldp/track/issues/80">
<ins class="diff-chg">ISSUE-80
</ins></a>
</div>
<ins class="diff-chg">How
does
a
client
know
which
POST
requests
create
new
resources
</ins></div><p>
This
<del class="diff-old">section
</del>
<ins class="diff-chg">specification
introduces
a
new
HTTP
response
header
</ins><code><ins class="diff-chg">
Accept-Post
</ins></code><ins class="diff-chg">
used
to
specify
the
document
formats
accepted
by
the
server
on
HTTP
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
requests.
It
</ins>
is
<del class="diff-old">non-normative.
</del>
<ins class="diff-chg">modeled
after
the
</ins><code><ins class="diff-chg">
Accept-Patch
</ins></code><ins class="diff-chg">
header
defined
in
[[!RFC5789]].
</ins></p><div id="header-accept-post-1" class="rule"><ins class="diff-chg">
6.1.1
The
syntax
for
</ins><code><ins class="diff-chg">
Accept-Post
</ins></code>,<ins class="diff-chg">
using
the
ABNF
syntax
defined
in
Section
2.1
of
[[!HTTP11]],
is:
</ins><blockquote>
<code>
<ins class="diff-new">Accept-Post
=
"Accept-Post"
":"
1#media-type
</ins></code><p><ins class="diff-new">
The
</ins><code><ins class="diff-new">
Accept-Post
</ins></code><ins class="diff-new">
header
specifies
a
comma-separated
list
of
media-
types
(with
optional
parameters)
as
defined
by
[[!HTTP11]],
Section
3.7.
</ins></p></blockquote></div><div id="header-accept-post-2" class="rule"><ins class="diff-new">
6.1.2
The
</ins><code><ins class="diff-new">
Accept-Post
</ins></code><ins class="diff-new">
HTTP
header
SHOULD
appear
in
the
</ins><code><ins class="diff-new">
OPTIONS
</ins></code><ins class="diff-new">
response
for
any
resource
that
supports
the
use
of
the
</ins><code><ins class="diff-new">
POST
</ins></code><ins class="diff-new">
method.
The
presence
of
the
</ins><code><ins class="diff-new">
Accept-Post
</ins></code><ins class="diff-new">
header
in
response
to
any
method
is
an
implicit
indication
that
</ins><code><ins class="diff-new">
POST
</ins></code><ins class="diff-new">
is
allowed
on
the
resource
identified
by
the
</ins><code><ins class="diff-new">
Request-URI
</ins></code>.<ins class="diff-new">
The
presence
of
a
specific
document
format
in
this
header
indicates
that
that
specific
format
is
allowed
on
</ins><code><ins class="diff-new">
POST
</ins></code><ins class="diff-new">
requests
to
the
resource
identified
by
the
</ins><code><ins class="diff-new">
Request-URI
</ins></code>.</div><div id="header-accept-post-iana" class="rule"><ins class="diff-new">
6.1.3
IANA
Registration
Template
</ins></div><div><blockquote><p><ins class="diff-new">
The
Accept-Post
response
header
must
be
added
to
the
permanent
registry
(see
[[!RFC3864]]).
</ins>
</p>
<p>
<ins class="diff-new">Header
field
name:
Accept-Post
</ins></p><p><ins class="diff-new">
Applicable
Protocol:
HTTP
</ins></p><p><ins class="diff-new">
Author/Change
controller:
W3C
</ins></p><p><ins class="diff-new">
Specification
document:
this
specification
</ins></p></blockquote></div></section></section><section class='appendix informative'><h2><ins class="diff-new">
Acknowledgements
</ins></h2><p>
The
following
people
have
been
instrumental
in
providing
thoughts,
feedback,
reviews,
content,
criticism
and
input
in
the
creation
of
this
specification:
</p>
<p style="margin-left: 3em;">
<del class="diff-old">Arnaud
Le
Hors,
Erik
Wilde,
</del>
Tim
Berners-Lee,
Steve
Battle,
Olivier
Berger,
Alexandre
Bertails,
<ins class="diff-new">Reza
B'Far,
Cody
Burleson,
</ins>
Richard
Cyganiak,
Raúl
García
Castro,
<ins class="diff-new">Miguel
Esteban
Gutiérrez,
</ins>
Sandro
Hawke,
Kingsley
Idehen,
Yves
Lafon,
<ins class="diff-new">Arnaud
Le
Hors,
</ins>
Antonis
Loizou,
Ashok
Malhota,
Roger
Menday,
Nandana
Mihindukulasooriya,
Kevin
Page,
Eric
Prud'hommeaux,
Andy
Seaborne,
<ins class="diff-new">Steve
Speicher,
</ins>
Henry
Story,
Ted
Thibodeau,
Bart
van
Leeuwen,
<ins class="diff-new">Miel
Vander
Sande,
</ins>
Ruben
Verborgh,
<ins class="diff-new">Serena
Villata,
Erik
Wilde,
</ins>
David
Wood,
Martin
P.
Nally
</p>
<del class="diff-old">B.
</del>
</section>
<section class='appendix informative' id="history">
<h1>
Change
History
</h1>
<p>
<del class="diff-old">This
section
</del>
<ins class="diff-chg">The
change
history
</ins>
is
<del class="diff-old">non-normative.
</del>
<ins class="diff-chg">up
to
the
editors
to
insert
a
brief
summary
of
changes,
ordered
by
most
recent
changes
first
and
with
heading
from
which
public
draft
it
has
been
changed
from.
</ins>
</p>
<ul>
<li>
<ins class="diff-chg">2013-07-11
-
Removed
4.1.5,
section
number
fixup:4.1.8-13-&gt;6-11,
4.9.2.*
fixup,
5.3.7-10-&gt;&gt;2-5
(SS)
</ins></li><li><ins class="diff-chg">
2013-07-11
-
Removed
all
stubbed
out
sections
5.1.3,
5.3.2-6
(SS)
</ins></li><li><ins class="diff-chg">
2013-07-11
-
Various
editorial
clean
up
items
from
editor
todo
list
(SS)
</ins></li><li><ins class="diff-chg">
2013-07-11
-
Removed
closed
issues
that
required
no
new
spec
changes:
50,
56,
16,
19,
17
(SS)
</ins></li><li><ins class="diff-chg">
2013-07-11
-
ISSUE-51
Added
how
a
LDPR
can
show
which
LDPC
is
it
in
(SS)
</ins></li><li><ins class="diff-chg">
2013-07-10
-
Removed
closed
issues
that
required
no
new
spec
changes:
18,
35,
20
(SS)
</ins></li><li><ins class="diff-chg">
2013-07-10
-
ISSUE-44
move
section
4.1.7
(relationships
are
simple
RDF
links)
to
guidance
(SS)
</ins></li><li><ins class="diff-chg">
2013-07-10
-
ISSUE-72
take
2
-
added
ldp:MemberSubject
to
handle
default
case
(SS)
</ins></li><li><ins class="diff-chg">
2013-07-10
-
ISSUE-72
adding
5.2.10
for
ldp:membershipObject
(SS)
</ins></li><li><ins class="diff-chg">
2013-07-09
-
ISSUE-58
inlining
-
actions
87-89
inclusive
(JA)
</ins></li><li><ins class="diff-chg">
2013-07-08
-
Moved
5.7.*
sections
out
of
HEAD
and
into
OPTIONS
as
5.9.*,
added
4.6.2
(SS)
</ins></li><li><ins class="diff-chg">
2013-07-08
-
ISSUE-15
Inserted
5.4.12,
5.6.4,
5.7.2
to
describe
link-relation
meta
usage
(SS)
</ins></li><li><ins class="diff-chg">
2013-07-08
-
ISSUE-79
ldp:contains
(JA)
</ins></li><li><ins class="diff-chg">
2013-07-08
-
ISSUE-80
Accept-Post
(JA)
</ins></li><li><ins class="diff-chg">
2013-07-08
-
ISSUE-32
Must
support
options
(JA)
</ins></li><li><ins class="diff-chg">
2013-07-08
-
ISSUE-78
No
client
inferencing
(JA)
</ins></li><li><ins class="diff-chg">
2013-07-08
-
ISSUE-77
Move
"must
have
rdf:type
explicitly"
to
Best
Practices
(JA)
</ins></li><li><ins class="diff-chg">
2013-07-08
-
ISSUE-57
Knowing
it's
an
LDP
server
(JA)
</ins></li><li><ins class="diff-chg">
2013-07-01
-
ISSUE-33
Moved
5.1.3
Paging
(LDPC)
to
4.8
(LDPR)
(SS)
</ins></li><li><ins class="diff-chg">
2013-06-18
-
ISSUE-75
5.2.5
membershipxxx
predicates
required,
per
2013-06-18
F2F
resolution
(JA)
</ins></li><li><ins class="diff-chg">
2013-06-18
-
ISSUE-63
End
of
5.3
+
example
rewritten
for
2013-06-18
F2F
resolution
(JA)
</ins></li><li><ins class="diff-chg">
2013-06-15
-
ISSUE-14
End
of
5.3
+
example
rewritten
for
ascending/descending
sorts
with
optional
collation
(JA)
</ins></li><li><ins class="diff-chg">
2013-06-13
-
ISSUE-54
New
5.4.8.1
to
set
base
URI
on
create
for
relative
URI
resolution
(SS)
</ins></li><li><ins class="diff-chg">
2013-06-10
-
ISSUE-74
4.4.2
require
428
Condition
Required
status
code
when
appropriate;
SS
adding
6585
to
biblio
(JA)
</ins></li><li><ins class="diff-chg">
2013-06-05
-
ISSUE-64
Remove
?non-member-properties;
5.1.2,
5.3.2,
5.5.2
(JA)
</ins></li><li><ins class="diff-chg">
2013-05-21
-
ISSUE-35
Re-use
of
URIs
on
create;
5.2.9,
5.4.11,
5.5.4
(JA)
</ins></li><li><ins class="diff-chg">
2013-05-21
-
ISSUE-43
Slug
in
LDPC
POSTs;
5.4.8,
5.4.10
(JA)
</ins></li><li><ins class="diff-chg">
2013-05-21
-
ISSUE-65
Remove
firstPage
in
favor
of
Link
rel=first,
mostly
hits
5.3.3/5.3.4
(JA)
</ins></li><li><ins class="diff-chg">
2013-05-17
-
ISSUE-13
Updated
5.2.3
to
say
any
resource
can
be
in
a
LDPC
and
inserted
5.5.3
on
rejecting
member
data
on
PUT
to
LDPC
(SS)
</ins></li><li><ins class="diff-chg">
2013-05-17
-
Tweaks
to
Terminology
section
for
LDPR
and
LDPC
(SS)
</ins></li><li><ins class="diff-chg">
2013-05-17
-
ISSUE-9
Moved
section
4.1.7
out
of
spec
to
the
</ins><a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Servers_should_serve_up_canonical_URLs"><ins class="diff-chg">
deployment
guide
</ins></a><ins class="diff-chg">
(SS)
</ins></li><li><ins class="diff-chg">
2013-05-15
-
Updated
wording
for
5.2.2
from
to
be
more
clear
(SS)
</ins></li><li><ins class="diff-chg">
2013-05-13
-
ISSUE-49
Moved
section
4.1.4
out
of
spec
to
the
</ins><a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Predicate_URIs_SHOULD_be_HTTP_URLs"><ins class="diff-chg">
deployment
guide
</ins></a>.<ins class="diff-chg">
(SS)
</ins></li><li><ins class="diff-chg">
2013-05-08
-
Removed
closed
issues
5,
7,
55
and
38
as
the
don't
require
edits.
Added
64
and
65.
(SS)
</ins></li><li><ins class="diff-chg">
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)
</ins></li><li><ins class="diff-chg">
2013-04-15
-
ISSUE-21
Added
ldp:membershipPredicateInverse
to
5.2.5
&amp;
5.5.2,
created
5.2.5.1
&amp;
5.3.5.2
to
indicate
difference.
(SS)
</ins></li><li><ins class="diff-chg">
2013-04-15
-
ISSUE-39
Moved
informative
text
from
5.4.5
into
5.4.1,
shifted
subsections
.6-.10
(SS)
</ins></li><li><ins class="diff-chg">
2013-04-15
-
Expanded
on
wording
for
4.3
to
be
more
consistent
(SS)
</ins></li><li><ins class="diff-chg">
2013-04-08
-
Fixed
two
old
references
to
BPR
(SS)
</ins></li><li><ins class="diff-chg">
2013-03-17
-
Inserted
examples
2&amp;3,
a
more
complete
NetWorth
resource
(SS)
</ins></li><li><ins class="diff-chg">
2013-03-15
-
Update
LDPC
glossary
term
based
on
Cody's
feedback
(SS)
</ins></li><li><ins class="diff-chg">
2013-03-15
-
Additional
fix
in
5.2.2
for
ISSUE-34
(SS)
</ins></li><li><ins class="diff-chg">
2013-03-15
-
Remove
reference
to
closed
issues
that
don't
require
edits:
ISSUE-27
&amp;
ISSUE-45
(SS)
</ins></li><li><ins class="diff-chg">
2013-03-14
-
General
prep
for
3rd
draft,
cleanup
and
a
little
restructure
(SS)
</ins></li></ul><blockquote>
<em>
<del class="diff-old">First
</del>
<a href="http://www.w3.org/TR/2013/WD-ldp-20130307/">
<ins class="diff-chg">Second
</ins>
Public
Working
Draft
</a>
</em>
</blockquote>
<ul>
<li>
<ins class="diff-new">2013-03-14
-
Fixed
up
broken
fragments
and
typos
before
publication
(SS)
</ins></li><li>
2013-03-04
-
Comments
received
from
David
Wood:
5.3.7
&amp;
5.1.3
clarity,
other
minor
edits
(part
2)
(SS)
</li>
<li>
2013-03-04
-
Comments
received
from
David
Wood:
abstract,
paging
informative
(part
1)
(SS)
</li>
<li>
2013-03-04
-
ISSUE-36
-
Added
informative
text
regarding
creationg
of
containers
in
5.4.4
(SS)
</li>
<li>
2013-03-04
-
ISSUE-12
-
Added
section
4.7.3
not
to
allow
PATCH
for
create
(SS)
</li>
<li>
2013-03-03
-
Adjustments
to
language
about
different
container
behavior
(SS)
</li>
<li>
2013-03-02
-
Adding
trailing
'/'
on
Container
URLs
to
help
with
readability
based
on
WG
suggestion
(SS)
</li>
<li>
2013-02-26
-
Updated
Acknowledgements
section
(SS)
</li>
<li>
2013-02-25
-
ISSUE-29
-
Use
relative
URIs
in
examples
(SS)
</li>
<li>
2013-02-25
-
ISSUE-31
-
Added
a
more
complete
conformance
section,
motived
by
SPARQL
1.1
(SS)
</li>
<li>
2013-02-25
-
Updating
some
simple
formatting,
reorganizing
open
issues
and
todos.
(SS)
</li>
<li>
2013-02-15
-
ISSUE-34
-
Aggregration:
5.6.1
and
5.6.2
updated
for
review.
(JA)
</li>
<li>
2013-02-13
-
ISSUE-42
-
4.8
Common
Properties
moved
to
<a href="http://www.w3.org/2012/ldp/wiki/Deployment_Guide#Re-use_established_linked_data_vocabularies_instead_of_.28re-.29inventing_duplicates">
Deploment
Guide
</a>
(JA)
</li>
<li>
2013-02-12
-
Fixed
up
previous
publication
links
(SS)
</li>
<li>
2013-02-12
-
ISSUE-10
-
4.1.12
to
be
MUST
use
entity
tags
(either
weak
or
strong
ones)
(SS)
</li>
<li>
2013-02-12
-
ISSUE-11
-
4.4.1
Relaxed
the
MUST
ignore
dc:modified/creator
to
MAY
(SS)
</li>
<li>
2013-01-16
-
ISSUE-25
Updated
introduction.
5.2.2
changed
to
MUST
NOT
be
in
multiple
containers.
Flipped
5.6.1/2
as
first
rule
leads
to
2nd.
5.6.2(was
.1)
Delete
LDPC
MUST
also
delete
members.
(SS)
</li>
<li>
2013-01-16
-
Added
new
issues
ranging
from
26-43.
Removed
closed/deferred
issues:
2
&amp;
3
(SS)
</li>
<li>
2012-12-28
-
Fixed
Typos.
Separated
some
compound
rules
like
4.1.5.
Rewording
for
clarity:
4.1.10,
Text
being
repeated
in
several
places
centralized
and
cross-linked.
Made
printed
code
output
easier
to
read
on
black
&amp;
white
printers.
Exposed
terms
defined
in-line
under
LDPC
as
Terminology
(tentatively).
Removed
non-normative
qualifer
from
section
5.2.
Added
<del class="diff-old">&quot;several&quot;
</del>
<ins class="diff-chg">"several"
</ins>
editors'
to-dos.(JA)
</li>
<li>
2012-11-05
-
minor
rewording
from
ISSUE-24
</li>
<li>
2012-11-03
-
ISSUE-22,
ISSUE-23:
changed
sections
4.2.3
and
5.4.7.
Removed
closed
issues.
(SS)
</li>
<li>
2012-11-03
-
ISSUE-24
Delete
the
phrase
in
4.5.1
that
nays
<del class="diff-old">&quot;until
</del>
<ins class="diff-chg">"until
</ins>
...Request
<del class="diff-old">URI&quot;
</del>
<ins class="diff-chg">URI"
</ins>
and
adding
a
sentence,
<del class="diff-old">&quot;Clients
</del>
<ins class="diff-chg">"Clients
</ins>
should
note
that
servers
may
reuse
a
Request-URI
under
some
<del class="diff-old">circumstances.&quot;
</del>
<ins class="diff-chg">circumstances."
</ins>
</li>
<li>
2012-11-03
-
ISSUE-6
Removed
section
4.1.9.
Shifted
up
sections
.10
through
.13.
</li>
<li>
2012-11-01
-
Fixed
minor
typo
and
added
some
notes
(SS)
</li>
</ul>
<blockquote>
<em>
<del class="diff-old">Submission
</del>
<a href="http://www.w3.org/TR/2012/WD-ldp-20121025/">
<ins class="diff-chg">First
Public
Working
Draft
</ins></a>
</em>
</blockquote>
<ul>
<li>
2012-10-15
-
ISSUE-8
Changed
references
from
LDBP
to
LDP,
removed
definition
for
<del class="diff-old">&quot;profile&quot;
</del>
<ins class="diff-chg">"profile"
</ins>
and
new
namespace
(SS)
</li>
<li>
2012-10-15
-
Included
additional
open
ISSUES
from
Oct
15
WG
meeting:
22,
23,
24
(SS)
</li>
<li>
2012-10-14
-
Added
open
ISSUES
and
formating
to
prep
for
public
working
draft
(SS)
</li>
<li>
2012-09-20
-
Sent
pull
request
re
LINKED-DATA
and
added
suggestion
for
<code>
ldp
</code>
namespace
(SS)
</li>
<li>
2012-09-19
-
Repairing
references
and
forward
reference
to
biblio.js
updates
(SS)
</li>
<li>
2012-09-19
-
Fixed
rdfs:label
range
to
be
rdfs:Literal
(SS)
</li>
<li>
2012-09-19
-
ISSUE-1
Define
Turtle
as
the
required
serialization
format
for
LDP
(SS)
</li>
<li>
2012-09-18
-
Initial
ReSpec'ing
of
<a href="http://www.w3.org/Submission/ldbp/">
Member
Submission
-
Linked
Data
Basic
Profile
1.0
</a>
(SS)
</li>
<li>
2012-09-18
-
Fixed
up
some
links
and
worked
on
references,
work
left
to
do.
(SS)
</li>
</ul>
<del class="diff-old">C.
Editor
Todos
and
Notes
</del>
<blockquote>
<em>
<del class="diff-old">This
section
is
non-normative.
Other
than
LDP
open
actions
and
issues
,
included
here
are
transient
tasks
and
notes
editors
use.
They
have
not
meaning
in
final
product
of
a
published
working
draft
and
will
be
removed
prior
to
publishing.
Insert
some
additional
examples
4.1.2:
&quot;the&quot;
subject
?=
Request-URI
...
not
always
(hash
URIs)
4.1.5:
refers
to
RDF
*Primer*
-
is
that
intentful?
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
&quot;
LDPR
server&quot;?
...think
about
role
vs
artifact.
If
&quot;an
LDPR
server&quot;
hosts
both
LDPRs
and
non-
LDPR
HTTP
resources,
4.1.2
(if
&quot;the
code&quot;
==
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.
4.1.7:
define
&quot;explicitly&quot;?
4.4.1:
specifically
calls
out
2
props;
issue-11
note
talks
about
&quot;server-managed
props&quot;
which
is
not
defined.
4.4.4/4.4.5
could
be
read
to
overlap/dup
one
another
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.
5.2.1:
4.1.6.1
issue
linked
to
this
text
5.2.2:
I
think
we
mean
&quot;resource&quot;
==
any
HTTP
resource,
not
just
LDPR
.
If
so,
perhaps
we
should
be
more
explicit.
5.2.1
might
be
the
place.
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.
5.4.5:
in
light
of
the
existence
of
server-managed
properties,
why
not
allow
response
body
from
create?
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,
&quot;An
LDPR
server
MAY
require
a
user
to
be
authenticated
and
authorized
before
this
action
is
permitted.&quot;
to
each
of
those
sections.',
consider
place
to
edit
this
in.
ISSUE-37
Additional
introductory
text
on
the
LDP
data
and
interaction
model
ISSUE-5
Add
a
section
explaining
how
LDP
is
related
to
Graph
Store
Protocol
D.
References
D.1
Normative
references
[DC-RDF]
M.
Nilsson
et
al.
Expressing
Dublin
Core
metadata
using
the
Resource
Description
Framework
(RDF)
.
14
January
2008.
DCMI
Recommendation.
URL:
http://dublincore.org/documents/dc-rdf/
[DC-TERMS]
Dublin
Core
Metadata
Initiative.
Dublin
Core
Metadata
Initiative
Terms,
version
1.1.
11
October
2010.
DCMI
Recommendation.
URL:
http://dublincore.org/documents/2010/10/11/dcmi-terms/
.
[HTML401]
David
Raggett;
Ian
Jacobs;
Arnaud
Le
Hors.
HTML
4.01
Specification
.
24
December
1999.
W3C
Recommendation.
URL:
http://www.w3.org/TR/1999/REC-html401-19991224
[HTTP11]
R.
Fielding
et
al.
Hypertext
Transfer
Protocol
-
HTTP/1.1
.
June
1999.
RFC
2616.
URL:
http://www.ietf.org/rfc/rfc2616.txt
[RDF-PRIMER]
Frank
Manola;
Eric
Miller.
RDF
Primer
.
10
February
2004.
W3C
Recommendation.
URL:
http://www.w3.org/TR/2004/REC-rdf-primer-20040210/
[RDF-SCHEMA]
Dan
Brickley;
Ramanathan
V.
Guha.
RDF
Vocabulary
Description
Language
1.0:
RDF
Schema
.
10
February
2004.
W3C
Recommendation.
URL:
http://www.w3.org/TR/2004/REC-rdf-schema-20040210
[RFC2119]
S.
Bradner.
Key
words
for
use
in
RFCs
to
Indicate
Requirement
Levels.
March
1997.
Internet
RFC
2119.
URL:
http://www.ietf.org/rfc/rfc2119.txt
[RFC4627]
D.
Crockford.
The
application/json
Media
Type
for
JavaScript
Object
Notation
(JSON)
.
July
2006.
RFC
4627.
URL:
http://www.ietf.org/rfc/rfc4627.txt
[RFC5789]
L
Dusseault;
J.
Snell.
PATCH
Method
for
HTTP
.
March
2010.
Internet
Proposed
Standard
RFC
5789.
URL:
http://tools.ietf.org/html/rfc5789
[SPARQL-QUERY]
E.
Prud'hommeaux;
A.
Seaborne.
SPARQL
Query
Language
for
RDF
.
W3C
Recommendation.
15
January
2008.
URL:
http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/
[SPARQL-UPDATE]
S.
Schenk;
P.
Gearon.
SPARQL
1.1
Update
.
W3C
Working
Draft.
26
January
2010.
URL:
http://www.w3.org/TR/2010/WD-sparql11-update-20100126/
[TURTLE]
David
Beckett;
Tim
Berners-Lee.
Turtle:
Terse
RDF
Triple
Language
.
January
2008.
W3C
Team
Submission.
URL:
http://www.w3.org/TeamSubmission/turtle/
D.2
Informative
references
[LINKED-DATA]
</del>
<del class="diff-old">Tim
Berners-Lee.
Linked
Data
Design
Issues
.
27
July
2006.
W3C-Internal
Document.
URL:
http://www.w3.org/DesignIssues/LinkedData.html
[WEBARCH]
Norman
Walsh;
Ian
Jacobs.
Architecture
of
the
World
Wide
Web,
Volume
One
.
15
December
2004.
W3C
Recommendation.
URL:
http://www.w3.org/TR/2004/REC-webarch-20041215/
</del>
<a href="http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/">
<ins class="diff-chg">Submission
</ins>
</a>
</em>
</blockquote>
</section>
</body>
</html>