ldp-diff-20140210.html
author Steve Speicher <sspeiche@gmail.com>
Thu, 11 Dec 2014 08:30:51 -0500
changeset 920 6e705e6cd210
parent 478 cfcf586b2200
permissions -rw-r--r--
Updated abstract and publication dates for PR
<!-- 
 Editor TODO:
   - Search "TODO" within this document.
   - Once companion documents (best practices, primer) have URLs, link to them.  Search on "companion".
   - Once the membership* names stabilize, take a pass through for "membership consistent value", membership-constant-URI
     and see if there is a friendlier way to phrase it.
   - Paging intro: add 3rd example showing header linkage amongst pages and (HEAD on) the base resource.
     Maybe also insert HEAD on base as new first example instead of relying on text alone.
   - The ReSpec SPARQL QUERY link is http://www.w3.org/TR/rdf-sparql-query/ , which has highlighted text
        referring readers to SPARQL 1.1.  Which normative reference do we want?
 Various pre-LC comments:
    - 5.2.5.1 For a given triple T with a subject C of the LDPC and predicate of ldp:containsRelation, 
          5.2.5.2 For a given triple T with a subject C of the LDPC and predicate of ldp:containedByRelation, 
          5.2.10 Some LDPC's have membership object's that are not directly URIs minted upon LDPC member creation, 
          (JohnA) I found these particularly hard to read.  And I perpetrated the SortCollation paragraphs.  
          Links to examples might be an 80-20 solution. 
        - 5.3.1: I'd change the link to the example ("as in the example") to refer the concrete example #, I think example 9. 
          Currently does not work when printing.
 Misc during LC comments:
    - http://lists.w3.org/Archives/Public/public-ldp/2013Aug/0002.html
      #1 Should update example in 5.1.3 to be more clear on what the request vs base URI is.  Also example is missing ldp:nextPage.
 -->
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>Linked Data Platform 1.0</title>
<!-- Changed by: , 07-Feb-2014 -->
<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:  "",

          // 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-07-30",
          previousMaturity:     "LC",
          previousURI:                  "http://www.w3.org/TR/2013/WD-ldp-20130730/",

          // 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: "2013-09-02",
          
          // Only include h1 and h2 level
          maxTocLevel: 2,

          // 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: "mailto: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-comments",
          
          // 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",
                        localBiblio:  {
                                "HTTPBIS-SEMANTICS": {
                                        title:    "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"
                                ,   href:     "http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics/"
                                ,   authors:  [
                                                "R. Fielding"
                                        ,   "J. Reschke"
                                        ]
                                ,   status:   "In Last Call"
                                ,   publisher:  "IETF"
                                },
                                "RFC2817": {
                                        title:    "Upgrading to TLS Within HTTP/1.1"
                                ,   href:     "http://tools.ietf.org/html/rfc2817"
                                ,   authors:  [
                                                "R. Khare"
                                        ,   "S. Lawrence"
                                        ]
                                ,   status:   "Proposed Standard"
                                ,   publisher:  "IETF"
                                },
                                "RFC5005": {
                                        title:    "Feed Paging and Archiving"
                                ,   href:     "http://tools.ietf.org/html/rfc5005"
                                ,   authors:  [
                                                "M. Nottingham"
                                        ]
                                ,   status:   "Proposed Standard"
                                ,   publisher:  "IETF"
                                }
                        },
      };
//]]>
</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;
                }
                .normal { 
                        font-weight: normal;
                        font: normal 100% sans-serif;
                }
                
/*]]>*/
</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
Last
Call
Working
Draft
30
July
2013
This
version:
http://www.w3.org/TR/2013/WD-ldp-20130730/
Latest
published
version:
http://www.w3.org/TR/ldp/
Latest
editor's
draft:
http://www.w3.org/2012/ldp/hg/ldp.html
Previous
version:
http://www.w3.org/TR/2013/WD-ldp-20130307/
Editors:
Steve
Speicher
,
IBM
Corporation
John
Arwe
,
IBM
Corporation
Ashok
Malhotra
,
Oracle
Corporation
Copyright
©
2013
W3C
®
(
MIT
,
ERCIM
,
Keio
,
Beihang
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
Abstract
</del>
<section id='abstract'>
This
document
describes
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
document
was
published
by
the
Linked
Data
Platform
Working
Group
as
a
Last
Call
Working
Draft.
This
document
is
intended
to
become
a
W3C
Recommendation.
If
you
wish
to
make
comments
regarding
this
document,
please
send
them
to
public-ldp-comments@w3.org
(
subscribe
,
archives
).
The
Last
Call
period
ends
02
September
2013.
All
comments
are
welcome.
Publication
as
a
Last
Call
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
is
a
Last
Call
Working
Draft
and
thus
the
Working
Group
has
determined
that
this
document
has
satisfied
the
relevant
technical
requirements
and
is
sufficiently
stable
to
advance
through
the
Technical
Recommendation
process.
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
Informative
4.2
General
4.3
HTTP
GET
4.4
HTTP
POST
4.5
HTTP
PUT
4.6
HTTP
DELETE
4.7
HTTP
HEAD
4.8
HTTP
PATCH
4.9
HTTP
OPTIONS
4.10
Paging
4.10.1
Introduction
4.10.2
HTTP
GET
4.10.3
HTTP
OPTIONS
4.11
Resource
Inlining:
Representing
Multiple
Resources
in
a
Response
4.11.1
Introduction
4.11.2
Use
with
Care
4.11.3
HTTP
GET
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
5.9
HTTP
OPTIONS
5.10
Member
Inlining:
Returning
All
of
a
Container
Page's
Members
in
a
Response
5.10.1
Introduction
5.10.2
HTTP
GET
6.
HTTP
Header
Definitions
6.1
The
Accept-Post
Response
Header
A.
Acknowledgements
B.
References
B.1
Normative
references
B.2
Informative
references
</del>
</section>
<del class="diff-old">1.
</del>
<section class="informative" id="intro">
<h1>
Introduction
<del class="diff-old">This
section
is
non-normative.
</del>
</h1>
<p>
This
<del class="diff-old">document
</del>
<ins class="diff-chg">specification
</ins>
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">&nbsp;It
</del>
<ins class="diff-chg">&#160;It
</ins>
provides
clarifications
and
extensions
of
the
<del class="diff-old">four
</del>
rules
of
Linked
Data
<del class="diff-old">[
LINKED-DATA
]:
</del>
<ins class="diff-chg">[[LINKED-DATA]]:
</ins>
</p>
<del class="diff-old">1.
</del>
<ol>
<li>
Use
URIs
as
names
for
things
<del class="diff-old">2.
</del>
</li>
<li>
Use
HTTP
URIs
so
that
people
can
look
up
those
names
<del class="diff-old">3.
</del>
</li>
<li>
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>
)
<del class="diff-old">4.
</del>
</li>
<li>
Include
links
to
other
URIs,
so
that
they
can
discover
more
things
</li>
</ol>
<p>
This
specification
discusses
standard
HTTP
and
RDF
techniques
<ins class="diff-new">used
when
constructing
clients
</ins>
and
<ins class="diff-new">servers
that
create,
read,
and
write
</ins><a title="Linked Data Platform Resource"><ins class="diff-new">
Linked
Data
Platform
Resources
</ins></a>.<ins class="diff-new">
A
companion
document
discusses
</ins>
best
practices
that
you
should
use,
and
anti-patterns
you
should
avoid,
when
constructing
<ins class="diff-new">these
</ins>
clients
and
<del class="diff-old">servers
that
read
and
write
Linked
Data
</del>
<ins class="diff-chg">servers.
</ins></p><p><ins class="diff-chg">
This
specification
provides
a
widely
re-usable
pattern
to
deal
with
large
</ins>
resources.
<ins class="diff-new">Depending
on
the
server’s
capabilities,
a
GET
request
on
a
</ins><a title="Paged resource"><ins class="diff-new">
resource
</ins></a><ins class="diff-new">
can
be
redirected
to
a
</ins><a title="Single-page resource"><ins class="diff-new">
subset
of
the
resource
(one
page)
</ins></a>,<ins class="diff-new">
that
provides
access
to
subsequent
pages
(see
</ins><a href="#ldpr-Paging" class="sectionRef"></a><ins class="diff-new">
).
</ins>
</p>
<p>
<del class="diff-old">A
</del>
<ins class="diff-chg">This
specification
defines
a
</ins>
special
type
of
<a>
Linked
Data
Platform
Resource
<del class="diff-old">is
</del>
</a>:
a
<a title="Linked Data Platform Container">
Container
</a>.
Containers
are
very
useful
in
building
application
models
involving
collections
of
<ins class="diff-new">resources,
often
</ins>
homogeneous
<del class="diff-old">resources.
</del>
<ins class="diff-chg">ones.
</ins>
For
example,
universities
offer
a
collection
of
classes
and
have
a
collection
of
faculty
members,
each
faculty
member
teaches
a
collection
of
courses,
<del class="diff-old">etc.
</del>
<ins class="diff-chg">and
so
on.
</ins>
This
specification
discusses
how
to
work
with
containers.
Resources
can
be
added
to
containers
<del class="diff-old">in
several
ways.
As
a
special
case,
members
can
both
be
created
and
added
to
a
container
by
overloading
the
</del>
<ins class="diff-chg">using
standard
HTTP
operations
like
</ins>
POST
<del class="diff-old">operation
</del>
(see
<a href="#ldpc-HTTP_POST" class="sectionRef">
<del class="diff-old">section
5.4
).
Another
contribution
of
this
specification
is
how
to
deal
with
large
amounts
of
data.
Depending
on
the
server’s
capabilities,
a
GET
request
on
a
Linked
Data
Platform
Resource
returns
a
set
of
pages
and
uses
a
convention
to
access
any
subsequent
page
(see
section
4.10
</del>
</a>
).
</p>
<p>
The
intention
of
this
<del class="diff-old">document
</del>
<ins class="diff-chg">specification
</ins>
is
to
enable
additional
rules
and
layered
groupings
of
rules
as
additional
specifications.
The
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>
<p>
<ins class="diff-chg">For
context
and
background,
it
could
be
useful
to
read
</ins><a href="#bib-LDP-UCR"><ins class="diff-chg">
Linked
Data
Platform
Use
Case
and
Requirements
</ins></a><ins class="diff-chg">
[[LDP-UCR]]
and
</ins><a href="#base-specs" class="sectionRef">
<del class="diff-old">2.
</del>
</a>.
</p>
</section>
<section id="terms">
<h1>
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
].
Linked
Data
Platform
Resource
(
LDPR
)
HTTP
resource
whose
state
is
represented
in
RDF
that
conforms
to
the
simple
lifecycle
patterns
and
conventions
in
section
4.
.
Linked
Data
Platform
Container
(
LDPC
)
An
LDPR
representing
a
collection
of
same-subject,
same-predicate
triples
which
is
uniquely
identified
by
a
URI
that
responds
to
client
requests
for
creation,
modification,
and
enumeration
of
its
members.
</del>
<ins class="diff-chg">[[LINKED-DATA]].
</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">[
</del>
<ins class="diff-chg">[[HTTP11]].
</ins></p></dd><dt>
<del class="diff-old">HTTP11
</del>
<dfn>
<ins class="diff-chg">Linked
Data
Platform
Resource
</ins></dfn><ins class="diff-chg">
(
</ins><abbr title="Linked Data Platform Resource"><ins class="diff-chg">
LDPR
</ins></abbr><ins class="diff-chg">
)
</ins></dt><dd><ins class="diff-chg">
A
HTTP
resource
whose
state
is
represented
in
any
way
that
conforms
to
the
simple
lifecycle
patterns
and
conventions
in
</ins><a href="#ldpr" class="sectionRef"></a>.<p></p></dd><dt><dfn><ins class="diff-chg">
Linked
Data
Platform
RDF
Resource
</ins></dfn><ins class="diff-chg">
(
</ins><abbr title="Linked Data Platform RDF Resource"><ins class="diff-chg">
LDP-RR
</ins></abbr><ins class="diff-chg">
)
</ins></dt><dd><ins class="diff-chg">
An
</ins><a title="Linked Data Platform Resource"><ins class="diff-chg">
LDPR
</ins></a><ins class="diff-chg">
whose
state
is
represented
in
RDF,
corresponding
to
an
RDF
</ins><a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph"><ins class="diff-chg">
named
graph
</ins>
</a>
<ins class="diff-new">[[rdf11-concepts]].
</ins><p>
<del class="diff-old">].
</del>
</p>
</dd>
<dt>
<dfn>
<ins class="diff-new">Linked
Data
Platform
Binary
Resource
</ins></dfn><ins class="diff-new">
(
</ins><abbr title="Linked Data Platform Binary Resource"><ins class="diff-new">
LDP-BR
</ins></abbr><ins class="diff-new">
)
</ins></dt><dd><ins class="diff-new">
A
</ins><a title="Linked Data Platform Resource"><ins class="diff-new">
LDPR
</ins></a><ins class="diff-new">
whose
state
is
</ins><em><ins class="diff-new">
not
</ins></em><ins class="diff-new">
represented
in
RDF.
These
are
binary
or
text
documents
that
do
not
have
useful
RDF
representations.
</ins><p>
</p>
</dd>
<dt>
<dfn>
<ins class="diff-chg">Linked
Data
Platform
Container
</ins></dfn><ins class="diff-chg">
(
</ins><abbr title="Linked Data Platform Container"><ins class="diff-chg">
LDPC
</ins></abbr><ins class="diff-chg">
)
</ins></dt><dd><ins class="diff-chg">
An
LDPR
representing
a
collection
of
</ins><a title="Membership"><ins class="diff-chg">
member
</ins></a><ins class="diff-chg">
resources
and/or
</ins><a title="Containment"><ins class="diff-chg">
contained
</ins></a><ins class="diff-chg">
documents
(information
resources
[[!WEBARCH]])
that
responds
to
client
requests
for
creation,
modification,
and/or
enumeration
of
its
members
and
documents,
and
that
conforms
to
the
simple
lifecycle
patterns
and
conventions
in
</ins><a href="#ldpc" class="sectionRef"></a>.<p></p></dd><dt><dfn><ins class="diff-chg">
Linked
Data
Platform
Basic
Container
</ins></dfn><ins class="diff-chg">
(
</ins><abbr title="Linked Data Platform Basic Container"><ins class="diff-chg">
LDP-BC
</ins></abbr><ins class="diff-chg">
)
</ins></dt><dd><ins class="diff-chg">
A
</ins><a title="Linked Data Platform Container"><ins class="diff-chg">
LDPC
</ins></a><ins class="diff-chg">
that
uses
a
single
pre-defined
predicate
to
link
to
both
its
</ins><a title="Containment"><ins class="diff-chg">
contained
</ins></a><ins class="diff-chg">
and
</ins><a title="Membership"><ins class="diff-chg">
member
</ins></a><ins class="diff-chg">
documents
(information
resources)
[[!WEBARCH]].
</ins><p></p></dd><dt><dfn><ins class="diff-chg">
Linked
Data
Platform
Direct
Container
</ins></dfn><ins class="diff-chg">
(
</ins><abbr title="Linked Data Platform Direct Container"><ins class="diff-chg">
LDP-DC
</ins></abbr><ins class="diff-chg">
)
</ins></dt><dd><ins class="diff-chg">
A
</ins><a title="Linked Data Platform Container"><ins class="diff-chg">
LDPC
</ins></a><ins class="diff-chg">
that
has
the
flexibility
of
choosing
what
form
its
</ins><a title="Membership triples"><ins class="diff-chg">
membership
triples
</ins></a><ins class="diff-chg">
take,
and
allows
</ins><a title="Membership"><ins class="diff-chg">
members
</ins></a><ins class="diff-chg">
to
be
any
resources
[[!WEBARCH]],
not
only
documents.
</ins><p></p></dd><dt><dfn><ins class="diff-chg">
Linked
Data
Platform
Indirect
Container
</ins></dfn><ins class="diff-chg">
(
</ins><abbr title="Linked Data Platform Indirect Container"><ins class="diff-chg">
LDP-IC
</ins></abbr><ins class="diff-chg">
)
</ins></dt><dd><ins class="diff-chg">
A
</ins><a title="Linked Data Platform Container"><ins class="diff-chg">
LDPC
</ins></a><ins class="diff-chg">
that
is
similar
to
a
</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
LDP-DC
</ins></a><ins class="diff-chg">
and
is
capable
of
accepting
creation
requests
that
result
in
</ins><a title="Membership"><ins class="diff-chg">
members
</ins></a><ins class="diff-chg">
being
added
based
on
the
content
of
its
</ins><a title="Containment"><ins class="diff-chg">
contained
</ins></a><ins class="diff-chg">
documents
rather
than
the
URIs
assigned
to
those
documents.
</ins><p></p></dd><dt><dfn><ins class="diff-chg">
Membership
</ins></dfn></dt><dd><ins class="diff-chg">
The
relationship
linking
an
LDP-RR
(LDPCs
are
also
LDP-RRs)
and
its
member
LDPRs.
There
often
is
a
linked
LDPC
that
assists
with
managing
the
member
LDPRs.
</ins><p></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.
<del class="diff-old">The
</del>
<ins class="diff-chg">A
container's
</ins>
membership
triples
<ins class="diff-new">all
have
one
</ins>
of
<ins class="diff-new">the
following
patterns:
</ins><table style="margin-left: +3em"><tr><td style="padding:0 0 0 +2ex"><var style="background:#DDDDDD"><ins class="diff-new">
membership-constant-URI
</ins></var></td><td style="padding:0 0 0 +2ex"><var><ins class="diff-new">
membership-predicate
</ins></var></td><td style="padding:0 0 0 +2ex"><var style="background:#CCFFFF"><ins class="diff-new">
member-derived-URI
</ins></var></td></tr><tr><td style="padding:0 0 0 +2ex"><var style="background:#CCFFFF"><ins class="diff-new">
member-derived-URI
</ins></var></td><td style="padding:0 0 0 +2ex"><var><ins class="diff-new">
membership-predicate
</ins></var></td><td style="padding:0 0 0 +2ex"><var style="background:#DDDDDD"><ins class="diff-new">
membership-constant-URI
</ins></var></td></tr></table><ins class="diff-new">
The
difference
between
the
two
is
simply
which
position
member-derived-URI
occupies,
which
is
usually
driven
by
the
choice
of
</ins><var><ins class="diff-new">
membership-predicate
</ins></var>.<ins class="diff-new">
Most
predicates
have
</ins>
a
<ins class="diff-new">natural
forward
direction
inherent
in
their
name,
and
existing
vocabularies
contain
useful
examples
that
read
naturally
in
each
direction.
</ins><code><ins class="diff-new">
ldp:member
</ins></code><ins class="diff-new">
and
</ins><code><ins class="diff-new">
dcterms:isPartOf
</ins></code><ins class="diff-new">
are
representative
examples.
</ins><p><ins class="diff-new">
Each
</ins>
container
<del class="diff-old">all
have
</del>
<ins class="diff-chg">exposes
properties
(see
</ins><a href="#ldpc-general" class="sectionRef"></a><ins class="diff-chg">
)
that
allow
clients
to
determine
which
pattern
it
uses,
what
</ins>
the
<del class="diff-old">same
subject
</del>
<ins class="diff-chg">actual
</ins><var><ins class="diff-chg">
membership-predicate
</ins></var>
and
<del class="diff-old">predicate,
</del>
<var>
<ins class="diff-chg">membership-constant-URI
</ins></var><ins class="diff-chg">
values
are,
</ins>
and
<ins class="diff-new">(for
containers
that
allow
</ins>
the
<del class="diff-old">objects
</del>
<ins class="diff-chg">creation
</ins>
of
<ins class="diff-new">new
members)
what
value
is
used
for
</ins>
the
<del class="diff-old">membership
triples
identify
</del>
<var>
<ins class="diff-chg">member-derived-URI
</ins></var><ins class="diff-chg">
based
on
</ins>
the
<del class="diff-old">container's
members.
</del>
<ins class="diff-chg">client's
input
to
the
creation
process.
</ins></p>
<p>
</p>
</dd>
<dt>
<dfn>
Membership
<del class="diff-old">subject
</del>
<ins class="diff-chg">predicate
</ins>
</dfn>
</dt>
<dd>
The
<del class="diff-old">subject
</del>
<ins class="diff-chg">predicate
</ins>
of
all
a
<del class="diff-old">LDPC
's
</del>
<ins class="diff-chg">LDPC's
</ins><a title="Membership triples">
membership
triples
</a>.
<p>
</p>
</dd>
<dt>
<del class="diff-old">Membership
predicate
</del>
<dfn>
<ins class="diff-chg">Containment
</ins>
</dfn>
</dt>
<dd>
The
<del class="diff-old">predicate
</del>
<ins class="diff-chg">relationship
binding
an
LDPC
to
LDPRs
whose
lifecycle
it
controls
and
is
aware
of.
The
lifecycle
</ins>
of
<del class="diff-old">all
</del>
<ins class="diff-chg">the
contained
LDPR
is
limited
by
the
lifecycle
of
the
containing
LDPC;
that
is,
</ins>
a
<ins class="diff-chg">contained
LDPR
cannot
be
created
(through
LDP-defined
means)
before
its
containing
</ins>
LDPC
<del class="diff-old">'s
membership
triples
.
</del>
<ins class="diff-chg">exists.
</ins>
<p>
</p>
</dd>
<dt>
<del class="diff-old">Page
resource
</del>
<dfn>
<ins class="diff-chg">Containment
triples
</ins>
</dfn>
</dt>
<dd>
A
<del class="diff-old">type
</del>
<ins class="diff-chg">set
</ins>
of
<del class="diff-old">LDPR
</del>
<ins class="diff-chg">triples
in
an
LDPC's
state,
maintained
by
the
LDPC,
that
lists
documents
created
by
the
LDPC
but
not
yet
deleted.
These
triples
</ins><strong><ins class="diff-chg">
always
</ins></strong><ins class="diff-chg">
have
the
form:
</ins><var><ins class="diff-chg">
(
LDPC
URI,
ldp:contains
,
document-URI
)
</ins></var>.<p></p></dd><dt><dfn><ins class="diff-chg">
Empty-container
triples
</ins></dfn></dt><dd><ins class="diff-chg">
The
portion
of
an
LDPC's
state
</ins>
that
<ins class="diff-new">would
be
present
when
the
container
</ins>
is
<del class="diff-old">associated
</del>
<ins class="diff-chg">empty.
Currently,
this
definition
is
equivalent
</ins>
to
<del class="diff-old">another
LDPR
</del>
<ins class="diff-chg">all
the
LDPC's
triples
minus
its
containment
triples
</ins>
and
<del class="diff-old">whose
representation
includes
a
subset
</del>
<ins class="diff-chg">minus
its
membership
triples,
but
if
future
versions
of
LDP
define
additional
classes
</ins>
of
<del class="diff-old">the
</del>
triples
<del class="diff-old">in
the
associated
LDPR
.
</del>
<ins class="diff-chg">then
this
definition
would
expand
to
subtract
out
those
classes
as
well.
</ins>
<p>
</p>
</dd>
<dt>
<del class="diff-old">Non-member
</del>
<dfn>
<ins class="diff-chg">Paged
</ins>
resource
</dfn>
</dt>
<dd>
A
<del class="diff-old">resource
associated
with
a
LDPC
by
</del>
<ins class="diff-chg">LDP-RR
whose
representation
may
be
too
large
to
fit
in
</ins>
a
<del class="diff-old">server
</del>
<ins class="diff-chg">single
HTTP
response,
</ins>
for
<del class="diff-old">the
purpose
of
enabling
clients
to
retrieve
</del>
<ins class="diff-chg">which
an
LDP
server
offers
</ins>
a
<del class="diff-old">subset
</del>
<ins class="diff-chg">sequence
</ins>
of
<ins class="diff-new">single-page
</ins><a title="Linked Data Platform RDF Resource"><ins class="diff-new">
LDP-RRs
</ins></a>.<ins class="diff-new">
When
</ins>
the
<del class="diff-old">LDPC
's
state,
namely
the
subset
that
omits
</del>
<ins class="diff-chg">representations
of
</ins>
the
<del class="diff-old">LDPC
's
membership
triples.
In
other
words,
</del>
<ins class="diff-chg">sequence's
resources
are
combined
by
a
client,
</ins>
the
<del class="diff-old">union
</del>
<ins class="diff-chg">client
has
a
(potentially
incomplete
or
incoherent)
copy
</ins>
of
the
<del class="diff-old">non-member
</del>
<ins class="diff-chg">paged
</ins>
resource's
<del class="diff-old">state
</del>
<ins class="diff-chg">state.
If
a
paged
resource
</ins><var><ins class="diff-chg">
P
</ins></var><ins class="diff-chg">
is
a
LDP-RR
</ins>
and
<ins class="diff-new">is
broken
into
a
sequence
of
pages
(single-page
resources)
</ins><var><ins class="diff-new">
P
</ins><sub><ins class="diff-new">
1
</ins></sub>,<ins class="diff-new">
P
</ins><sub><ins class="diff-new">
2
</ins></sub>,<ins class="diff-new">
...,P
</ins><sub><ins class="diff-new">
n
</ins></sub></var>,<ins class="diff-new">
the
representation
of
each
</ins><var><ins class="diff-new">
P
</ins><sub><ins class="diff-new">
i
</ins></sub></var><ins class="diff-new">
contains
a
subset
of
</ins>
the
<del class="diff-old">LDPC
's
membership
</del>
triples
<ins class="diff-new">in
</ins><var><ins class="diff-new">
P
</ins></var>.<ins class="diff-new">
LDP
allows
paging
of
resources
other
than
</ins><a title="Linked Data Platform RDF Resource"><ins class="diff-new">
LDP-RRs
</ins></a>,<ins class="diff-new">
but
does
not
specify
how
clients
combine
their
representations.
See
</ins><a href="#ldpr-Paging" class="sectionRef"></a><ins class="diff-new">
for
additional
details.
For
readers
familiar
with
paged
feeds
[[RFC5005]],
a
paged
resource
is
similar
to
a
logical
feed.
Any
resource
could
be
considered
to
be
a
paged
resource
consisting
of
</ins>
exactly
<del class="diff-old">equals
the
LDPC
's
state.
</del>
<ins class="diff-chg">one
page,
although
there
is
no
known
advantage
in
doing
so.
</ins>
<p>
</p>
</dd>
<dt>
<del class="diff-old">Resource
inlining
</del>
<dfn>
<ins class="diff-chg">Single-page
resource
</ins>
</dfn>
</dt>
<dd>
<del class="diff-old">The
practice
</del>
<ins class="diff-chg">One
</ins>
of
<del class="diff-old">responding
to
</del>
a
<del class="diff-old">HTTP
GET
request
made
to
a
request
URI
</del>
<ins class="diff-chg">sequence
of
related
</ins><a title="Linked Data Platform RDF Resource"><ins class="diff-chg">
LDP-RRs
</ins></a>
<var>
<del class="diff-old">R
</del>
<ins class="diff-chg">P
</ins>
<sub>
<del class="diff-old">0
</del>
<ins class="diff-chg">1
</ins></sub>,<ins class="diff-chg">
P
</ins><sub><ins class="diff-chg">
2
</ins></sub>,<ins class="diff-chg">
...,P
</ins><sub><ins class="diff-chg">
n
</ins>
</sub>
</var>,
<ins class="diff-new">each
of
which
contains
a
subset
of
the
state
of
another
resource
</ins><var><ins class="diff-new">
P
</ins></var>.<var><ins class="diff-new">
P
</ins>
</var>
<ins class="diff-new">is
called
the
paged
resource.
For
readers
familiar
</ins>
with
<ins class="diff-new">paged
feeds
[[RFC5005]],
</ins>
a
<del class="diff-old">representation
</del>
<ins class="diff-chg">single-page
resource
is
similar
to
a
feed
document
and
the
same
coherency/completeness
considerations
apply.
</ins><a href="#ldpr-pagingGET-sequences-change"><ins class="diff-chg">
LDP
provides
no
guarantees
</ins>
that
<del class="diff-old">includes
</del>
the
<del class="diff-old">state
</del>
<ins class="diff-chg">sequence
is
stable
</ins></a>.<p><ins class="diff-chg">
Note:
the
choice
</ins>
of
<del class="diff-old">R
0
,
</del>
<ins class="diff-chg">terms
was
designed
to
help
authors
and
readers
clearly
differentiate
between
</ins>
the
<a title="Paged resource">
<em>
<del class="diff-old">entire
</del>
<ins class="diff-chg">resource
being
paged
</ins>
</em>
<del class="diff-old">state
of
resources
accessed
through
</del>
</a>,
<ins class="diff-chg">and
the
</ins><a title="Single-page resource">
<em>
<del class="diff-old">other
</del>
<ins class="diff-chg">individual
page
resources
</ins>
</em>
<del class="diff-old">request
URI(s)
</del>
</a>,
<ins class="diff-chg">in
cases
where
both
are
mentioned
in
close
proximity.
</ins></p><p></p></dd><dt><dfn><ins class="diff-chg">
first
page
link
</ins></dfn></dt><dd><ins class="diff-chg">
A
link
to
the
first
</ins><a title="Single-page resource"><ins class="diff-chg">
single-page
resource
</ins></a><ins class="diff-chg">
of
a
</ins><a title="Paged resource"><ins class="diff-chg">
paged
resource
</ins></a>
<var>
<del class="diff-old">R
</del>
<ins class="diff-chg">P
</ins></var>.<ins class="diff-chg">
Syntactically,
a
HTTP
</ins><code><ins class="diff-chg">
Link
&lt;
</ins><var><ins class="diff-chg">
P
</ins>
<sub>
1
</sub>
<del class="diff-old">...
</del>
</var>
<ins class="diff-chg">&gt;;
rel='first'
</ins></code><ins class="diff-chg">
header
[[!RFC5988]].
</ins><p></p></dd><dt><dfn><ins class="diff-chg">
next
page
link
</ins></dfn></dt><dd><ins class="diff-chg">
A
link
to
the
next
</ins><a title="Single-page resource"><ins class="diff-chg">
single-page
resource
</ins></a><ins class="diff-chg">
of
a
</ins><a title="Paged resource"><ins class="diff-chg">
paged
resource
</ins></a>
<var>
<del class="diff-old">R
</del>
<ins class="diff-chg">P
</ins></var>.<ins class="diff-chg">
Syntactically,
a
HTTP
</ins><code><ins class="diff-chg">
Link
&lt;
</ins><var><ins class="diff-chg">
P
</ins>
<sub>
<del class="diff-old">n
</del>
<ins class="diff-chg">i
</ins>
</sub>
<del class="diff-old">,
and
assertions
from
the
server
identifying
</del>
</var>
<ins class="diff-chg">&gt;;
rel='next'
</ins></code><ins class="diff-chg">
header
[[!RFC5988]]
where
</ins>
the
<del class="diff-old">additional
resources
whose
entire
state
has
been
provided.
</del>
<ins class="diff-chg">target
URI
is
</ins>
<var>
<del class="diff-old">R
</del>
<ins class="diff-chg">P
</ins>
<sub>
<del class="diff-old">1
</del>
<ins class="diff-chg">i=2...n
</ins>
</sub>
<del class="diff-old">...
</del>
</var>.
<p>
</p>
</dd>
<dt>
<dfn>
<ins class="diff-chg">last
page
link
</ins></dfn></dt><dd><ins class="diff-chg">
A
link
to
the
last
</ins><a title="Single-page resource"><ins class="diff-chg">
single-page
resource
</ins></a><ins class="diff-chg">
of
a
</ins><a title="Paged resource"><ins class="diff-chg">
paged
resource
</ins></a>
<var>
<del class="diff-old">R
</del>
<ins class="diff-chg">P
</ins></var>.<ins class="diff-chg">
Syntactically,
a
HTTP
</ins><code><ins class="diff-chg">
Link
&lt;
</ins><var><ins class="diff-chg">
P
</ins>
<sub>
n
</sub>
</var>
<del class="diff-old">identify
the
inlined
resource(s).
See
section
4.11
for
details.
</del>
<ins class="diff-chg">&gt;;
rel='last'
</ins></code><ins class="diff-chg">
header
[[!RFC5988]].
</ins>
<p>
</p>
</dd>
<dt>
<del class="diff-old">Member
inlining
</del>
<dfn>
<ins class="diff-chg">previous
page
link
</ins>
</dfn>
</dt>
<dd>
A
<del class="diff-old">special
case
of
</del>
<ins class="diff-chg">link
to
the
previous
</ins><a title="Single-page resource"><ins class="diff-chg">
single-page
</ins>
resource
<del class="diff-old">inlining
,
where
all
members
</del>
</a>
of
a
<del class="diff-old">container
on
</del>
<a title="Paged resource">
<ins class="diff-chg">paged
resource
</ins></a><var><ins class="diff-chg">
P
</ins></var>.<ins class="diff-chg">
Syntactically,
</ins>
a
<del class="diff-old">given
page
are
inlined.
The
response
page
may
or
may
not
include
all
of
</del>
<ins class="diff-chg">HTTP
</ins><code><ins class="diff-chg">
Link
&lt;
</ins><var><ins class="diff-chg">
P
</ins><sub><ins class="diff-chg">
i
</ins></sub></var><ins class="diff-chg">
&gt;;
rel='prev'
</ins></code><ins class="diff-chg">
header
[[!RFC5988]]
where
</ins>
the
<del class="diff-old">container's
members.
See
section
5.10
for
details.
</del>
<ins class="diff-chg">target
URI
is
</ins><var><ins class="diff-chg">
P
</ins><sub><ins class="diff-chg">
i=1...n-1
</ins></sub></var>.
<p>
</p>
</dd>
</dl>
<del class="diff-old">2.1
</del>
<section id="conventions">
<h2>
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: &nbsp;  &nbsp;&lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
	@prefix rdfs: &nbsp; &nbsp;&lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
	@prefix ldp: &nbsp; &nbsp; &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix
xsd:
&nbsp;
&nbsp;&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 foaf:     &lt;http://xmlns.com/foaf/0.1/&gt;.
        @prefix rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
        @prefix ldp:     &lt;http://www.w3.org/ns/ldp#&gt;.
        @prefix xsd:     &lt;http://www.w3.org/2001/XMLSchema#&gt;.
</ins>
</pre>
</section>
</section>
<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
[
RFC2119
].
</del>
<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>
<del class="diff-old">informative
</del>
<ins class="diff-chg">non-normative
</ins>
</b>
</li>
<li>
2.
Terminology:
<b>
normative
</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>
6.
HTTP
Header
Definitions:
<b>
normative
</b>
</li>
<li>
A.
Acknowledgements:
<b>
<del class="diff-old">informative
</del>
<ins class="diff-chg">non-normative
</ins>
</b>
</li>
<li>
B.1
Normative
references:
<b>
normative
</b>
</li>
<li>
B.2
<del class="diff-old">Informative
</del>
<ins class="diff-chg">Non-normative
</ins>
references:
<b>
<del class="diff-old">informative
</del>
<ins class="diff-chg">non-normative
</ins>
</b>
</li>
</ul>
<p>
A
conforming
<b>
<dfn>
LDP
<del class="diff-old">server
</del>
<ins class="diff-chg">client
</ins></dfn>
</b>
is
<del class="diff-old">an
application
program
that
processes
HTTP
requests
and
generates
</del>
<ins class="diff-chg">a
conforming
</ins>
HTTP
<del class="diff-old">responses
</del>
<ins class="diff-chg">client
[[!HTTP11]]
</ins>
that
<del class="diff-old">conform
to
</del>
<ins class="diff-chg">follows
</ins>
the
rules
defined
<ins class="diff-new">by
LDP
</ins>
in
<del class="diff-old">section
4.
Linked
Data
Platform
Resources
and
section
5.
Linked
Data
Platform
Containers
</del>
<a href="#ldpclient" class="sectionRef">
</a>.
</p>
<p>
A
conforming
<b>
<dfn>
LDP
<del class="diff-old">client
</del>
<ins class="diff-chg">server
</ins></dfn>
</b>
is
<del class="diff-old">an
application
program
that
generates
HTTP
requests
and
processes
</del>
<ins class="diff-chg">a
conforming
</ins>
HTTP
<del class="diff-old">responses
</del>
<ins class="diff-chg">server
[[!HTTP11]]
</ins>
that
<del class="diff-old">conform
to
</del>
<ins class="diff-chg">follows
</ins>
the
rules
defined
<ins class="diff-new">by
LDP
</ins>
in
<del class="diff-old">section
4.
Linked
Data
Platform
Resources
</del>
<a href="#ldpr" class="sectionRef">
</a>
<ins class="diff-new">when
it
is
serving
LDPRs,
</ins>
and
<del class="diff-old">section
5.
</del>
<ins class="diff-chg">also
</ins><a href="#ldpc" class="sectionRef"></a><ins class="diff-chg">
when
it
is
serving
LDPCs.
LDP
does
not
constrain
its
behavior
when
serving
other
HTTP
resources.
</ins></p></section><section id="ldpclient"><h1>
Linked
Data
Platform
<del class="diff-old">Containers
</del>
<ins class="diff-chg">Clients
</ins></h1><p><ins class="diff-chg">
All
of
the
following
are
conformance
rules
for
</ins><a title="LDP server"><ins class="diff-chg">
LDP
Clients
</ins>
</a>.
</p>
<section>
<h2>
<ins class="diff-new">General
</ins></h2><section id="ldp-cli-multitype"><h2 class="normal"><ins class="diff-new">
In
the
absence
of
special
knowledge
of
the
application
or
domain,
</ins><a title="LDP client"><ins class="diff-new">
LDP
clients
</ins></a><ins class="diff-new">
MUST
assume
that
any
LDP-RR
can
have
multiple
values
for
</ins><code><ins class="diff-new">
rdf:type
</ins></code>.</h2>
</section>
<section id="ldpr-cli-typeschange">
<h2 class="normal">
<ins class="diff-chg">In
the
absence
of
special
knowledge
of
the
application
or
domain,
</ins><a title="LDP client"><ins class="diff-chg">
LDP
clients
</ins></a><ins class="diff-chg">
MUST
assume
that
the
</ins><code><ins class="diff-chg">
rdf:type
</ins></code><ins class="diff-chg">
values
of
a
given
LDP-RR
can
change
over
time.
</ins></h2></section><section id="ldpr-cli-openpreds"><h2 class="normal">
<del class="diff-old">4.
</del>
<a title="LDP client">
<ins class="diff-chg">LDP
clients
</ins></a><ins class="diff-chg">
SHOULD
always
assume
that
the
set
of
predicates
for
a
LDP-RR
of
a
particular
type
at
an
arbitrary
server
is
open,
in
the
sense
that
different
resources
of
the
same
type
may
not
all
have
the
same
set
of
predicates
in
their
triples,
and
the
set
of
predicates
that
are
used
in
the
state
of
any
one
LDP-RR
is
not
limited
to
any
pre-defined
set.
</ins></h2></section><section id="ldpr-cli-preservetriples"><h2 class="normal"><ins class="diff-chg">
A
</ins><a title="LDP client"><ins class="diff-chg">
LDP
client
</ins></a><ins class="diff-chg">
MUST
preserve
all
triples
retrieved
from
an
LDP-RR
using
HTTP
</ins><code><ins class="diff-chg">
GET
</ins></code><ins class="diff-chg">
that
it
doesn’t
change
whether
it
understands
the
predicates
or
not,
when
its
intent
is
to
perform
an
update
using
HTTP
</ins><code><ins class="diff-chg">
PUT
</ins></code>.<ins class="diff-chg">
&#160;The
use
of
HTTP
</ins><code><ins class="diff-chg">
PATCH
</ins></code><ins class="diff-chg">
instead
of
HTTP
</ins><code><ins class="diff-chg">
PUT
</ins></code><ins class="diff-chg">
for
update
avoids
this
burden
for
clients
[[RFC5789]].
</ins></h2></section><section id="ldpr-cli-can-hint"><h2 class="normal"><a title="LDP client"><ins class="diff-chg">
LDP
clients
</ins></a><ins class="diff-chg">
MAY
provide
LDP-defined
hints
that
allow
servers
to
optimize
the
content
of
responses.
</ins><a href="#prefer-parameters" class="sectionRef"></a><ins class="diff-chg">
defines
hints
that
apply
to
</ins><a title="Linked Data Platform RDF Resource"><ins class="diff-chg">
LDP-RRs
</ins></a>.</h2></section><section id="ldpr-cli-hints-ignorable"><h2 class="normal"><a title="LDP client"><ins class="diff-chg">
LDP
clients
</ins></a><ins class="diff-chg">
MUST
be
capable
of
processing
responses
formed
by
an
LDP
server
that
ignores
hints,
including
LDP-defined
hints.
</ins></h2></section></section></section><section id="ldpr"><h1>
Linked
Data
Platform
Resources
</h1>
<section class="informative" id="ldpr-informative">
<h2>
<ins class="diff-new">Introduction
</ins>
</h2>
<del class="diff-old">4.1
Informative
This
section
is
non-normative.
</del>
<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
<del class="diff-old">LDPR
servers.
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
servers
</ins></a>.
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
representations
should
be
used?
</li>
<li>
How
is
optimistic
collision
detection
handled
for
updates?
</li>
<li>
What
should
client
expectations
be
for
changes
to
linked-to
resources,
such
as
type
changes?
</li>
<li>
What
can
servers
do
to
ease
the
burden
of
constraints
for
resource
creation?
</li>
<li>
How
do
I
GET
the
<del class="diff-old">entries
</del>
<ins class="diff-chg">representation
</ins>
of
a
large
<del class="diff-old">resources
</del>
<ins class="diff-chg">resource
</ins>
broken
up
into
pages?
</li>
</ul>
<p>
Additional
<del class="diff-old">informative
</del>
<ins class="diff-chg">non-normative
</ins>
guidance
is
available
<del class="diff-old">on
</del>
<ins class="diff-chg">in
</ins>
the
<del class="diff-old">working
group's
wiki
</del>
<a href="https://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp-bp/ldp-bp.html" class="external" title="LDP Best Practices and Guidelines" rel="nofollow">
<ins class="diff-chg">LDP
Best
Practices
and
Guidelines
editor's
draft
</ins>
</a>
that
addresses
<del class="diff-old">deployment
</del>
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
<ins class="diff-new">conformance
</ins>
rules
<del class="diff-old">and
guidelines
</del>
for
<del class="diff-old">use
of
LDPRs
.
</del>
<ins class="diff-chg">LDP
servers
when
serving
LDPRs.
</ins>
This
document
also
explains
<a href="#ldpr-Paging">
how
<del class="diff-old">to
include
information
about
each
member
in
the
resource’s
own
representation
and
how
to
paginate
the
resource
</del>
<ins class="diff-chg">a
server
paginates
an
LDP-RR's
</ins>
representation
</a>
if
it
gets
too
big.
<ins class="diff-new">Companion
non-normative
documents
describe
additional
guidelines
for
use
when
interacting
with
LDPRs.
</ins>
</p>
<p>
<ins class="diff-chg">An
LDP
server
manages
two
kinds
of
</ins><a title="Linked Data Platform Resources"><ins class="diff-chg">
LDPRs
</ins></a>,<ins class="diff-chg">
those
resources
who
whose
state
is
represented
using
RDF
(LDP-RR)
and
those
using
other
formats
(LDP-BR).
LDP-RRs
have
the
unique
quality
that
their
representation
is
based
on
RDF,
which
addresses
a
number
of
use
cases
from
web
metadata,
open
data
models,
machine
processable
information,
and
automated
processing
by
software
agents
[[!RDF-CONCEPTS]].
LDP-BRs
are
almost
anything
on
the
Web
today:
images,
HTML
pages,
word
processing
documents,
spreadsheets,
etc.
and
LDP-RRs
hold
metadata
associated
with
LDP-BRs
in
some
cases.
</ins></p><figure id="fig-ldpr-types">
<del class="diff-old">4.2
</del>
<img src="images/ldpr1.png" alt="Sample separation of Linked Data Platform Resource" />
<figcaption>
<ins class="diff-chg">Samples
of
different
types
of
LDPRs
</ins></figcaption></figure><p><ins class="diff-chg">
The
LDP-BRs
and
LDP-RRs
are
simply
sub-types
of
LDPRs,
as
illustrated
in
</ins><a href="#fig-ldpr-class"></a>.</p><figure id="fig-ldpr-class"><img src="images/ldpr2.png" alt="Class Diagram of Linked Data Platform Resource" /><figcaption><ins class="diff-chg">
Class
relationship
of
types
of
LDPRs
</ins></figcaption></figure></section><section id="ldpr-general"><h2>
General
<del class="diff-old">4.2.1
LDPR
</del>
</h2>
<section id="ldpr-gen-http">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MUST
at
least
be
HTTP/1.1
conformant
servers
<del class="diff-old">[
HTTP11
</del>
<ins class="diff-chg">[[!HTTP11]].
</ins></h2></section><section id="ldpr-gen-rdf"><h2 class="normal">
<del class="diff-old">].
4.2.2
LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MUST
provide
an
RDF
representation
for
<del class="diff-old">LDPRs
.
</del>
<a title="Linked Data Platform RDF Resource">
<ins class="diff-chg">LDP-RRs
</ins></a>.
The
HTTP
<code>
Request-URI
</code>
of
the
<del class="diff-old">LDPR
</del>
<ins class="diff-chg">LDP-RR
</ins>
is
typically
the
subject
of
most
triples
in
the
response.
<del class="diff-old">4.2.3
LDPR
</del>
</h2>
</section>
<section id="ldpr-gen-binary">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MAY
host
a
mixture
of
<del class="diff-old">LDPRs
</del>
<ins class="diff-chg">LDPRs,
</ins><a title="Linked Data Platform RDF Resource"><ins class="diff-chg">
LDP-RRs
</ins></a>
and
<del class="diff-old">non-
LDPRs
.
</del>
<a title="Linked Data Platform Binary Resource">
<ins class="diff-chg">LDP-BRs
</ins></a>.
For
example,
it
is
common
for
<del class="diff-old">LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
to
need
to
host
binary
or
text
resources
that
do
not
have
useful
RDF
representations.
<del class="diff-old">4.2.4
LDPRs
</del>
</h2>
</section>
<section id="ldpr-gen-reusevocab">
<h2 class="normal">
<a title="Linked Data Platform RDF Resource">
<ins class="diff-chg">LDP-RRs
</ins></a>
SHOULD
reuse
existing
vocabularies
instead
of
creating
their
own
duplicate
vocabulary
terms.
In
addition
to
this
general
rule,
some
specific
cases
are
covered
by
other
conformance
rules.
<del class="diff-old">4.2.4.1
LDPR
</del>
</h2>
</section>
<section id="ldpr-gen-reusevocabsuchas">
<h2 class="normal">
<a title="Linked Data Platform RDF Resource">
<ins class="diff-chg">LDP-RRs
</ins></a>
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-CONCEPTS
]
</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.
<del class="diff-old">4.2.5
LDPR
</del>
</h2>
</section>
<section id="ldpr-gen-atleast1rdftype">
<h2 class="normal">
<a title="Linked Data Platform RDF Resource">
<ins class="diff-chg">LDP-RRs
</ins></a>
representations
SHOULD
have
at
least
one
<code>
rdf:type
</code>
set
explicitly.
<del class="diff-old">&nbsp;This
</del>
<ins class="diff-chg">&#160;This
</ins>
makes
the
representations
much
more
useful
to
client
applications
that
don’t
support
inferencing.
<del class="diff-old">4.2.6
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
non-
RDF
formats
like
HTML
[
HTML401
]
and
JSON
[
RFC4627
]
would
likely
be
common.
4.2.7
LDPRs
MAY
be
created,
updated
and
deleted
using
methods
not
defined
in
this
document,
for
example
through
application-specific
means,
SPARQL
UPDATE,
etc.
[
SPARQL-UPDATE
</del>
</h2>
</section>
<section id="ldpr-gen-etags">
<h2 class="normal">
<del class="diff-old">],
as
long
as
those
methods
do
not
conflict
with
this
specification's
normative
requirements.
4.2.8
LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
server
</a>
responses
MUST
use
entity
tags
(either
weak
or
strong
ones)
as
response
<code>
ETag
</code>
header
values.
<del class="diff-old">4.2.9
LDPR
</del>
</h2>
</section>
<section id="ldpr-gen-linktypehdr">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
<del class="diff-old">SHOULD
enable
simple
creation
and
modification
of
</del>
</a>
<ins class="diff-chg">exposing
</ins>
LDPRs
<del class="diff-old">.
It
is
common
for
LDPR
servers
to
put
restrictions
on
representations

for
example,
the
range
of
rdf:type
predicates,
datatypes
of
the
objects
of
predicates,
and
the
number
of
occurrences
of
predicates
in
an
LDPR
,
but
servers
SHOULD
minimize
those
restrictions.
&nbsp;Enforcement
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.
4.2.10
LDPR
servers
</del>
MUST
advertise
their
LDP
support
by
exposing
a
HTTP
<code>
Link
</code>
header
with
a
target
URI
of
<code>
<del class="diff-old">http://www.w3.org/ns/ldp/Resource
</del>
<ins class="diff-chg">http://www.w3.org/ns/ldp#Resource
</ins>
</code>,
and
a
link
relation
type
of
<code>
type
</code>
(that
is,
<code>
<del class="diff-old">rel="type"
</del>
<ins class="diff-chg">rel='type'
</ins>
</code>
)
in
all
responses
to
requests
made
to
the
<del class="diff-old">resource's
</del>
<ins class="diff-chg">LDPR's
</ins>
HTTP
<code>
Request-URI
</code>.
<del class="diff-old">This
is
notionally
equivalent
to
the
presence
of
a
(subject-URI,
rdf:type
,
ldp:Resource
)
triple
in
the
resource.
</del>
</h2>
</section>
<blockquote>
<p>
<ins class="diff-chg">Note:
</ins>
The
HTTP
<code>
Link
</code>
header
is
the
method
by
which
servers
assert
their
support
for
the
LDP
specification
<ins class="diff-new">on
a
specific
resource
</ins>
in
a
way
that
clients
can
<del class="diff-old">introspect
</del>
<ins class="diff-chg">inspect
</ins>
dynamically
at
run-time.
<del class="diff-old">Conservative
clients
should
note
that
</del>
<ins class="diff-chg">This
is
</ins><strong><ins class="diff-chg">
not
</ins></strong><ins class="diff-chg">
equivalent
to
the
presence
of
</ins>
a
<var>
<ins class="diff-new">(subject-URI,
</ins><code><ins class="diff-new">
rdf:type
</ins></code>,<code><ins class="diff-new">
ldp:Resource
</ins></code><ins class="diff-new">
)
</ins></var><ins class="diff-new">
triple
in
an
RDF
resource.
The
presence
of
this
header
asserts
that
the
server
complies
with
the
LDP
specification's
constraints
on
HTTP
interactions
with
LDPRs,
that
is
it
asserts
that
the
resource
</ins><a href="#ldpr-gen-tags"><ins class="diff-new">
has
Etags
</ins></a>,<a href="#ldpr-gen-rdf"><ins class="diff-new">
has
an
RDF
representation
</ins></a>,<ins class="diff-new">
and
so
on,
which
is
not
true
of
all
Web
resources
served
as
RDF
media
types.
</ins></p><p><ins class="diff-new">
Note:
</ins><a href="#ldpr-gen-binary"><ins class="diff-new">
A
LDP
</ins>
server
can
host
a
mixture
of
LDPRs
and
other
resources
</a>,
and
therefore
there
is
no
implication
that
LDP
support
advertised
on
one
HTTP
<code>
Request-URI
</code>
means
that
other
resources
on
the
same
server
are
also
<del class="diff-old">LDPRs
.
</del>
<ins class="diff-chg">LDPRs.
</ins>
Each
HTTP
<code>
Request-URI
</code>
needs
to
be
individually
<del class="diff-old">introspected
by
a
conservative
client,
</del>
<ins class="diff-chg">inspected,
</ins>
in
the
absence
of
outside
information.
<del class="diff-old">4.2.11
LDPR
</del>
</p>
</blockquote>
<section id="ldpr-gen-noinferencing">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
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
<del class="diff-old">[
RDF-CONCEPTS
].
</del>
<ins class="diff-chg">[[!RDF-CONCEPTS]].
</ins>
The
practical
implication
is
that
all
content
defined
by
LDP
must
be
explicitly
represented.
<del class="diff-old">4.2.12
LDPR
</del>
</h2>
</section>
<section id="ldpr-gen-defbaseuri">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MUST
assign
the
default
base-URI
for
<del class="diff-old">[
RFC3987
]
</del>
<ins class="diff-chg">[[!RFC3987]]
</ins>
relative-URI
resolution
to
be
the
HTTP
<code>
Request-URI
</code>
when
the
resource
already
exists,
and
to
the
URI
of
the
created
resource
when
the
request
results
in
the
creation
of
a
new
resource.
</h2>
</section>
<section id="ldpr-gen-pubclireqs">
<h2 class="normal">
<del class="diff-old">4.3
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
servers
</ins></a><ins class="diff-chg">
MUST
publish
any
constraints
on
</ins><a title="LDP client"><ins class="diff-chg">
LDP
clients’
</ins></a><ins class="diff-chg">
ability
to
create
or
update
LDPRs,
by
adding
a
Link
header
with
</ins><code><ins class="diff-chg">
rel='describedby'
</ins></code><ins class="diff-chg">
[[!POWDER-DR]]
to
all
responses
to
requests
which
fail
due
to
violation
of
those
constraints.
For
example,
a
server
that
refuses
resource
creation
requests
via
HTTP
PUT,
POST,
or
PATCH
would
return
this
</ins><code><ins class="diff-chg">
Link
</ins></code><ins class="diff-chg">
header
on
its
4xx
responses
to
such
requests.
The
same
</ins><code><ins class="diff-chg">
Link
</ins></code><ins class="diff-chg">
header
MAY
be
provided
on
other
responses.
LDP
neither
defines
nor
constrains
the
representation
of
the
link's
target
resource;
as
stated
in
[[POWDER-DR]],
the
target
might
(or
might
not)
be
a
POWDER
document.
Natural
language
constraint
documents
are
therefore
permitted,
although
machine-readable
ones
facilitate
better
client
interactions.
</ins></h2></section><section id="ldpr-page-large"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
SHOULD
allow
clients
to
retrieve
large
LDP-RRs
in
pages.
See
</ins><a href="#ldpr-Paging" class="sectionRef"></a><ins class="diff-chg">
for
additional
requirements
associated
with
</ins><a title="Paged resource"><ins class="diff-chg">
paged
resources
</ins></a>.</h2></section><section id="ldpr-split-any"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
MAY
treat
any
resource
(LDP-RR
or
not)
as
a
</ins><a title="Paged resource"><ins class="diff-chg">
paged
resource
</ins></a>.<ins class="diff-chg">
See
</ins><a href="#ldpr-Paging" class="sectionRef"></a><ins class="diff-chg">
for
additional
details.
</ins></h2></section></section><section id="ldpr-HTTP_GET"><h2>
HTTP
GET
<del class="diff-old">4.3.1
LDPR
</del>
</h2>
<section id="ldpr-get-must">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MUST
support
the
HTTP
<code>
GET
</code>
Method
for
<del class="diff-old">LDPRs
.
4.3.2
LDPR
</del>
<ins class="diff-chg">LDPRs.
</ins></h2></section><section id="ldpr-get-options"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
</ins>
servers
</a>
MUST
support
the
HTTP
response
headers
defined
in
<a href="#ldpr-HTTP_OPTIONS" class="sectionRef">
<del class="diff-old">section
4.9
</del>
</a>.
<del class="diff-old">4.3.3
LDPR
</del>
</h2>
</section>
<section id="ldpr-get-turtle">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
<del class="diff-old">SHOULD
</del>
</a>
<ins class="diff-chg">MUST
</ins>
provide
a
<code>
text/turtle
</code>
representation
of
the
requested
<del class="diff-old">LDPR
[
TURTLE
].
4.3.4
LDPR
servers
MAY
provide
representations
of
the
requested
LDPR
beyond
those
necessary
to
conform
to
this
specification,
using
standard
HTTP
content
negotiation
([
HTTP11
</del>
<a title="Linked Data Platform RDF Resource">
<ins class="diff-chg">LDP-RR
</ins>
</a>
<del class="diff-old">]
Section
12
-
Content
Negotiation).
If
the
client
does
not
indicate
a
preference,
text/turtle
SHOULD
be
returned.
4.3.5
In
the
absence
of
special
knowledge
of
the
application
or
domain,
LDPR
clients
MUST
assume
that
any
LDPR
can
have
multiple
values
for
rdf:type
.
4.3.6
In
the
absence
of
special
knowledge
of
the
application
or
domain,
LDPR
clients
MUST
assume
that
the
rdf:type
values
of
a
given
LDPR
can
change
over
time.
</del>
<ins class="diff-chg">[[!TURTLE]].
</ins></h2>
</section>
<del class="diff-old">4.4
</del>
</section>
<section id="ldpr-HTTP_POST">
<h2>
HTTP
POST
</h2>
<p>
This
specification
adds
no
new
requirements
on
HTTP
<code>
POST
</code>
for
LDPRs
even
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>
<del class="diff-old">Creation
of
LDPRs
</del>
<ins class="diff-chg">Clients
</ins>
can
<del class="diff-old">be
done
</del>
<ins class="diff-chg">create
LDPRs
</ins>
via
<code>
POST
</code>
(
<a href="#ldpc-HTTP_POST" class="sectionRef">
<del class="diff-old">section
5.4
</del>
</a>
)
or
<code>
PUT
</code>
(
<a href="#ldpc-HTTP_PUT" class="sectionRef">
<del class="diff-old">section
5.5
</del>
</a>
)
to
a
<del class="diff-old">LDPC
,
</del>
<ins class="diff-chg">LDPC,
</ins>
see
those
sections
for
more
details.
<ins class="diff-new">Any
server-imposed
constraints
on
LDPR
creation
or
update
</ins><a href="#ldpr-gen-pubclireqs"><ins class="diff-new">
must
be
advertised
</ins></a><ins class="diff-new">
to
clients.
</ins>
</p>
</section>
<del class="diff-old">4.5
</del>
<section id="ldpr-HTTP_PUT">
<h2>
HTTP
PUT
</h2>
<p>
<del class="diff-old">This
</del>
<ins class="diff-chg">Per
[HTTP11],
this
HTTP
method
is
optional
and
this
specification
does
not
require
</ins><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
to
support
it.
When
a
LDP
server
chooses
to
support
this
method,
this
</ins>
specification
imposes
the
following
new
requirements
<del class="diff-old">on
HTTP
PUT
</del>
for
<del class="diff-old">LDPRs
only
when
the
</del>
<ins class="diff-chg">LDPRs.
</ins></p><p><ins class="diff-chg">
Any
server-imposed
constraints
on
</ins>
LDPR
<del class="diff-old">supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
[
HTTP11
</del>
<ins class="diff-chg">creation
or
update
</ins><a href="#ldpr-gen-pubclireqs"><ins class="diff-chg">
must
be
advertised
</ins>
</a>
<del class="diff-old">]
makes
it
optional.
</del>
<ins class="diff-chg">to
clients.
</ins>
</p>
<del class="diff-old">4.5.1
</del>
<section id="ldpr-put-replaceall">
<h2 class="normal">
If
<ins class="diff-new">a
</ins>
HTTP
<code>
PUT
</code>
is
<del class="diff-old">performed
</del>
<ins class="diff-chg">accepted
</ins>
on
an
existing
resource,
<del class="diff-old">LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MUST
replace
the
entire
persistent
state
of
the
identified
resource
with
the
entity
representation
in
the
body
of
the
request.
<del class="diff-old">LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MAY
ignore
server
managed
properties
such
as
<code>
dcterms:modified
</code>
and
<code>
dcterms:creator
</code>
if
they
are
not
under
client
control.
Any
<del class="diff-old">LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
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
<code>
PATCH
</code>,
not
HTTP
<code>
PUT
</code>.
<del class="diff-old">4.5.2
LDPR
</del>
</h2>
</section>
<section id="ldpr-put-servermanagedprops">
<h2 class="normal">
<ins class="diff-chg">If
an
otherwise
valid
HTTP
</ins><code><ins class="diff-chg">
PUT
</ins></code><ins class="diff-chg">
request
is
received
that
attempts
to
change
triples
the
server
does
not
allow
</ins>
clients
<ins class="diff-chg">to
modify,
</ins><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
MUST
respond
with
a
4xx
range
status
code
(typically
409
Conflict).
</ins><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
SHOULD
provide
a
corresponding
response
body
containing
information
about
which
triples
could
not
be
persisted.
The
format
of
the
4xx
response
body
is
not
constrained
by
LDP.
</ins></h2></section><blockquote><ins class="diff-chg">
Non-normative
note:
Clients
might
provide
triples
equivalent
to
those
already
in
the
resource's
state,
e.g.
as
part
of
a
GET/update
representation/PUT
sequence,
and
those
PUT
requests
are
intended
to
work
as
long
as
the
server-controlled
triples
are
identical
on
the
GET
response
and
the
subsequent
PUT
request.
</ins></blockquote><section id="ldpr-put-precond"><h2 class="normal"><a title="LDP client"><ins class="diff-chg">
LDP
clients
</ins></a>
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.
<del class="diff-old">LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
SHOULD
require
the
HTTP
<code>
If-Match
</code>
header
and
HTTP
<code>
ETags
</code>
to
detect
collisions.
<del class="diff-old">LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MUST
respond
with
status
code
412
(Condition
Failed)
if
<code>
ETag
</code>
s
fail
to
match
when
there
are
no
other
errors
with
the
request
<del class="diff-old">[
HTTP11
].
LDPR
</del>
<ins class="diff-chg">[[!HTTP11]].
</ins><a title="LDP server"><ins class="diff-chg">
LDP
</ins>
servers
</a>
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
<del class="diff-old">[
RFC6585
].
4.5.3
LDPR
clients
SHOULD
always
assume
that
the
set
of
predicates
for
a
resource
of
a
particular
type
at
</del>
<ins class="diff-chg">[[!RFC6585]].
</ins></h2></section><section id="ldpr-put-failed"><h2 class="normal"><ins class="diff-chg">
If
</ins>
an
<del class="diff-old">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
</del>
<ins class="diff-chg">otherwise
valid
HTTP
</ins><code><ins class="diff-chg">
PUT
</ins></code><ins class="diff-chg">
request
</ins>
is
<del class="diff-old">not
limited
to
any
pre-defined
set.
4.5.4
LDPR
clients
SHOULD
assume
</del>
<ins class="diff-chg">received
</ins>
that
<del class="diff-old">an
LDPR
server
could
discard
</del>
<ins class="diff-chg">contains
</ins>
triples
<del class="diff-old">whose
predicates
</del>
the
server
<del class="diff-old">does
not
recognize
or
otherwise
</del>
chooses
not
to
<del class="diff-old">persist.
In
other
words,
LDPR
</del>
<ins class="diff-chg">persist,
e.g.
unknown
content,
</ins><a title="LDP server"><ins class="diff-chg">
LDP
</ins>
servers
<del class="diff-old">MAY
restrict
themselves
to
a
known
set
of
predicates,
but
LDPR
clients
</del>
</a>
MUST
<del class="diff-old">NOT
restrict
themselves
to
a
known
set
of
predicates
when
their
intent
is
to
perform
</del>
<ins class="diff-chg">respond
with
an
appropriate
4xx
range
status
code
[[HTTP11]].
</ins><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
SHOULD
provide
</ins>
a
<del class="diff-old">later
HTTP
PUT
to
update
the
resource.
4.5.5
An
LDPR
client
MUST
preserve
all
</del>
<ins class="diff-chg">corresponding
response
body
containing
information
about
which
</ins>
triples
<del class="diff-old">retrieved
using
HTTP
GET
that
it
doesn’t
change
whether
it
understands
</del>
<ins class="diff-chg">could
not
be
persisted.
The
format
of
</ins>
the
<del class="diff-old">predicates
or
not,
when
its
intent
</del>
<ins class="diff-chg">4xx
response
body
</ins>
is
<del class="diff-old">to
perform
an
update
using
HTTP
PUT
.
&nbsp;The
use
of
HTTP
PATCH
instead
of
HTTP
PUT
for
update
avoids
this
burden
for
clients
[
RFC5789
</del>
<ins class="diff-chg">not
constrained
by
LDP.
</ins></h2></section><section id="ldpr-put-create"><h2 class="normal">
<del class="diff-old">].
4.5.6
LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MAY
choose
to
allow
the
creation
of
new
resources
using
HTTP
<code>
PUT
</code>.
<del class="diff-old">4.5.7
LDPR
</del>
</h2>
</section>
<section id="ldpr-put-simpleupdate">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
SHOULD
allow
clients
to
update
resources
without
requiring
detailed
knowledge
of
server-specific
constraints.
<del class="diff-old">&nbsp;
</del>
<ins class="diff-chg">&#160;
</ins>
This
is
a
consequence
of
the
requirement
to
enable
simple
creation
and
modification
of
<del class="diff-old">LPDRs.
</del>
<ins class="diff-chg">LDPRs.
</ins></h2>
</section>
<del class="diff-old">4.6
</del>
</section>
<section id="ldpr-HTTP_DELETE">
<h2>
HTTP
DELETE
</h2>
<p>
<del class="diff-old">This
specification
imposes
the
following
new
requirements
on
</del>
<ins class="diff-chg">Per
[HTTP11],
this
</ins>
HTTP
<del class="diff-old">DELETE
for
LDPRs
only
when
the
LDPR
supports
that
method.
This
</del>
<ins class="diff-chg">method
is
optional
and
this
</ins>
specification
does
not
<del class="diff-old">impose
any
new
requirement
</del>
<ins class="diff-chg">require
</ins><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a>
to
support
<del class="diff-old">that
</del>
<ins class="diff-chg">it.
When
a
LDP
server
chooses
to
support
this
</ins>
method,
<del class="diff-old">and
[
HTTP11
]
makes
it
optional.
</del>
<ins class="diff-chg">this
specification
imposes
the
following
new
requirements
for
LDPRs.
</ins>
</p>
<p>
Additional
requirements
on
HTTP
<code>
DELETE
</code>
of
LDPRs
within
containers
can
be
found
in
<a href="#ldpc-HTTP_DELETE" class="sectionRef">
<del class="diff-old">section
5.6
</del>
</a>.
</p>
<del class="diff-old">4.6.1
LDPR
servers
MUST
remove
the
resource
identified
by
the
Request-URI
.
After
a
successful
HTTP
DELETE
,
a
subsequent
HTTP
GET
on
the
same
Request-URI
MUST
result
in
a
404
(Not
found)
or
410
(Gone)
status
code.
Clients
SHOULD
note
that
servers
MAY
reuse
a
URI
under
some
circumstances.
4.6.2
LDPR
servers
MAY
alter
the
state
of
other
resources
as
a
result
of
an
HTTP
DELETE
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.
</del>
</section>
<del class="diff-old">4.7
</del>
<section id="ldpr-HTTP_HEAD">
<h2>
HTTP
HEAD
</h2>
<p>
Note
that
certain
LDP
mechanisms,
such
as
<del class="diff-old">paging,
</del>
<a href="#ldpr-Paging">
<ins class="diff-chg">paging
</ins></a>,
rely
on
HTTP
headers,
and
HTTP
generally
requires
that
<code>
HEAD
</code>
responses
include
the
same
headers
as
<code>
GET
</code>
responses.
Thus,
implementers
should
also
carefully
read
<del class="diff-old">section
4.3
</del>
<ins class="diff-chg">sections
</ins><a href="#ldpr-HTTP_GET">
</a>
and
<del class="diff-old">section
4.9
</del>
<a href="#ldpr-HTTP_OPTIONS">
</a>.
</p>
<del class="diff-old">4.7.1
LDPR
</del>
<section id="ldpr-head-must">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MUST
support
the
HTTP
<code>
HEAD
</code>
method.
</h2>
</section>
<del class="diff-old">4.8
</del>
</section>
<section id="ldpr-HTTP_PATCH">
<h2>
HTTP
PATCH
</h2>
<p>
<del class="diff-old">This
specification
imposes
the
following
new
requirements
on
</del>
<ins class="diff-chg">Per
[HTTP11],
this
</ins>
HTTP
<del class="diff-old">PATCH
for
LDPRs
only
when
the
LDPR
supports
that
method.
This
</del>
<ins class="diff-chg">method
is
optional
and
this
</ins>
specification
does
not
<del class="diff-old">impose
any
new
requirement
</del>
<ins class="diff-chg">require
</ins><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a>
to
support
<del class="diff-old">that
</del>
<ins class="diff-chg">it.
When
a
LDP
server
chooses
to
support
this
</ins>
method,
<del class="diff-old">and
[
HTTP11
]
makes
it
optional.
</del>
<ins class="diff-chg">this
specification
imposes
the
following
new
requirements
for
LDPRs.
</ins>
</p>
<del class="diff-old">4.8.1
</del>
<p>
<ins class="diff-chg">Any
server-imposed
constraints
on
</ins>
LDPR
<del class="diff-old">servers
MAY
implement
HTTP
PATCH
to
allow
modifications,
especially
partial
replacement,
of
their
resources
[
RFC5789
</del>
<ins class="diff-chg">creation
or
update
</ins><a href="#ldpr-gen-pubclireqs"><ins class="diff-chg">
must
be
advertised
</ins>
</a>
<ins class="diff-new">to
clients.
</ins></p><section id="ldpr-patch-create"><h2 class="normal">
<del class="diff-old">].
No
minimal
set
of
patch
document
formats
is
mandated
by
this
document.
4.8.2
LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
<del class="diff-old">SHOULD
allow
clients
to
update
resources
without
requiring
detailed
knowledge
of
server-specific
constraints.
&nbsp;
This
is
a
consequence
of
the
requirement
to
enable
simple
creation
and
modification
</del>
</a>
<del class="diff-old">of
LPDRs.
4.8.3
LDPR
servers
</del>
SHOULD
NOT
allow
clients
to
create
new
resources
using
<code>
PATCH
</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="#ldpr-HTTP_PUT">
<code>
PUT
</code>
</a>
should
be
used
as
the
standard
way
to
create
new
<del class="diff-old">LDPRs
.
4.8.4
LDPR
</del>
<ins class="diff-chg">LDPRs.
</ins></h2></section><section id="ldpr-patch-acceptpatch"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
</ins>
servers
</a>
that
support
<code>
PATCH
</code>
MUST
include
an
<code>
Accept-Patch
</code>
HTTP
response
header
<del class="diff-old">[
RFC5789
]
</del>
<ins class="diff-chg">[[!RFC5789]]
</ins>
on
HTTP
<code>
OPTIONS
</code>
requests,
listing
patch
document
media
type(s)
supported
by
the
server.
</h2>
</section>
<del class="diff-old">4.9
</del>
</section>
<section id="ldpr-HTTP_OPTIONS">
<h2>
HTTP
OPTIONS
</h2>
<p>
This
specification
imposes
the
following
new
requirements
on
HTTP
<code>
OPTIONS
</code>
for
LDPRs
beyond
those
in
<del class="diff-old">[
HTTP11
].
</del>
<ins class="diff-chg">[[!HTTP11]].
</ins>
Other
sections
of
this
specification,
for
example
<a href="#ldpr-HTTP_PATCH">
PATCH
</a>,
<a href="#header-accept-post">
Accept-Post
</a>
and
<a href="#ldpr-paging-HTTP_OPTIONS">
Paging
</a>,
add
other
requirements
on
<code>
OPTIONS
</code>
responses.
</p>
<del class="diff-old">4.9.1
LDPR
</del>
<section id="ldpr-options-must">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MUST
support
the
HTTP
<code>
OPTIONS
</code>
method.
<del class="diff-old">4.9.2
LDPR
</del>
</h2>
</section>
<section id="ldpr-options-allow">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MUST
indicate
their
support
for
HTTP
Methods
by
responding
to
a
HTTP
<code>
OPTIONS
</code>
request
on
the
<del class="diff-old">LDPR
’s
</del>
<ins class="diff-chg">LDPR’s
</ins>
URL
with
the
HTTP
Method
tokens
in
the
HTTP
response
header
<code>
Allow
</code>.
</h2>
</section>
<del class="diff-old">4.10
</del>
</section>
<section id="ldpr-Paging">
<h2>
Paging
<del class="diff-old">4.10.1
</del>
</h2>
<section class="informative" id="ldpr-PagingIntro">
<h3>
Introduction
<del class="diff-old">This
section
is
non-normative.
</del>
</h3>
<p>
It
sometimes
happens
that
a
resource
is
too
large
to
reasonably
transmit
its
representation
in
a
single
HTTP
response.
<del class="diff-old">This
will
be
especially
true
if
the
resource
representation
includes
many
triples
both
from
its
own
representation
and
from
the
representations
of
any
inlined
resources
.
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.
</del>
To
address
this
problem,
<del class="diff-old">LDPRs
</del>
<ins class="diff-chg">servers
</ins>
should
support
a
technique
called
Paging.
<del class="diff-old">&nbsp;Paging
can
be
achieved
with
</del>
<ins class="diff-chg">&#160;
When
a
client
retrieves
such
</ins>
a
<del class="diff-old">simple
RDF
pattern.
For
each
</del>
resource,
<del class="diff-old">&lt;resourceURL&gt;
,
we
define
</del>
<ins class="diff-chg">the
server
redirects
the
client
to
</ins>
a
<del class="diff-old">new
'first
page'
resource.
In
this
example,
</del>
<ins class="diff-chg">"first
page"
resource,
and
includes
in
</ins>
its
<del class="diff-old">URL
will
be
&lt;resourceURL&gt;?firstPage
,
but
servers
are
free
</del>
<ins class="diff-chg">response
a
link
</ins>
to
<del class="diff-old">construct
</del>
the
<del class="diff-old">URL
as
they
see
fit.
</del>
<ins class="diff-chg">next
part
of
the
resource's
state,
all
at
a
URLs
of
the
server's
choosing.
</ins>
The
triples
in
the
representation
of
the
<a title="Single-page resource">
each
page
<ins class="diff-new">of
an
LDPR
</ins></a>
are
typically
a
subset
of
the
triples
<del class="diff-old">in
</del>
<ins class="diff-chg">from
</ins>
the
<a title="Paged resource">
<ins class="diff-new">paged
</ins>
resource
<del class="diff-old">-
same
subject,
predicate
and
object.
</del>
</a>.
</p>
<p>
<del class="diff-old">LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
may
respond
to
requests
for
a
resource
by
redirecting
<del class="diff-old">the
client
</del>
to
the
first
page
<ins class="diff-new">of
the
</ins>
resource
<del class="diff-old">–
using
</del>
<ins class="diff-chg">and,
with
that,
returning
</ins>
a
<del class="diff-old">303
“See
Other”
redirect
to
</del>
<code>
<ins class="diff-chg">Link
&lt;next-page-URL&gt;;type='next'
</ins></code><ins class="diff-chg">
header
containing
</ins>
the
<del class="diff-old">actual
</del>
URL
for
the
<del class="diff-old">page
resource.
Alternatively,
clients
may
introspect
the
resource
</del>
<ins class="diff-chg">next
page.
Clients
inspect
each
response
</ins>
for
<del class="diff-old">a
paged
representation
</del>
<ins class="diff-chg">the
link
header
to
see
if
additional
pages
are
available;
paging
does
not
affect
the
choice
of
HTTP
status
code.
Note
that
paging
is
lossy,
as
described
in
[[RFC5005]],
</ins>
and
<del class="diff-old">use
it
preferentially
when
available.
</del>
<ins class="diff-chg">so
(as
stated
there)
clients
should
not
make
any
assumptions
about
a
set
of
pages
being
a
complete
or
coherent
snapshot
of
a
resource's
state.
</ins>
</p>
<p>
Looking
at
an
example
resource
representing
Example
Co.'s
customer
relationship
data,
<ins class="diff-new">identified
by
the
URI
</ins><code><ins class="diff-new">
http://example.org/customer-relations
</ins></code>,
we’ll
split
the
response
across
two
pages.
<del class="diff-old">&nbsp;
To
find
the
URL
of
the
first
page,
the
</del>
<ins class="diff-chg">&#160;
The
</ins>
client
<del class="diff-old">makes
a
</del>
<ins class="diff-chg">retrieves
</ins>
<code>
<del class="diff-old">OPTIONS
request
to
the
resource's
URL,
</del>
<ins class="diff-chg">http://example.org/customer-relations
</ins></code>,
and
<del class="diff-old">in
</del>
the
<del class="diff-old">response
looks
for
a
HTTP
</del>
<ins class="diff-chg">server
responds
with
</ins><a href="#atrisk-333"><ins class="diff-chg">
status
code
</ins>
<code>
<del class="diff-old">Link
</del>
<ins class="diff-chg">333
(Returning
Related)
</ins>
</code>
<del class="diff-old">header
with
</del>
</a>,
<ins class="diff-chg">a
</ins>
<code>
<del class="diff-old">rel="first"
</del>
<ins class="diff-chg">Location:
http://example.org/customer-relations?page1
</ins>
</code>
<del class="diff-old">;
the
target
URI
in
the
header
is
the
URL
of
the
first
page
resource.
The
client
then
requests
</del>
<ins class="diff-chg">HTTP
response
header,
and
</ins>
the
<del class="diff-old">first
page
as
http://example.org/customer-relations?firstPage
:
</del>
<ins class="diff-chg">following
representation:
</ins>
</p>
<del class="diff-old"># The following is the representation of
#    http://example.org/customer-relations?firstPage
</del>
<pre class="example" id="ldpc-ex-page1">
<ins class="diff-chg"># The following is the representation of
#    http://example.org/customer-relations?page1
#    Requests on the URI will result in responses that include the following HTTP header
#       Link: &lt;http://example.org/customer-relations?p=2&gt;; rel='next'
#    This Link header is how clients discover the URI of the next page in sequence,
#    and that the resource supports paging.
</ins>
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
<ins class="diff-new">@base &lt;http://example.org/customer-relations&gt;.
</ins>
<del class="diff-old">&lt;http://example.org/customer-relations&gt;
</del>
<ins class="diff-chg">&lt;&gt;
</ins>
   a o:CustomerRelations;
<del class="diff-old">&nbsp; &nbsp;dcterms:title "The customer information for Example Co.";
 &nbsp; o:client &lt;client#JohnZSmith&gt;, &lt;client#BettyASmith&gt;, &lt;client#JoanRSmith&gt;. 
&lt;http://example.org/customer-relations?firstPage&gt;
   a ldp:Page;
 &nbsp; ldp:pageOf &lt;http://example.org/customer-relations&gt;;
 &nbsp; ldp:nextPage &lt;http://example.org/customer-relations?p=2&gt;.
</del>
<ins class="diff-chg">   dcterms:title "The customer information for Example Co.";
   o:client &lt;#JohnZSmith&gt;, &lt;#BettyASmith&gt;, &lt;#JoanRSmith&gt;. 
</ins>
<del class="diff-old">&lt;client#JohnZSmith&gt;
&nbsp;  a foaf:Person;
</del>
<ins class="diff-chg">&lt;#JohnZSmith&gt;
   a foaf:Person;
</ins>
   o:status o:ActiveCustomer;
<del class="diff-old"> &nbsp; foaf:name "John Z. Smith".
&lt;client#BettyASmith&gt;
&nbsp;  a foaf:Person;
</del>
<ins class="diff-chg">   foaf:name "John Z. Smith".
&lt;#BettyASmith&gt;
   a foaf:Person;
</ins>
   o:status o:PreviousCustomer;
<del class="diff-old"> &nbsp; foaf:name "Betty A. Smith".
 &lt;client#BettyASmith&gt;
&nbsp;  a foaf:Person;
</del>
<ins class="diff-chg">   foaf:name "Betty A. Smith".
 &lt;#JoanRSmith&gt;
   a foaf:Person;
</ins>
   o:status o:PotentialCustomer;
<del class="diff-old">&nbsp;
foaf:name
"Joan
R.
Smith".
</del>
<ins class="diff-chg">   foaf:name "Joan R. Smith".
</ins>
</pre>
<p>
<ins class="diff-new">Because
the
server
includes
a
</ins><code><ins class="diff-new">
Link:
&lt;http://example.org/customer-relations?p=2&gt;;
rel='next'
</ins></code><ins class="diff-new">
response
header,
and
the
status
code
is
3xx
(
</ins><code><ins class="diff-new">
333
(Returning
Related)
</ins></code><ins class="diff-new">
in
this
case),
the
client
knows
that
more
data
exists
and
where
to
find
it.
</ins>
The
server
determines
the
size
of
the
pages
using
application
specific
methods
not
defined
within
this
specificiation.
<del class="diff-old">Note
also,
the
actual
name
for
the
query
parameter
(such
as
?p=2)
</del>
<ins class="diff-chg">The
next
page
link's
target
URI
</ins>
is
also
defined
by
the
server
and
not
this
specification.
</p>
<p>
The
following
example
is
the
result
of
retrieving
the
<del class="diff-old">representation
for
the
</del>
next
<del class="diff-old">page:
</del>
<ins class="diff-chg">page;
the
server
responds
with
status
code
</ins><code><ins class="diff-chg">
200
(OK)
</ins></code><ins class="diff-chg">
and
the
following
representation:
</ins>
</p>
<del class="diff-old"># The following is the representation of
</del>
<pre class="example" id="ldpc-ex-page2">
<ins class="diff-chg"># The following is the representation of
</ins>
#  http://example.org/customer-relations?p=2
<ins class="diff-new">#
#  There is no "next" Link in the server's response, so this is the final page.
#
</ins>
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
<ins class="diff-new">@base &lt;http://example.org/customer-relations&gt;.
</ins>
<del class="diff-old">&lt;http://example.org/customer-relations&gt;
 &nbsp; o:client &lt;client#GlenWSmith&gt;, &lt;client#AlfredESmith&gt;. 
</del>
<ins class="diff-chg">&lt;&gt;
   o:client &lt;#GlenWSmith&gt;, &lt;#AlfredESmith&gt;. 
</ins>
 
<del class="diff-old">&lt;http://example.org/customer-relations?p=2&gt;
 &nbsp; a ldp:Page;
&nbsp; &nbsp;ldp:pageOf &lt;http://example.org/customer-relations&gt;;
&nbsp; &nbsp;ldp:nextPage rdf:nil.
&lt;client#GlenWSmith&gt;
&nbsp;  a foaf:Person;
</del>
<ins class="diff-chg">&lt;#GlenWSmith&gt;
   a foaf:Person;
</ins>
   o:status o:ActiveCustomer, o:GoldCustomer;
<del class="diff-old"> &nbsp; foaf:name "Glen W. Smith".
</del>
<ins class="diff-chg">   foaf:name "Glen W. Smith".
</ins>
<del class="diff-old">&lt;client#AlfredESmith&gt;
&nbsp;  a foaf:Person;
</del>
<ins class="diff-chg">&lt;#AlfredESmith&gt;
   a foaf:Person;
</ins>
   o:status o:ActiveCustomer, o:BronzeCustomer;
<del class="diff-old">&nbsp;
foaf:name
"Alfred
E.
Smith".
</del>
<ins class="diff-chg">   foaf:name "Alfred E. Smith".
 
</ins>
</pre>
<p>
In
this
example,
there
are
only
two
customers
provided
in
the
final
page.
<del class="diff-old">&nbsp;To
</del>
<ins class="diff-chg">&#160;To
</ins>
indicate
this
is
the
last
page,
<del class="diff-old">a
value
of
rdf:nil
is
used
for
</del>
<ins class="diff-chg">the
server
omits
</ins>
the
<code>
<del class="diff-old">ldp:nextPage
</del>
<ins class="diff-chg">Link:
rel='next'
</ins>
</code>
<del class="diff-old">predicate
</del>
<ins class="diff-chg">header
in
its
response.
</ins></p><p><ins class="diff-chg">
As
mentioned
above,
retrieving
all
the
pages
offered
by
a
server
gives
no
guarantee
to
a
client
that
it
knows
the
entire
state
</ins>
of
the
<ins class="diff-new">server.
For
example,
after
the
server
constructs
the
the
first
</ins>
page
<del class="diff-old">resource.
</del>
<ins class="diff-chg">representation,
another
actor
could
delete
</ins><code><ins class="diff-chg">
client#BettyASmith
</ins></code><ins class="diff-chg">
from
the
server.
</ins>
</p>
</section>
<del class="diff-old">4.10.2
</del>
<section id="ldpr-PagingGET">
<h3>
HTTP
GET
</h3>
<p>
In
addition
to
the
requirements
set
forth
in
<a href="#ldpr-HTTP_GET" class="sectionRef">
<del class="diff-old">section
4.3
</del>
</a>
on
HTTP
<code>
GET
</code>,
<del class="diff-old">LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
that
support
paging
must
also
follow
the
requirements
in
this
section
<ins class="diff-new">for
all
</ins><a title="Paged resource"><ins class="diff-new">
paged
resources
</ins></a><ins class="diff-new">
and
their
associated
</ins><a title="Single-page resource"><ins class="diff-new">
single-page
resources
</ins></a>.
</p>
<del class="diff-old">4.10.2.1
LDPR
</del>
<section id="ldpr-pagingGET-sequences-change">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
<ins class="diff-chg">MAY
add
</ins><a title="Single-page resource"><ins class="diff-chg">
single-page
resources
</ins></a><ins class="diff-chg">
to
a
</ins><a title="Paged resource"><ins class="diff-chg">
paged
resource's
</ins></a><ins class="diff-chg">
sequence
over
time,
but
</ins>
SHOULD
<del class="diff-old">allow
clients
</del>
<ins class="diff-chg">only
add
pages
</ins>
to
<del class="diff-old">retrieve
large
LDPRs
</del>
<ins class="diff-chg">the
end
of
a
sequence.
</ins></h2><blockquote><ins class="diff-chg">
Non-normative
note:
As
a
result,
clients
retrieving
any
</ins><a title="Single-page resource"><ins class="diff-chg">
single-page
resource
</ins></a><ins class="diff-chg">
several
times
can
observe
its
place
</ins>
in
<ins class="diff-new">the
sequence
change
as
the
state
of
the
</ins><a title="Paged resource"><ins class="diff-new">
paged
resource
</ins></a><ins class="diff-new">
changes.
For
example,
a
nominally
last
page's
server
might
provide
a
</ins><a><ins class="diff-new">
next
page
link
</ins></a><ins class="diff-new">
when
the
page
is
retrieved.
Similar
situations
arise
when
the
page
sequence
crosses
server
boundaries;
server
A
might
host
the
initial
portion
of
a
sequence
that
links
to
the
last
page
server
A
is
aware
of,
hosted
on
server
B,
and
server
B
might
extend
the
sequence
of
</ins>
pages.
<del class="diff-old">In
</del>
</blockquote>
<section id="ldpr-pagingGET-first-allowed-onpages">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
servers
</ins></a><ins class="diff-chg">
MAY
provide
a
</ins><a><ins class="diff-chg">
first
page
link
</ins></a><ins class="diff-chg">
when
responding
to
requests
with
any
</ins><a title="Single-page resource"><ins class="diff-chg">
single-page
resource
</ins></a><ins class="diff-chg">
as
the
</ins><code><ins class="diff-chg">
Request-URI
</ins></code>.</h2></section><section id="ldpr-pagingGET-last-allowed-onpages"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
MAY
provide
a
</ins><a><ins class="diff-chg">
last
page
link
</ins></a><ins class="diff-chg">
in
</ins>
responses
to
<code>
GET
</code>
requests
with
<del class="diff-old">an
LDPR
</del>
<ins class="diff-chg">any
</ins><a title="Single-page resource"><ins class="diff-chg">
single-page
resource
</ins></a>
as
the
<code>
Request-URI
<del class="diff-old">,
LDPR
</del>
</code>.
</h2>
</section>
</section>
<section id="ldpr-pagingGET-next-reqd">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
<del class="diff-old">that
support
paging
SHOULD
</del>
</a>
<ins class="diff-chg">MUST
</ins>
provide
<del class="diff-old">an
HTTP
Link
header
whose
target
URI
is
the
first
</del>
<ins class="diff-chg">a
</ins><a><ins class="diff-chg">
next
</ins>
page
<del class="diff-old">resource,
and
whose
</del>
link
<del class="diff-old">relation
type
is
</del>
</a>
<ins class="diff-chg">in
responses
to
</ins>
<code>
<del class="diff-old">first
</del>
<ins class="diff-chg">GET
</ins>
</code>
<del class="diff-old">[
RFC5988
</del>
<ins class="diff-chg">requests
with
any
</ins><a title="Single-page resource"><ins class="diff-chg">
single-page
resource
</ins>
</a>
<del class="diff-old">].
</del>
<em>
<ins class="diff-chg">other
than
the
final
page
</ins></em><ins class="diff-chg">
as
the
</ins><code><ins class="diff-chg">
Request-URI
</ins></code>.
This
is
the
mechanism
by
which
clients
<ins class="diff-new">can
</ins>
discover
the
URL
of
the
<del class="diff-old">first
</del>
<ins class="diff-chg">next
</ins>
page.
<del class="diff-old">If
no
such
Link
header
is
present,
then
conservative
clients
will
assume
that
the
LDPR
does
not
support
paging.
For
example,
if
there
is
</del>
</h2>
<section id="ldpr-pagingGET-lastnext-prohibited">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
servers
</ins></a><ins class="diff-chg">
MUST
NOT
provide
</ins>
a
<del class="diff-old">LDPR
with
URL
&lt;resourceURL&gt;
that
supports
paging
and
whose
first
</del>
<a>
<ins class="diff-chg">next
</ins>
page
<del class="diff-old">URL
is
&lt;resourceURL&gt;?theFirstPage
,
then
the
corresponding
</del>
link
<del class="diff-old">header
would
be
</del>
</a>
<ins class="diff-chg">in
responses
to
</ins>
<code>
<del class="diff-old">Link:
&lt;?theFirstPage&gt;;rel="first"
.
The
representation
for
any
page,
including
the
first,
will
include
the
URL
for
</del>
<ins class="diff-chg">GET
</ins></code><ins class="diff-chg">
requests
with
</ins>
the
<del class="diff-old">next
page.&nbsp;See
section
4.10
</del>
<ins class="diff-chg">final
</ins><a title="Single-page resource"><ins class="diff-chg">
single-page
resource
</ins>
</a>
<del class="diff-old">for
additional
details.
4.10.2.2
LDPR
servers
MAY
split
</del>
<ins class="diff-chg">as
</ins>
the
<del class="diff-old">response
representation
of
any
LDPR
.
</del>
<code>
<ins class="diff-chg">Request-URI
</ins></code>.
This
is
<del class="diff-old">known
as
server-initiated
paging.
See
section
4.10
for
additional
details.
4.10.2.3
LDPR
servers
that
initiate
paging
SHOULD
respond
to
requests
for
a
LDPR
</del>
<ins class="diff-chg">the
mechanism
</ins>
by
<del class="diff-old">redirecting
</del>
<ins class="diff-chg">which
clients
can
discover
</ins>
the
<del class="diff-old">client
to
</del>
<ins class="diff-chg">end
of
</ins>
the
<del class="diff-old">first
</del>
page
<del class="diff-old">resource
using
</del>
<ins class="diff-chg">sequence
as
currently
known
by
the
server.
</ins></h2></section><section id="ldpr-pagingGET-prev-allowed"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
MAY
provide
</ins>
a
<a>
<ins class="diff-new">previous
page
link
</ins></a><ins class="diff-new">
in
responses
to
</ins>
<code>
<del class="diff-old">303
See
Other
</del>
<ins class="diff-chg">GET
</ins>
</code>
<del class="diff-old">response
</del>
<ins class="diff-chg">requests
</ins>
with
<del class="diff-old">an
HTTP
Location
header
providing
the
first
page
</del>
<ins class="diff-chg">any
</ins><a title="Single-page resource"><ins class="diff-chg">
single-page
</ins>
resource
<del class="diff-old">URL.
4.10.2.4
LDPR
servers
that
support
paging
MUST
include
a
representation
for
</del>
</a>
<em>
<ins class="diff-chg">other
than
</ins>
the
<ins class="diff-new">first
</ins>
page
<del class="diff-old">resource.
4.10.2.4.1
The
page
resource
representation
MUST
</del>
</em>
<del class="diff-old">have
one
triple
with
the
subject
of
</del>
<ins class="diff-chg">as
</ins>
the
<del class="diff-old">page,
predicate
of
</del>
<code>
<del class="diff-old">ldp:nextPage
and
object
being
</del>
<ins class="diff-chg">Request-URI
</ins></code>.<ins class="diff-chg">
This
is
one
mechanism
by
which
clients
can
discover
</ins>
the
URL
<del class="diff-old">for
</del>
<ins class="diff-chg">of
</ins>
the
<del class="diff-old">subsequent
</del>
<ins class="diff-chg">previous
</ins>
page.
<del class="diff-old">&lt;http://example.org/customer-relations?firstPage&gt;
ldp:nextPage
&lt;http://example.org/customer-relations?p=2&gt;
.
</del>
</h2>
</section>
<section id="ldpr-pagingGET-firstprev-prohibited">
<h2 class="normal">
<del class="diff-old">4.10.2.4.2
The
last
page
resource
representation
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
servers
</ins></a>
MUST
<del class="diff-old">have
one
triple
with
the
subject
of
the
last
page,
predicate
of
ldp:nextPage
and
object
being
rdf:nil
.
&lt;http://example.org/customer-relations?p=2&gt;
ldp:nextPage
rdf:nil
.
4.10.2.4.3
The
</del>
<ins class="diff-chg">NOT
provide
a
</ins><a><ins class="diff-chg">
previous
</ins>
page
<del class="diff-old">resource
representation
SHOULD
have
one
triple
</del>
<ins class="diff-chg">link
</ins></a><ins class="diff-chg">
in
responses
</ins>
to
<del class="diff-old">indicate
its
type,
whose
subject
is
the
URL
of
the
page,
whose
predicate
is
</del>
<code>
<del class="diff-old">rdf:type
</del>
<ins class="diff-chg">GET
</ins>
</code>
<del class="diff-old">and
object
is
ldp:Page
.
It
also
SHOULD
have
1
triple
to
indicate
</del>
<ins class="diff-chg">requests
with
</ins>
the
<em>
<ins class="diff-new">first
</ins></em><a title="Single-page resource"><ins class="diff-new">
single-page
</ins>
resource
<del class="diff-old">it
is
paging,
whose
&nbsp;subject
is
the
URL
of
</del>
</a>
<ins class="diff-chg">as
</ins>
the
<del class="diff-old">page,
predicate
is
</del>
<code>
<del class="diff-old">ldp:pageOf
,
and
object
</del>
<ins class="diff-chg">Request-URI
</ins></code>.<ins class="diff-chg">
This
</ins>
is
<ins class="diff-new">one
mechanism
by
which
clients
can
discover
</ins>
the
<del class="diff-old">URL
</del>
<ins class="diff-chg">beginning
</ins>
of
the
<del class="diff-old">LDPR
.
&lt;http://example.org/customer-relations?firstPage&gt;
    rdf:type    ldp:Page;
ldp:pageOf
&lt;http://example.org/customer-relations&gt;.
</del>
<ins class="diff-chg">page
sequence
as
currently
known
by
the
server.
</ins></h2>
</section>
</section>
<section id="ldpr-pagingGET-page-type-reqd">
<h2 class="normal">
<del class="diff-old">4.10.3
HTTP
OPTIONS
4.10.3.1
LDPR
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MUST
<del class="diff-old">indicate
their
support
for
client-initiated
paging
by
responding
to
a
</del>
<ins class="diff-chg">provide
an
</ins>
HTTP
<code>
<del class="diff-old">OPTIONS
</del>
<ins class="diff-chg">Link
</ins>
</code>
<del class="diff-old">request
on
the
LDPR
’s
URL
with
the
HTTP
response
</del>
header
<del class="diff-old">for
link
relations
using
the
header
name
of
</del>
<ins class="diff-chg">whose
target
URI
is
</ins>
<code>
<del class="diff-old">Link
</del>
<ins class="diff-chg">http://www.w3.org/ns/ldp#Page
</ins></code>,
and
<ins class="diff-new">whose
</ins>
link
relation
type
<ins class="diff-new">is
</ins>
<code>
<del class="diff-old">first
</del>
<ins class="diff-chg">type
</ins>
</code>
<del class="diff-old">[
RFC5988
].
4.11
Resource
Inlining:
Representing
Multiple
Resources
</del>
<ins class="diff-chg">[[!RFC5988]]
</ins>
in
<ins class="diff-new">responses
to
</ins><code><ins class="diff-new">
GET
</ins></code><ins class="diff-new">
requests
with
any
</ins><a title="Single-page resource"><ins class="diff-new">
single-page
resource
</ins></a><ins class="diff-new">
as
the
</ins><code><ins class="diff-new">
Request-URI
</ins></code>.<ins class="diff-new">
This
is
one
mechanism
by
which
clients
know
that
the
resource
is
one
of
</ins>
a
<del class="diff-old">Response
</del>
<ins class="diff-chg">sequence
of
pages.
</ins></h2></section><div class="atrisk" id="atrisk-333">
<p class="atrisktext">
Feature
At
Risk
</p>
<p>
The
LDP
Working
Group
proposes
incorporation
of
the
features
described
in
<del class="diff-old">this
section.
</del>
<ins class="diff-chg">the
next
compliance
clause.
</ins>
</p>
<ul>
<li>
<del class="diff-old">The
addition
of
resource
inlining
to
save
application
latency
and
server/network
load
in
controlled
environments.
Feedback,
both
positive
and
negative,
is
invited
by
sending
email
to
the
mailing
list
in
Status
of
This
Document
.
4.11.1
Introduction
</del>
<p>
<del class="diff-old">This
section
is
non-normative.
Servers
</del>
<ins class="diff-chg">A
</ins><a href="http://lists.w3.org/Archives/Public/www-tag/2013Dec/0041.html"><ins class="diff-chg">
TAG
discussion
</ins></a><ins class="diff-chg">
has
started,
</ins>
whose
<del class="diff-old">resources
are
relatively
granular
may
wish
to
optimistically
provide
more
information
in
a
response
than
what
the
client
actually
requested,
in
order
</del>
<ins class="diff-chg">goal
is
</ins>
to
reduce
the
<del class="diff-old">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
resource
inlining
and
member
inlining
.
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
</del>
<ins class="diff-chg">need
for
two
request-response
round
trips
down
</ins>
to
<del class="diff-old">influence
which
(if
any)
resources
are
inlined
in
any
given
response.
Servers
can
return
extra
triples
on
any
response,
but
fail
</del>
<ins class="diff-chg">one
when
retrieving
what
turns
out
</ins>
to
<del class="diff-old">meet
</del>
<ins class="diff-chg">be
</ins>
the
<del class="diff-old">definition
</del>
<ins class="diff-chg">first
page
</ins>
of
<del class="diff-old">resource
inlining
,
</del>
<ins class="diff-chg">a
paged
resource,
</ins>
by
<del class="diff-old">either
returning
</del>
<ins class="diff-chg">defining
</ins>
a
<del class="diff-old">subset
of
</del>
<ins class="diff-chg">new
HTTP
response
code
in
</ins>
the
<del class="diff-old">other
resource(s)
triples
</del>
<code>
<ins class="diff-chg">2xx
</ins></code>
or
<del class="diff-old">by
failing
to
assert
</del>
<code>
<ins class="diff-chg">3xx
</ins></code><ins class="diff-chg">
class
</ins>
that
<del class="diff-old">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
</del>
would
<del class="diff-old">be
to
make
</del>
<ins class="diff-chg">allow
</ins>
a
<del class="diff-old">HTTP
</del>
<ins class="diff-chg">server
to
respond
to
</ins>
<code>
GET
<ins class="diff-new">request-uri
</ins>
</code>
<del class="diff-old">request
against
all
the
other
resource(s).
In
some
applications,
knowing
that
these
</del>
requests
<del class="diff-old">are
unnecessary
saves
significant
latency
and
server/network
load.
4.11.2
Use
</del>
with
<del class="diff-old">Care
This
section
is
non-normative.
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
</del>
the
<del class="diff-old">general
case

so
if
you
care
about
any
</del>
<ins class="diff-chg">representation
</ins>
of
the
<del class="diff-old">following
in
a
given
application,
your
server
should
avoid
returning
any
triples
beyond
those
found
at
the
HTTP
Request-URI
.
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
</del>
<ins class="diff-chg">first
page
(whose
URI
</ins>
is
<del class="diff-old">impossible
for
</del>
<code>
<ins class="diff-chg">first-page-uri
</ins></code>,<ins class="diff-chg">
not
</ins><code><ins class="diff-chg">
request-uri
</ins></code><ins class="diff-chg">
)
of
</ins>
a
<del class="diff-old">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.
</del>
<ins class="diff-chg">multi-page
response.
</ins>
</p>
</li>
<li>
<p>
<del class="diff-old">The
response
may
contain
contradictions
that
are
trivially
obvious
(or
subtle),
and
those
may
or
may
not
be
a
problem
at
the
application
level.
</del>
For
<del class="diff-old">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.
4.11.3
HTTP
GET
In
addition
to
</del>
the
<del class="diff-old">requirements
set
forth
in
other
sections,
LDPR
servers
that
support
resource
inlining
must
also
follow
the
requirements
in
</del>
<ins class="diff-chg">purposes
of
drafting
</ins>
this
<del class="diff-old">section.
4.11.3.1
LDPR
servers
</del>
<ins class="diff-chg">section,
we
assume
</ins>
that
<del class="diff-old">support
resource
inlining
MUST
include
a
ldp:Page
resource
in
the
representation
describing
</del>
the
<del class="diff-old">set
of
inlined
resources,
whether
or
not
the
representation
contains
subsequent
pages.
The
ldp:Page
resource
conceptually
contains
metadata
about
the
representation;
it
</del>
<ins class="diff-chg">new
code's
value
</ins>
is
<del class="diff-old">usually
not
part
of
the
HTTP
resource's
state,
</del>
<code>
<ins class="diff-chg">333
(Returning
Related)
</ins></code>,<a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0023.html"><ins class="diff-chg">
an
LDP
extrapolation
from
TAG
discussions,
</ins></a>
and
its
<del class="diff-old">presence
does
not
indicate
that
</del>
<ins class="diff-chg">definition
is
given
by
</ins><a href="http://lists.w3.org/Archives/Public/www-tag/2014Jan/0015.html"><ins class="diff-chg">
Henry
Thompson's
strawman
</ins></a>,<ins class="diff-chg">
with
</ins>
the
<del class="diff-old">LDPR
server
supports
paging
in
general.
LDPR
</del>
<ins class="diff-chg">substitution
of
333
for
2xx.
Note:
nothing
prevents
</ins>
servers
<del class="diff-old">that
include
the
</del>
<ins class="diff-chg">or
clients
from
using
</ins>
<code>
<del class="diff-old">ldp:Page
</del>
<ins class="diff-chg">303
See
Other
</ins>
</code>
<del class="diff-old">resource
</del>
<ins class="diff-chg">responses
to
requests
</ins>
for
<del class="diff-old">inlining
</del>
<a title="Paged resource">
<ins class="diff-chg">paged
resources
</ins></a>.<ins class="diff-chg">
The
only
significant
difference
between
303
</ins>
and
<del class="diff-old">also
support
paging
MUST
use
</del>
<ins class="diff-chg">333
responses
is
</ins>
the
<del class="diff-old">same
ldp:Page
resource
</del>
<ins class="diff-chg">extra
round
trip
required
</ins>
for
the
<del class="diff-old">triples
required
by
both,
in
order
to
minimize
</del>
client
<del class="diff-old">code
complexity.
The
ldp:Page
resource's
triples
are
the
LDP-defined
means
by
which
the
servers
communicate
</del>
to
<del class="diff-old">LDP
clients
</del>
<ins class="diff-chg">retrieve
</ins>
the
<del class="diff-old">set
</del>
<ins class="diff-chg">representation
</ins>
of
<del class="diff-old">HTTP
resources
whose
state
</del>
<ins class="diff-chg">the
first
page
when
using
303.
</ins></p></li><li><p><ins class="diff-chg">
Once
LDP
</ins>
is
<del class="diff-old">included
in
</del>
a
<del class="diff-old">representation,
allowing
clients
</del>
<ins class="diff-chg">Candidate
Recommendation,
the
LDP
WG
will
make
an
assessment
based
on
the
status
at
IETF,
working
with
the
W3C
Director,
</ins>
to
<del class="diff-old">avoid
HTTP
GET
requests
for
them.
4.11.3.2
LDPR
servers
that
support
resource
inlining
MUST
include
</del>
<ins class="diff-chg">either
use
</ins>
the
<del class="diff-old">ldp:Page
resource
described
</del>
<ins class="diff-chg">newly
defined
response
code
as
documented
</ins>
in
<ins class="diff-chg">this
</ins>
section
<del class="diff-old">4.11.3.1
one
triple
for
each
inlined
resource,
whose
subject
is
the
ldp:Page
resource
URI,
whose
predicate
is
ldp:inlinedResource
,
and
whose
object
is
the
HTTP
</del>
<ins class="diff-chg">or
to
revert
to
a
classic
</ins>
<code>
<del class="diff-old">Request-URI
</del>
<ins class="diff-chg">303
</ins>
</code>
<del class="diff-old">of
an
inlined
resource
[
</del>
<ins class="diff-chg">response
pattern.
</ins></p></li></ul></div><section id="ldpr-status-code"><h2 class="normal">
<del class="diff-old">HTTP11
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
servers
</ins>
</a>
<del class="diff-old">].
4.11.3.3
LDPR
clients
</del>
SHOULD
<del class="diff-old">avoid
making
</del>
<ins class="diff-chg">respond
with
</ins>
HTTP
<ins class="diff-new">status
code
</ins><code><ins class="diff-new">
333
(Returning
Related)
</ins></code><ins class="diff-new">
to
successful
</ins>
<code>
GET
</code>
requests
<del class="diff-old">against
</del>
<ins class="diff-chg">with
</ins>
any
<a title="Paged resource">
<ins class="diff-new">paged
</ins>
resource
<del class="diff-old">whose
HTTP
</del>
</a>
<ins class="diff-chg">as
the
</ins>
<code>
Request-URI
<del class="diff-old">is
the
object
of
a
triple
of
the
form
described
in
section
4.11.3.2
,
unless
there
are
application-specific
reasons
for
doing
so.
Clients
should
note
that
by
the
time
the
representation
is
received,
the
actual
state
of
</del>
</code>,
<ins class="diff-chg">although
</ins>
any
<del class="diff-old">inlined
resource(s)
may
have
changed
due
</del>
<ins class="diff-chg">appropriate
code
MAY
be
used.
</ins></h2></section></section><section id="ldpr-paging-HTTP_OPTIONS"><h3><ins class="diff-chg">
HTTP
OPTIONS
</ins></h3><p><ins class="diff-chg">
In
addition
</ins>
to
<del class="diff-old">subsequent
requests.
4.11.3.4
LDPR
clients
MUST
NOT
assume
that
LDPR
representations
lacking
a
ldp:Page
resource
or
lacking
</del>
the
<del class="diff-old">triple
described
</del>
<ins class="diff-chg">requirements
set
forth
</ins>
in
<del class="diff-old">section
4.11.3.2
</del>
<a href="#ldpr-HTTP_OPTIONS" class="sectionRef">
</a>
<del class="diff-old">contain
all
the
triples
for
any
resource(s)
listed
in
the
representation
whose
HTTP
Request-URI
differs
from
the
</del>
<ins class="diff-chg">on
</ins>
HTTP
<code>
<del class="diff-old">Request-URI
used
by
</del>
<ins class="diff-chg">OPTIONS
</ins></code>,<a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
that
support
paging
must
also
follow
</ins>
the
<del class="diff-old">client.
The
representation
might
</del>
<ins class="diff-chg">requirements
</ins>
in
<del class="diff-old">fact
contain
</del>
<ins class="diff-chg">this
section
for
</ins>
all
<del class="diff-old">such
triples,
or
some
subset
of
them,
and
</del>
<a title="Paged resource">
<ins class="diff-chg">paged
resources
</ins></a>.<ins class="diff-chg">
Note
</ins>
that
<del class="diff-old">might
or
might
not
be
completely
adequate
for
the
client's
intended
usage,
but
an
</del>
LDP
<del class="diff-old">client
has
no
way
to
discern
</del>
<ins class="diff-chg">only
requires
enough
</ins>
from
<del class="diff-old">such
</del>
<code>
<ins class="diff-chg">OPTIONS
</ins></code><ins class="diff-chg">
for
discovery
of
paging
support
on
</ins>
a
<del class="diff-old">representation
</del>
<ins class="diff-chg">resource,
</ins>
which
<del class="diff-old">interpretation
</del>
is
<del class="diff-old">accurate.
</del>
<ins class="diff-chg">considerably
less
than
is
required
for
HTTP
</ins><code><ins class="diff-chg">
GET
</ins></code>.<ins class="diff-chg">
This
lowers
server
implementation
effort.
</ins></p>
</section>
</section>
</section>
<del class="diff-old">5.
</del>
<section id="ldpc">
<h1>
Linked
Data
Platform
Containers
</h1>
<section class="informative" id="ldpc-informative">
<h2>
<ins class="diff-new">Introduction
</ins>
</h2>
<del class="diff-old">5.1
Informative
This
section
is
non-normative.
</del>
<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
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
<a title="Membership triples">
membership
<del class="diff-old">triples.
</del>
<ins class="diff-chg">triples
</ins></a><ins class="diff-chg">
that
follow
a
consistent
pattern
(see
the
linked-to
definition
for
the
possible
patterns).
</ins>
The
membership
triples
of
a
container
all
have
the
same
<del class="diff-old">subject
</del>
<ins class="diff-chg">predicate,
called
the
membership
predicate,
</ins>
and
<del class="diff-old">predicate
</del>
<ins class="diff-chg">either
the
subject
or
the
object
is
also
a
consistent
value
</ins>

the
<del class="diff-old">objects
</del>
<ins class="diff-chg">remaining
position
</ins>
of
the
membership
triples
<ins class="diff-new">(the
one
that
varies)
</ins>
define
the
members
of
the
container.
<del class="diff-old">The
subject
of
the
membership
triples
is
called
the
membership
subject
and
the
predicate
is
called
the
membership
predicate.
</del>
In
the
simplest
cases,
the
<del class="diff-old">membership
subject
</del>
<ins class="diff-chg">consistent
value
</ins>
will
be
the
LDPC
<del class="diff-old">resource
itself,
</del>
<ins class="diff-chg">resource's
URI,
</ins>
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>
<del class="diff-old">rdfs:member
</del>
<ins class="diff-chg">ldp:member
</ins>
</code>
predicate.
</p>
<p>
This
document
includes
a
set
of
guidelines
for
<del class="diff-old">using
POST
to
create
</del>
<ins class="diff-chg">creating
</ins>
new
resources
and
<del class="diff-old">add
</del>
<ins class="diff-chg">adding
</ins>
them
to
the
list
of
members
of
a
container.
It
goes
on
to
explain
how
to
learn
about
a
set
of
related
resources,
<ins class="diff-new">regardless
of
how
</ins>
they
<del class="diff-old">may
have
been
</del>
<ins class="diff-chg">were
</ins>
created
<del class="diff-old">using
POST
</del>
or
<del class="diff-old">through
other
means.
</del>
<ins class="diff-chg">added
to
the
container's
membership.
</ins>
It
also
defines
behavior
when
<del class="diff-old">POST
created
</del>
resources
<del class="diff-old">are
deleted,
to
clean
up
</del>
<ins class="diff-chg">created
using
a
</ins>
container
<del class="diff-old">membership,
and
</del>
<ins class="diff-chg">are
later
deleted;
</ins>
deleting
containers
removes
membership
information
and
possibly
<del class="diff-old">perform
</del>
<ins class="diff-chg">performs
</ins>
some
cleanup
tasks
on
unreferenced
member
resources.
</p>
<p>
The
following
illustrates
a
very
simple
container
with
only
three
members
and
some
information
about
the
container
(the
fact
that
it
is
a
container
and
a
brief
title):
</p>
<del class="diff-old"># The following is the representation of
# &nbsp; &nbsp;http://example.org/container1/
</del>
<pre class="example" id="ldpc-ex-simple">
<ins class="diff-chg"># The following is the representation of
#    http://example.org/c1/
# @base &lt;http://example.org/c1/&gt;
</ins>
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
<del class="diff-old">@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
</del>
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
&lt;&gt;
<del class="diff-old"> &nbsp; a ldp:Container;
   ldp:membershipSubject &lt;&gt;
   ldp:membershipPredicate rdfs:member;
   ldp:membershipObject ldp:MemberSubject;
 &nbsp; dcterms:title "A very simple container";
&nbsp;
rdfs:member
&lt;member1&gt;,
&lt;member2&gt;,
&lt;member3&gt;.
</del>
<ins class="diff-chg">   a ldp:Container, ldp:BasicContainer;
   dcterms:title "A very simple container";
   ldp:contains &lt;r1&gt;, &lt;r2&gt;, &lt;r3&gt;.
</ins>
</pre>
<figure id="fig-ldpc-basic">
<img src="images/ldpc-basic.png" alt="Sample Linked Data Platform Basic Container" />
<figcaption>
<ins class="diff-chg">Sample
of
Linked
Data
Platform
Basic
Container
</ins></figcaption></figure>
<p>
This
example
is
very
straightforward
-
the
membership
<ins class="diff-new">and
containment
</ins>
predicate
<del class="diff-old">is
</del>
<ins class="diff-chg">are
both
</ins>
<code>
<del class="diff-old">rdfs:member
</del>
<ins class="diff-chg">ldp:contains
</ins>
</code>
and
the
<ins class="diff-new">other
consistent
</ins>
membership
<del class="diff-old">subject
</del>
<ins class="diff-chg">value
</ins>
is
the
<del class="diff-old">container
itself.
</del>
<ins class="diff-chg">container's
URI,
occurring
in
the
subject
position
of
the
triples.
</ins>
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.
<ins class="diff-new">This
type
of
container
is
also
refered
to
as
</ins><a title="Linked Data Platform Basic Container"><ins class="diff-new">
LDP
Basic
Container
</ins></a>.
</p>
<p>
Sometimes
it
is
useful
to
use
a
subject
other
than
the
container
itself
as
the
<ins class="diff-new">consistent
</ins>
membership
<del class="diff-old">subject
and
</del>
<ins class="diff-chg">value,
and/or
</ins>
to
use
a
predicate
<del class="diff-old">other
than
rdfs:member
</del>
<ins class="diff-chg">from
an
application's
domain
model
</ins>
as
the
membership
predicate.
Let's
start
with
a
domain
resource
for
a
person's
net
worth,
as
illustrated
below:
</p>
<del class="diff-old"># The following is a partial representation of
# &nbsp; http://example.org/netWorth/nw1
</del>
<pre class="example" id="ldpc-ex-membership-partial">
<ins class="diff-chg"># The following is a partial representation of
#   http://example.org/netWorth/nw1
# @base &lt;http://example.org/netWorth/nw1/&gt;
</ins>
@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;,
<del class="diff-old">&lt;liabilityContainer/l3&gt;.
</del>
<ins class="diff-chg">      &lt;liabilityContainer/l3&gt;.
</ins>
</pre>
<p>
From
this
example,
there
is
a
<code>
rdf:type
</code>
of
<code>
o:NetWorth
</code>
indicating
the
resource
represents
an
instance
of
a
person's
net
worth
and
<code>
o:netWorthOf
</code>
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
<ins class="diff-new">in
the
3
examples
</ins>
below:
</p>
<del class="diff-old"># The following is an elaborated representation of
# &nbsp; http://example.org/netWorth/nw1/
</del>
<pre class="example" id="ldpc-ex-membership-full">
<ins class="diff-chg"># The following is an elaborated representation of LDPR
#   http://example.org/netWorth/nw1
# @base &lt;http://example.org/netWorth/nw1/&gt;.
</ins>
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&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;.
</pre>
<pre class="example" id="ldpc-ex-membership-subj">
<ins class="diff-new"># The following is an elaborated representation of LDPC
#   http://example.org/netWorth/nw1/assetContainer/
</ins>
<del class="diff-old">&lt;assetContainer/&gt;
   a ldp:Container;
</del>
<ins class="diff-chg"># @base &lt;http://example.org/netWorth/nw1/assetContainer/&gt;
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a ldp:Container, ldp:DirectContainer;
</ins>
   dcterms:title "The assets of JohnZSmith";
<del class="diff-old">   ldp:membershipSubject &lt;&gt;;
   ldp:membershipPredicate o:asset;
   ldp:membershipObject ldp:MemberSubject.
</del>
<ins class="diff-chg">   ldp:containerResource &lt;&gt;;
   ldp:containsRelation o:asset;
   ldp:contains &lt;a1&gt;, &lt;a2&gt;.
</ins></pre><pre class="example" id="ldpc-ex-membership-full-liabcont"><ins class="diff-chg">
# The following is an elaborated representation of LDPC
#   http://example.org/netWorth/nw1/liabilityContainer/
</ins>
<del class="diff-old">&lt;liabilityContainer/&gt;
   a ldp:Container;
</del>
<ins class="diff-chg"># @base &lt;http://example.org/netWorth/nw1/liabilityContainer/&gt;
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a ldp:Container, ldp:DirectContainer;
</ins>
   dcterms:title "The liabilities of JohnZSmith";
<del class="diff-old">   ldp:membershipSubject &lt;&gt;;
   ldp:membershipPredicate o:liability;
ldp:membershipObject
ldp:MemberSubject.
</del>
<ins class="diff-chg">   ldp:containerResource &lt;&gt;;
   ldp:containsRelation o:liability;
   ldp:contains &lt;l1&gt;, &lt;l2&gt;, &lt;l3&gt;.
</ins>
</pre>
<p>
The
essential
structure
of
the
container
is
the
same,
but
in
this
example,
the
<ins class="diff-new">consistent
</ins>
membership
<ins class="diff-new">value
(still
in
the
</ins>
subject
<ins class="diff-new">position)
</ins>
is
not
the
container
itself

it
is
a
separate
net
worth
resource.
The
membership
predicates
are
<code>
o:asset
</code>
and
<code>
o:liability
</code>

predicates
from
the
domain
model.
A
POST
of
an
asset
representation
to
the
asset
container
will
create
a
new
asset
and
add
it
to
the
list
of
members
by
adding
a
new
membership
triple
to
the
<ins class="diff-new">resource
and
containment
triple
to
the
</ins>
container.
You
might
wonder
why
<code>
http://example.org/netWorth/nw1
</code>
isn't
made
a
container
itself
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>
<del class="diff-old"># The following is the representation of
# &nbsp; 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;
 &nbsp; a ldp:Container;
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
&nbsp; &nbsp;ldp:membershipPredicate o:asset;
   ldp:membershipObject ldp:MemberSubject.
&lt;http://example.org/netWorth/nw1&gt;
&nbsp; &nbsp;a o:NetWorth;
o:asset
&lt;a1&gt;,
&lt;a2&gt;.
</del>
<p>
<del class="diff-old">In
this
example,
clients
cannot
simply
guess
which
resource
</del>
<ins class="diff-chg">This
type
of
container
is
refered
to
as
an
</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
LDP
Direct
Container
</ins></a>.<ins class="diff-chg">
An
</ins><a title="Linked Data Platform Basic Container"><ins class="diff-chg">
LDP
Basic
Container
</ins></a>
is
<ins class="diff-new">a
constrained
form
of
</ins><a title="Linked Data Platform Direct Container"><ins class="diff-new">
LDP
Direct
Container
</ins></a><ins class="diff-new">
where
</ins>
the
membership
<del class="diff-old">subject
and
which
</del>
predicate
is
<code>
<ins class="diff-new">ldp:contains
</ins></code><ins class="diff-new">
and
the
container
resource
is
the
container
itself.
</ins></p><p><ins class="diff-new">
As
seen
in
the
</ins><a href="#ldpc-ex-membership-subj"><code><ins class="diff-new">
assetContainer/
</ins></code><ins class="diff-new">
example
</ins></a>,<ins class="diff-new">
clients
cannot
correctly
guess
at
</ins>
the
membership
<del class="diff-old">predicate,
</del>
<ins class="diff-chg">triples,
</ins>
so
the
example
includes
this
information
in
triples
whose
subject
is
the
LDPC
resource
itself.
</p>
<del class="diff-old">5.1.1
Container
Member
Information
</del>
<p>
<del class="diff-old">In
many

perhaps
most

applications
involving
containers,
it
is
desirable
</del>
<ins class="diff-chg">Alternatively,
servers
may
provide
the
net
worth
resource
and
supporting
containers
in
a
single
response
representations.
When
doing
this,
a
preference
would
be
for
RDF
formats
that
support
multiple
named
graphs,
one
named
graph
</ins>
for
the
<del class="diff-old">client
</del>
<ins class="diff-chg">net
worth
resource
and
then
two
others
for
asset
and
liability
containers.
This
allows
for
the
membership
triples
</ins>
to
be
<del class="diff-old">able
to
get
information
about
each
container
member
without
having
</del>
<ins class="diff-chg">represented
with
the
named
graph
for
the
net
worth
resource,
while
the
containment
triples
would
be
represented
within
the
liability
and
asset
containers
[[rdf11-concepts]].
Generally,
the
membership
triples
belong
</ins>
to
<del class="diff-old">do
</del>
<ins class="diff-chg">the
representation
of
</ins>
a
<del class="diff-old">GET
on
each
one.
LDPC
allows
servers
</del>
<ins class="diff-chg">LDP-RR
and
the
containment
triples
belong
</ins>
to
<del class="diff-old">include
this
information
directly
in
</del>
the
representation
of
the
<del class="diff-old">container.
The
server
decides
</del>
<ins class="diff-chg">LDPC.
</ins></p><p><ins class="diff-chg">
Additionally,
we
could
extend
our
net
worth
example
to
include
a
container
for
advisors
(people)
that
have
managed
</ins>
the
<del class="diff-old">amount
</del>
<ins class="diff-chg">assets
and
liabilities.
We
have
decided
to
identify
these
advisors
with
URLs
that
contain
a
fragment
(hash)
to
represent
these
real-world
resources,
not
the
documents
that
describe
them.
</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
# Adding o:advisor but eaving off o:asset and o:liability for brevity.
# @base &lt;http://example.org/netWorth/nw1/&gt;
@prefix ldp: &lt;http://www.w3.org/ns/ldp#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix foaf: &lt;http://xmlns.com/foaf/0.1/&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;&gt;
   a o:NetWorth;
   o:netWorthOf &lt;http://example.org/users/JohnZSmith&gt;;
   o:advisor
         &lt;advisorContainer/bob#me&gt;,
         &lt;advisorContainer/marsha#me&gt;.
         
&lt;advisorContainer/&gt;
   a ldp:Container, ldp:IndirectContainer;
   dcterms:title "The asset advisors of JohnZSmith";
   ldp:containerResource &lt;&gt;;
   ldp:containsRelation o:advisor;
   ldp:insertedContentRelation foaf:primaryTopic;
   ldp:contains
         &lt;advisorContainer/bob&gt;,
         &lt;advisorContainer/marsha&gt;.
</ins></pre><p><ins class="diff-chg">
To
handle
this
type
</ins>
of
<del class="diff-old">data
about
each
member
</del>
<ins class="diff-chg">indirection,
the
triple
with
predicate
of
</ins><code><ins class="diff-chg">
ldp:insertedContentRelation
</ins></code><ins class="diff-chg">
and
object
of
</ins><code><ins class="diff-chg">
foaf:primaryTopic
</ins></code><ins class="diff-chg">
informs
clients
</ins>
that
<del class="diff-old">is
provided.
Some
common
strategies
</del>
<ins class="diff-chg">when
POSTing
to
this
container,
they
need
to
</ins>
include
<del class="diff-old">providing
</del>
a
<del class="diff-old">fixed
number
</del>
<ins class="diff-chg">triple
</ins>
of
<del class="diff-old">standard
properties,
or
providing
</del>
the
<del class="diff-old">entire
RDF
representation
</del>
<ins class="diff-chg">form
</ins><code><ins class="diff-chg">
(&lt;&gt;,
foaf:primaryTopic,
topic-URI)
</ins></code><ins class="diff-chg">
to
inform
the
server
which
URI
to
use
(
</ins><code><ins class="diff-chg">
topic-URI
</ins></code><ins class="diff-chg">
)
in
the
new
membership
triple.
</ins></p><p><ins class="diff-chg">
This
type
</ins>
of
<del class="diff-old">each
</del>
<ins class="diff-chg">container
is
also
referred
to
as
an
</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
LDP
Indirect
Container
</ins></a>.<ins class="diff-chg">
It
is
similar
to
a
an
</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
LDP
Direct
Container
</ins></a><ins class="diff-chg">
but
it
provides
an
indirection
to
add
(via
a
create
request)
as
</ins>
member
<ins class="diff-new">any
</ins>
resource,
<del class="diff-old">or
providing
nothing.
The
server
application
domain
and
its
use-cases
will
determine
how
much
information
</del>
<ins class="diff-chg">such
as
a
URI
representing
a
real-world
object,
that
</ins>
is
<del class="diff-old">required.
</del>
<ins class="diff-chg">different
from
the
document
that
is
created.
</ins>
</p>
<p>
<del class="diff-old">Continuing
on
from
</del>
<a href="#fig-ldpc-types">
</a>
<ins class="diff-chg">illustrates
</ins>
the
<del class="diff-old">net
worth
example,
</del>
<ins class="diff-chg">3
types:
Basic,
Direct
and
Indirect,
along
with
their
relationship
to
types
of
LDPRs.
It
is
not
expected
that
</ins>
there
will
be
<del class="diff-old">additional
triples
for
the
member
resources
(assets)
in
the
representation:
</del>
<ins class="diff-chg">a
container
with
a
</ins><code><ins class="diff-chg">
rdf:type
</ins></code><ins class="diff-chg">
solely
of
</ins><code><ins class="diff-chg">
ldp:Container
</ins></code>.
</p>
<del class="diff-old"># The following is the representation of
#	&nbsp;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;
   dcterms:title "The assets of JohnZSmith";
   ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   ldp:membershipPredicate o:asset;
   ldp:membershipObject ldp:MemberSubject.
&lt;http://example.org/netWorth/nw1&gt;
&nbsp; &nbsp;a o:NetWorth;
   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
&lt;a1&gt;
&nbsp; &nbsp;a o:Stock;
&nbsp; &nbsp;o:value 10000.
&lt;a2&gt;
&nbsp; &nbsp;a o:Bond;
&nbsp; &nbsp;o:value 20000.
&lt;a3&gt;
&nbsp; &nbsp;a o:RealEstateHolding;
&nbsp;
&nbsp;o:value
300000.
</del>
<figure id="fig-ldpc-types">
<img src="images/ldpc1.png" alt="Types of Linked Data Platform Containers" />
<figcaption>
<ins class="diff-chg">Types
of
Linked
Data
Platform
Containers
</ins></figcaption></figure><div class="ldp-issue-pending">
<p>
<del class="diff-old">In
a
similar
manner,
when
the
representation
for
</del>
<ins class="diff-chg">PENDING
--
table
work
in
progress,
if
found
valuable...we'll
keep.
</ins></p><p><ins class="diff-chg">
The
following
table
illustrates
some
differences
between
</ins><a title="membership"><ins class="diff-chg">
membership
</ins></a><ins class="diff-chg">
and
</ins><a title="containment"><ins class="diff-chg">
containment
</ins></a><ins class="diff-chg">
triples.
For
details
on
</ins>
the
<del class="diff-old">resource
</del>
<ins class="diff-chg">normative
behavior,
see
appropriate
sections
below.
</ins></p><table border="1" id="ldpc-mbrcntdiff"><thead><tr><th rowspan="2"><ins class="diff-chg">
Completed
Request
</ins></th><th colspan="2"><ins class="diff-chg">
Effects
</ins></th></tr><tr><th><ins class="diff-chg">
Membership
</ins></th><th><ins class="diff-chg">
Containment
</ins></th></tr></thead><tr><td><ins class="diff-chg">
LDPR
created
in
LDPC
(any
subtype)
</ins></td><td><ins class="diff-chg">
New
triple
based
on
type
</ins>
of
<del class="diff-old">asset
.../&lt;a1&gt;
is
returned
a
server
</del>
<ins class="diff-chg">container
(see
following
rows)
</ins></td><td><ins class="diff-chg">
New
triple:
(LDPC,
ldp:contains,
LDPR)
</ins></td></tr><tr><td><ins class="diff-chg">
LDPR
created
in
LDP-BC
</ins></td><td><ins class="diff-chg">
New
triple:
(LDPC,
ldp:contains,
LDPR)
</ins></td><td><ins class="diff-chg">
Same
</ins></td></tr><tr><td><ins class="diff-chg">
LDPR
created
in
LDP-DC
</ins></td><td><ins class="diff-chg">
New
triple
links
LDP-RR
to
created
LDPR.
LDP-RR
URI
</ins>
may
<del class="diff-old">include
the
membership
</del>
<ins class="diff-chg">be
same
as
LDP-DC
</ins></td><td><ins class="diff-chg">
New
triple:
(LDPC,
ldp:contains,
LDPR)
</ins></td></tr><tr><td><ins class="diff-chg">
LDPR
created
in
LDP-IC
</ins></td><td><ins class="diff-chg">
New
</ins>
triple
<ins class="diff-new">links
LDP-RR
to
content
indicated
URI
</ins></td><td><ins class="diff-new">
New
triple:
(LDPC,
ldp:contains,
LDPR)
</ins></td></tr><tr><td><ins class="diff-new">
LDPR
is
deleted
</ins></td><td><ins class="diff-new">
Triples
may
be
removed
</ins></td><td><ins class="diff-new">
Triples
are
removed
</ins></td></tr><tr><td><ins class="diff-new">
LDPC
is
deleted
</ins></td><td><ins class="diff-new">
Triples
and
member
resources
may
be
removed
</ins></td><td><ins class="diff-new">
Triples
</ins>
of
<del class="diff-old">the
</del>
form
<del class="diff-old">(.../nw1,
o:asset,
.../a1).
5.1.2&nbsp;Retrieving
Only
Non-member
Properties
</del>
<ins class="diff-chg">(LDPC,
ldp:contains,
LDPR)
and
contained
LDPRs
may
be
removed
</ins></td></tr></table>
</div>
<section id="ldpc-get_empty-container_props">
<h2 class="normal">
<ins class="diff-new">Retrieving
Only
Empty-Container
Triples
</ins></h2>
<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
<del class="diff-old">non-member
</del>
<ins class="diff-chg">subset
of
the
container's
</ins>
properties
<ins class="diff-new">that
are
unrelated
to
member
resources
and
unrelated
to
contained
documents,
for
example
to
determine
the
membership
triple
pattern
and
membership
predicate
</ins>
of
<ins class="diff-new">a
LDP-DC.
LDP
calls
these
</ins><a title="Empty-container triples"><ins class="diff-new">
empty-container
triples
</ins></a>,<ins class="diff-new">
because
they
are
what
remains
when
</ins>
the
<del class="diff-old">container.
</del>
<ins class="diff-chg">container
has
zero
members
and
zero
contained
resources.
</ins>
Since
retrieving
the
whole
container
representation
to
get
this
information
may
be
onerous
for
clients
and
cause
unnecessary
overhead
on
servers,
<del class="diff-old">it
is
desired
to
</del>
<ins class="diff-chg">we
</ins>
define
a
way
to
retrieve
only
<del class="diff-old">the
non-member
</del>
<ins class="diff-chg">these
</ins>
property
<del class="diff-old">values.
Defining
for
each
LDPC
</del>
<ins class="diff-chg">values
(and
more
generally,
</ins>
a
<del class="diff-old">corresponding
resource,
called
</del>
<ins class="diff-chg">way
to
retrieve
only
</ins>
the
<del class="diff-old">“
non-member
resource
”,
whose
state
is
a
</del>
subset
of
<del class="diff-old">the
state
</del>
<ins class="diff-chg">properties
used
to
address
other
major
clusters
</ins>
of
<ins class="diff-new">use
cases).
LDP
adds
parameters
to
</ins>
the
<del class="diff-old">container,
does
this.
</del>
<ins class="diff-chg">HTTP
</ins><code><ins class="diff-chg">
Prefer
</ins></code><ins class="diff-chg">
header's
</ins><code><ins class="diff-chg">
return=representation
</ins></code><ins class="diff-chg">
preference
for
this
(see
</ins><a href= "#prefer-parameters" class="sectionRef"></a><ins class="diff-chg">
for
details).
</ins>
</p>
<p>
The
example
listed
here
only
<del class="diff-old">show
</del>
<ins class="diff-chg">shows
</ins>
a
simple
case
where
<del class="diff-old">only
a
</del>
few
<del class="diff-old">simple
non-member
properties
</del>
<ins class="diff-chg">empty-container
triples
</ins>
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
<del class="diff-old">non-member
properties
</del>
<ins class="diff-chg">empty-container
triples
</ins>
of
a
container
identified
by
the
URL
<code>
http://example.org/container1/
</code>.
<del class="diff-old">In
this
case,
the
non-member
resource
is
identified
by
the
URL
http://example.org/container1?non-member-properties
:
</del>
</p>
<p id="ldpc-ex-empty-container">
Request:
</p>
<del class="diff-old">GET /container1?non-member-properties HTTP/1.1
</del>
<pre class="example">
<ins class="diff-chg">GET /container1 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
Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferEmptyContainer"
</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
ETag: "_87e52ce291112"
Content-Length: 325
<ins class="diff-new">Link: &lt;http://www.w3.org/ns/ldp/Container&gt;; rel="type"
Preference-Applied: return=representation 
</ins>
<del class="diff-old">@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
</del>
@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;
<del class="diff-old">   a ldp:Container;
&nbsp; &nbsp;dcterms:title "A Linked Data Platform Container of Acme Resources";
   ldp:membershipSubject http://example.org/container1/;
 &nbsp; ldp:membershipPredicate rdfs:member;
   ldp:membershipObject ldp:MemberSubject;
dcterms:publisher
&lt;http://acme.com/&gt;.
</del>
<ins class="diff-chg">   a ldp:Container, ldp:DirectContainer;
   dcterms:title "A Linked Data Platform Container of Acme Resources";
   ldp:containerResource &lt;http://example.org/container1/&gt;;
   ldp:containsRelation ldp:member;
   ldp:insertedContentRelation ldp:MemberSubject;
   dcterms:publisher &lt;http://acme.com/&gt;.
</ins>
</pre>
<p>
<del class="diff-old">While
the
same
non-member
resource
could
be
used
to
update
the
non-member
properties
via
PUT,
</del>
LDP
recommends
using
PATCH
<ins class="diff-new">to
update
these
properties,
if
necessary.
It
provides
no
facility
</ins>
for
<del class="diff-old">this
purpose.
</del>
<ins class="diff-chg">updating
them
via
PUT
without
replacing
the
entire
container's
state.
</ins>
</p>
<del class="diff-old">5.1.3
</del>
</section>
<section id="ldpc-ordering">
<h2 class="normal">
Ordering
</h2>
<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
becomes
more
important
for
<del class="diff-old">LDPC
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
when
containers
are
paginated.
If
the
server
does
not
respect
ordering
when
constructing
pages,
the
client
would
be
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
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
a
<del class="diff-old">higher
</del>
sort
order
<ins class="diff-new">no
lower
</ins>
than
all
members
on
the
previous
page
and
<del class="diff-old">lower
</del>
sort
order
<ins class="diff-new">no
higher
</ins>
than
all
the
members
on
the
next
<del class="diff-old">page.
</del>
<ins class="diff-chg">page;
that
is,
it
proceeds
from
low
to
high,
but
keep
in
mind
that
several
consecutive
pages
might
have
members
whose
sort
criteria
are
equal.
</ins>
When
the
sort
is
descending,
the
opposite
order
is
used.
Since
more
than
one
value
may
be
used
to
sort
members,
the
LDPC
specification
allows
servers
to
assert
the
ordered
list
of
sort
criteria
used
to
sort
the
members,
using
the
<code>
ldp:containerSortCriteria
</code>
relation.
Each
member
of
the
ordered
list
exposes
one
<code>
ldp:containerSortCriterion
</code>,
consisting
of
a
<code>
ldp:containerSortOrder
</code>,
<code>
ldp:containerSortPredicate
</code>,
and
optionally
a
<code>
ldp:containerSortCollation
</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" id="ldpc-ex-ordering">
<ins class="diff-chg"># The following is the ordered representation of
</ins>
#   http://example.org/netWorth/nw1/assetContainer/
<ins class="diff-new"># @base &lt;http://example.org/netWorth/nw1/assetContainer/&gt;
</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;
<del class="diff-old">&nbsp; &nbsp;a ldp:Container;
&nbsp; &nbsp;dcterms:title "The assets of JohnZSmith";
 &nbsp; ldp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
&nbsp; &nbsp;ldp:membershipPredicate o:asset;
   ldp:membershipObject ldp:MemberSubject.
</del>
<ins class="diff-chg">   a ldp:Container, ldp:DirectContainer;
   dcterms:title "The assets of JohnZSmith";
   ldp:containerResource &lt;http://example.org/netWorth/nw1&gt;;
   ldp:containsRelation o:asset;
   ldp:insertedContentRelation ldp:MemberSubject.
</ins>
&lt;?firstPage&gt;
   a ldp:Page;
<del class="diff-old"> &nbsp; ldp:pageOf &lt;&gt;;
   ldp:containerSortCriteria (#SortValueAscending).
</del>
<ins class="diff-chg">   ldp:pageOf &lt;&gt;;
   ldp:containerSortCriteria (&lt;#SortValueAscending&gt;).
</ins>
&lt;#SortValueAscending&gt;
   a ldp:ContainerSortCriterion;
<del class="diff-old"> &nbsp; ldp:containerSortOrder ldp:Ascending;
</del>
<ins class="diff-chg">   ldp:containerSortOrder ldp:Ascending;
</ins>
   ldp:containerSortPredicate o:value.
&lt;http://example.org/netWorth/nw1&gt;
<del class="diff-old">&nbsp; &nbsp;a o:NetWorth;
</del>
<ins class="diff-chg">   a o:NetWorth;
</ins>
   o:asset &lt;a1&gt;, &lt;a3&gt;, &lt;a2&gt;.
&lt;a1&gt;
<del class="diff-old">&nbsp;  a o:Stock;
 &nbsp; o:value 100.00.
</del>
<ins class="diff-chg">   a o:Stock;
   o:value 100.00 .
</ins>
&lt;a2&gt;
<del class="diff-old"> &nbsp; a o:Cash;
&nbsp; &nbsp;o:value 50.00.
</del>
<ins class="diff-chg">   a o:Cash;
   o:value 50.00 .
</ins>
&lt;a3&gt;
<del class="diff-old">&nbsp; &nbsp;a o:RealEstateHolding;
&nbsp;
&nbsp;o:value
300000.
</del>
<ins class="diff-chg">   a o:RealEstateHolding;
   o:value 300000 .
</ins>
</pre>
<p>
As
you
can
see
by
the
addition
of
the
<code>
ldp:ContainerSortCriteria
</code>
predicate,
the
<code>
o:value
</code>
predicate
is
used
to
order
the
page
members
in
ascending
order.
<del class="diff-old">&nbsp;It
</del>
<ins class="diff-chg">&#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.
<ins class="diff-new">Also
as
it
is
possible
for
a
container
to
have
as
its
members
other
containers,
the
ordering
approach
doesn't
change
as
containers
themselves
are
LDPRs
and
the
properties
from
the
domain
model
can
be
leveraged
for
the
sort
criteria.
</ins>
</p>
</section>
<del class="diff-old">5.2
</del>
</section>
<section id="ldpc-general">
<h2>
General
</h2>
<p>
The
Linked
Data
Platform
does
not
define
how
clients
discover
<dfn>
<abbr title="Linked Data Platform Containers">
LDPCs
</abbr>
</dfn>.
</p>
<del class="diff-old">5.2.1
LDPC
servers
MUST
also
be
conformant
LDPR
servers.
A
</del>
<section id="ldpc-isldpr">
<h2 class="normal">
<ins class="diff-chg">Each
</ins>
Linked
Data
Platform
Container
MUST
also
be
a
<del class="diff-old">conformant
</del>
<ins class="diff-chg">conforming
</ins><a title="">
Linked
Data
Platform
<del class="diff-old">Resource.
5.2.2
LDPC
membership
is
not
exclusive;
this
means
that
the
same
resource
(
LDPR
or
not)
which
is
identified
by
its
canonical
URI,
MAY
be
</del>
<ins class="diff-chg">RDF
Resource
</ins></a>.</h2></section><section id="ldpc-typecontainer"><h2 class="normal"><ins class="diff-chg">
The
representation
of
</ins>
a
<del class="diff-old">member
</del>
<ins class="diff-chg">LDPC
MUST
have
an
</ins><code><ins class="diff-chg">
rdf:type
</ins></code>
of
<del class="diff-old">more
than
</del>
<ins class="diff-chg">only
</ins>
one
<ins class="diff-chg">of:
</ins></h2><ul><li><code><ins class="diff-chg">
ldp:BasicContainer
</ins></code><ins class="diff-chg">
for
</ins><a title=""><ins class="diff-chg">
Linked
Data
Platform
Basic
Container
</ins></a></li><li><code><ins class="diff-chg">
ldp:DirectContainer
</ins></code><ins class="diff-chg">
for
</ins><a title=""><ins class="diff-chg">
Linked
Data
Platform
Direct
Container
</ins></a></li><li><code><ins class="diff-chg">
ldp:IndirectContainer
</ins></code><ins class="diff-chg">
for
</ins><a title=""><ins class="diff-chg">
Linked
Data
Platform
Indirect
Container
</ins></a></li></ul><ins class="diff-chg">
Non-normative
note:
</ins><a href="#ldp-rdfconcepts-extra-triples-types"><ins class="diff-chg">
LDPCs
might
have
additional
types
</ins></a>,<ins class="diff-chg">
like
any
RDF
resource.
</ins></section><section id="ldpc-nordfcontainertypes"><h2 class="normal">
LDPC
<del class="diff-old">.
5.2.3
</del>
<ins class="diff-chg">representations
SHOULD
NOT
use
RDF
container
types
</ins><code><ins class="diff-chg">
rdf:Bag
</ins></code>,<code><ins class="diff-chg">
rdf:Seq
</ins></code><ins class="diff-chg">
or
</ins><code><ins class="diff-chg">
rdf:List
</ins></code>.</h2></section><section id="ldpc-mbrpred"><h2 class="normal"><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
LDP
Direct
Containers
</ins></a><ins class="diff-chg">
and
</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
LDP
Indirect
Containers
</ins></a><ins class="diff-chg">
SHOULD
use
the
</ins><code><ins class="diff-chg">
ldp:member
</ins></code><ins class="diff-chg">
predicate
as
an
LDPC's
</ins><a title="Membership predicate"><ins class="diff-chg">
membership
predicate
</ins></a><ins class="diff-chg">
if
there
is
no
obvious
predicate
from
an
application
vocabulary
to
use
(
</ins><a title="Linked Data Platform Basic Container"><ins class="diff-chg">
LDP-BCs
</ins></a><a href="#ldpc-containtriple-basic"><ins class="diff-chg">
always
use
</ins><code><ins class="diff-chg">
ldp:contains
</ins></code></a><ins class="diff-chg">
).
</ins>
The
state
of
an
LDPC
includes
information
about
which
resources
are
its
<del class="diff-old">members.
In
the
simplest
cases,
</del>
<ins class="diff-chg">members,
in
</ins>
the
<ins class="diff-new">form
of
</ins><a title="Membership triples">
membership
<del class="diff-old">subject
will
be
the
LDPC
resource
itself,
but
it
does
not
have
to
be.
</del>
<ins class="diff-chg">triples
</ins></a><ins class="diff-chg">
that
follow
a
consistent
pattern.
</ins>
The
<ins class="diff-new">LDPC's
state
contains
enough
information
for
clients
to
discern
the
</ins><a title="Membership predicate">
membership
predicate
<del class="diff-old">is
also
variable
and
will
often
be
a
predicate
from
</del>
</a>,
the
<del class="diff-old">server
application
vocabulary.
If
there
is
no
obvious
predicate
from
</del>
<ins class="diff-chg">other
consistent
membership
value
used
in
</ins>
the
<del class="diff-old">server
application
vocabulary
to
use,
LDPC
servers
SHOULD
use
</del>
<ins class="diff-chg">container's
membership
triples
(
</ins><var><ins class="diff-chg">
membership-constant-URI
</ins></var><ins class="diff-chg">
),
and
</ins>
the
<del class="diff-old">rdfs:member
predicate.
</del>
<ins class="diff-chg">position
(subject
or
object)
where
those
URIs
occurs
in
the
</ins><a title="Membership triples"><ins class="diff-chg">
membership
triples
</ins></a>.
Member
resources
can
be
any
kind
of
resource
identified
by
<del class="diff-old">its
</del>
<ins class="diff-chg">a
</ins>
URI,
LDPR
or
otherwise.
<del class="diff-old">5.2.4
An
LDPC
</del>
</h2>
</section>
<section id="ldpc-containres">
<h2 class="normal">
<ins class="diff-chg">Each
</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
LDP
Direct
Container
</ins></a><ins class="diff-chg">
and
</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
LDP
Indirect
Container
</ins></a>
representation
MUST
contain
exactly
one
triple
whose
subject
is
the
LDPC
URI,
whose
predicate
is
the
<code>
<del class="diff-old">ldp:membershipSubject
</del>
<ins class="diff-chg">ldp:containerResource
</ins>
</code>,
and
whose
object
is
the
<del class="diff-old">LDPC
's
membership
</del>
<ins class="diff-chg">LDPC's
</ins><var><ins class="diff-chg">
membership-constant-URI
</ins></var>.<ins class="diff-chg">
Commonly
the
LDPC's
URI
is
the
</ins><var><ins class="diff-chg">
membership-constant-URI
</ins></var>,<ins class="diff-chg">
but
LDP
does
not
require
this.
</ins></h2><section id="ldpc-containres-basic"><h2 class="normal"><a title="Linked Data Platform Basic Container"><ins class="diff-chg">
LDP-BCs
</ins></a><ins class="diff-chg">
MUST
behave
as
if
their
state
contains
the
triple
whose
</ins>
subject
<del class="diff-old">URI.
5.2.5
An
</del>
<ins class="diff-chg">is
the
</ins>
LDPC
<ins class="diff-chg">URI,
whose
predicate
is
</ins><code><ins class="diff-chg">
ldp:containerResource
</ins></code>,<ins class="diff-chg">
and
whose
object
is
the
LDPC
URI
(subject
and
object
are
the
same
URI),
but
there
is
no
requirement
to
materialize
this
triple
in
LDP-BC
representations.
</ins></h2></section></section><section id="ldpc-containtriples"><h2 class="normal"><ins class="diff-chg">
Each
</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
LDP
Direct
Container
</ins></a><ins class="diff-chg">
and
</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
LDP
Indirect
Container
</ins></a>
representation
MUST
contain
exactly
one
triple
whose
subject
is
the
LDPC
URI,
and
whose
predicate
is
either
<code>
<del class="diff-old">ldp:membershipPredicate
</del>
<ins class="diff-chg">ldp:containsRelation
</ins>
</code>
or
<code>
<del class="diff-old">ldp:membershipPredicateInverse
</del>
<ins class="diff-chg">ldp:containedByRelation
</ins>
</code>.
The
object
of
the
triple
is
constrained
by
other
sections,
such
as
<del class="diff-old">5.2.5.1
</del>
<a href="#ldpc-containtriple-relation" class="sectionRef">
<ins class="diff-chg">ldp:containsRelation
</ins>
</a>
or
<del class="diff-old">5.2.5.2
.
5.2.5.1
For
a
given
</del>
<a href="#ldpc-containtriple-byrelation" class="sectionRef">
<ins class="diff-chg">ldp:containedByRelation
</ins></a>,<ins class="diff-chg">
based
on
the
</ins><a title="Membership triples"><ins class="diff-chg">
membership
triple
</ins></a><ins class="diff-chg">
pattern
used
by
the
container.
</ins></h2><section id="ldpc-containtriple-relation"><h2 class="normal"><ins class="diff-chg">
LDPCs
(
</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
Direct
</ins></a><ins class="diff-chg">
and
</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
Indirect
</ins></a><ins class="diff-chg">
Containers
only)
whose
</ins><a title="Membership triples"><ins class="diff-chg">
membership
</ins>
triple
</a>
<ins class="diff-new">pattern
is
</ins>
<var>
<del class="diff-old">T
</del>
<ins class="diff-chg">(
membership-constant-URI
,
membership-predicate
,
member-derived-URI
)
</ins>
</var>
<del class="diff-old">with
a
</del>
<ins class="diff-chg">MUST
contain
exactly
one
triple
whose
</ins>
subject
<del class="diff-old">C
of
</del>
<ins class="diff-chg">is
</ins>
the
LDPC
<del class="diff-old">and
</del>
<ins class="diff-chg">URI,
whose
</ins>
predicate
<del class="diff-old">of
</del>
<ins class="diff-chg">is
</ins>
<code>
<del class="diff-old">ldp:membershipPredicate
</del>
<ins class="diff-chg">ldp:containsRelation
</ins>
</code>,
<del class="diff-old">the
</del>
<ins class="diff-chg">and
whose
</ins>
object
<del class="diff-old">MUST
be
</del>
<ins class="diff-chg">is
</ins>
the
URI
of
<del class="diff-old">the
membership
predicate
</del>
<var>
<del class="diff-old">P
used
to
indicate
membership
to
</del>
<ins class="diff-chg">membership-predicate
</ins></var>.</h2><section id="ldpc-containtriple-basic"><h2 class="normal"><a title="Linked Data Platform Basic Container"><ins class="diff-chg">
LDP-BCs
</ins></a><ins class="diff-chg">
MUST
behave
as
if
their
state
contains
the
triple
whose
subject
is
</ins>
the
<del class="diff-old">linked
to
</del>
LDPC
<del class="diff-old">,
or
simply:
T
=
(
C
,
</del>
<ins class="diff-chg">URI,
whose
predicate
is
</ins>
<code>
<del class="diff-old">ldp:membershipPredicate
</del>
<ins class="diff-chg">ldp:containsRelation
</ins>
</code>,
<del class="diff-old">P)
.
For
the
membership
predicate
URI
</del>
<ins class="diff-chg">and
whose
</ins>
object
<del class="diff-old">used
in
the
</del>
<ins class="diff-chg">is
</ins><code><ins class="diff-chg">
ldp:contains
</ins></code>,<ins class="diff-chg">
but
there
is
no
requirement
to
materialize
this
</ins>
triple
<del class="diff-old">T
,
it
would
be
found
</del>
in
<del class="diff-old">a
resource's
same
subject
R
</del>
<ins class="diff-chg">LDP-BC
representations.
</ins></h2></section></section><section id="ldpc-containtriple-byrelation"><h2 class="normal"><ins class="diff-chg">
LDPCs
(
</ins><a title="Linked Data Platform Direct Container"><ins class="diff-chg">
Direct
</ins></a>
and
<del class="diff-old">same
predicate
P
</del>
<a title="Linked Data Platform Indirect Container">
<ins class="diff-chg">Indirect
</ins></a><ins class="diff-chg">
Containers
only)
whose
</ins><a title="Membership triples">
membership
<del class="diff-old">triples
of
the
form:
(
R
,
P
,
MR
),
where
MR
represents
URI
of
a
member
resource.
5.2.5.2
For
a
given
</del>
triple
</a>
<ins class="diff-new">pattern
is
</ins>
<var>
<del class="diff-old">T
</del>
<ins class="diff-chg">(
member-derived-URI
,
membership-predicate
,
membership-constant-URI
)
</ins>
</var>
<del class="diff-old">with
a
</del>
<ins class="diff-chg">MUST
contain
exactly
one
triple
whose
</ins>
subject
<del class="diff-old">C
of
</del>
<ins class="diff-chg">is
</ins>
the
LDPC
<del class="diff-old">and
</del>
<ins class="diff-chg">URI,
whose
</ins>
predicate
<del class="diff-old">of
</del>
<ins class="diff-chg">is
either
</ins>
<code>
<del class="diff-old">ldp:membershipPredicateInverse
</del>
<ins class="diff-chg">ldp:containedByRelation
</ins>
</code>,
<del class="diff-old">the
</del>
<ins class="diff-chg">and
whose
</ins>
object
<del class="diff-old">MUST
be
</del>
<ins class="diff-chg">is
</ins>
the
URI
of
<del class="diff-old">the
membership
predicate
</del>
<var>
<del class="diff-old">P
used
to
indicate
membership
to
</del>
<ins class="diff-chg">membership-predicate
</ins></var>.</h2></section></section><section id="ldpc-indirectmbr"><h2 class="normal"><ins class="diff-chg">
LDP
</ins><a title="Linked Data Platform Indirect Container"><ins class="diff-chg">
Indirect
</ins></a><ins class="diff-chg">
Containers
MUST
contain
exactly
one
triple
whose
subject
is
</ins>
the
<del class="diff-old">linked
to
</del>
LDPC
<del class="diff-old">,
or
simply:
T
=
(
C
,
</del>
<ins class="diff-chg">URI,
whose
predicate
is
</ins>
<code>
<del class="diff-old">ldp:membershipPredicateInverse
</del>
<ins class="diff-chg">ldp:insertedContentRelation
</ins>
</code>,
<del class="diff-old">P)
.
For
the
membership
predicate
URI
</del>
<ins class="diff-chg">and
whose
</ins>
object
<del class="diff-old">used
in
</del>
<var>
<ins class="diff-chg">ICR
</ins></var><ins class="diff-chg">
describes
how
</ins>
the
<del class="diff-old">triple
</del>
<var>
<del class="diff-old">T
,
it
would
be
found
</del>
<ins class="diff-chg">member-derived-URI
</ins></var>
in
<del class="diff-old">a
resource's
object
subject
</del>
<ins class="diff-chg">the
container's
</ins><a title="Membership triples"><ins class="diff-chg">
membership
triples
</ins></a><ins class="diff-chg">
is
chosen.
The
</ins>
<var>
<del class="diff-old">R
</del>
<ins class="diff-chg">member-derived-URI
</ins>
</var>
<del class="diff-old">and
same
predicate
</del>
<ins class="diff-chg">is
taken
from
some
triple
</ins>
<var>
<del class="diff-old">P
</del>
<ins class="diff-chg">(
S,
P,
O
)
</ins>
</var>
<del class="diff-old">membership
triples
of
</del>
<ins class="diff-chg">in
</ins>
the
<del class="diff-old">form:
(
</del>
<ins class="diff-chg">document
supplied
by
the
client
as
input
to
the
create
request;
if
</ins>
<var>
<del class="diff-old">MR
,
</del>
<ins class="diff-chg">ICR
</ins></var><ins class="diff-chg">
's
value
is
</ins>
<var>
P
</var>,
<ins class="diff-new">then
the
</ins>
<var>
<del class="diff-old">R
</del>
<ins class="diff-chg">member-derived-URI
</ins>
</var>
<del class="diff-old">),
where
</del>
<ins class="diff-chg">is
</ins>
<var>
<del class="diff-old">MR
represents
URI
of
a
member
resource.
5.2.6
The
representation
of
a
LDPC
MAY
include
an
arbitrary
number
of
additional
triples
whose
subjects
are
</del>
<ins class="diff-chg">O
</ins></var>.<ins class="diff-chg">
LDP
does
not
define
</ins>
the
<del class="diff-old">members
of
</del>
<ins class="diff-chg">behavior
when
more
than
one
triple
containing
</ins>
the
<del class="diff-old">container,
or
that
are
from
</del>
<ins class="diff-chg">predicate
</ins><var><ins class="diff-chg">
P
</ins></var><ins class="diff-chg">
is
present
in
</ins>
the
<del class="diff-old">representations
of
</del>
<ins class="diff-chg">client's
input.
For
example,
if
</ins>
the
<del class="diff-old">members
(if
they
have
</del>
<ins class="diff-chg">client
POSTs
</ins>
RDF
<del class="diff-old">representations).
This
allows
a
LDPC
server
</del>
<ins class="diff-chg">content
</ins>
to
<del class="diff-old">provide
clients
with
information
about
the
members
without
</del>
<ins class="diff-chg">a
container
that
causes
</ins>
the
<del class="diff-old">client
having
</del>
<ins class="diff-chg">container
</ins>
to
<del class="diff-old">do
</del>
<ins class="diff-chg">create
</ins>
a
<ins class="diff-new">new
LDPR,
and
that
content
contains
the
triple
</ins><var><ins class="diff-new">
(
&lt;&gt;
,
foaf:primaryTopic
,
bob#me
)
</ins></var>
<code>
<del class="diff-old">GET
</del>
<ins class="diff-chg">foaf:primaryTopic
</ins>
</code>
<del class="diff-old">on
each
member
individually.
See
sections
5.1.1
Container
Member
Information
,
section
4.11
,
</del>
<ins class="diff-chg">says
that
the
</ins><var><ins class="diff-chg">
member-derived-URI
</ins></var><ins class="diff-chg">
is
</ins><var><ins class="diff-chg">
bob#me
</ins></var>.</h2><section id="ldpc-indirectmbr-basic"><h2 class="normal"><ins class="diff-chg">
LDP
</ins><a title="Linked Data Platform Basic Container"><ins class="diff-chg">
Basic
</ins></a>
and
<del class="diff-old">section
5.10
</del>
<a title="Linked Data Platform Direct Container">
<ins class="diff-chg">Direct
</ins>
</a>
<del class="diff-old">for
additional
details.
5.2.7
The
representation
of
a
LDPC
</del>
<ins class="diff-chg">Containers
</ins>
MUST
<ins class="diff-chg">behave
as
if
they
</ins>
have
<ins class="diff-new">a
</ins><var><ins class="diff-new">
(
LDPC
URI,
</ins>
<code>
<del class="diff-old">rdf:type
</del>
<ins class="diff-chg">ldp:insertedContentRelation
</ins>
</code>
<del class="diff-old">of
ldp:Container
,
but
it
MAY
have
additional
</del>
<ins class="diff-chg">,
</ins>
<code>
<del class="diff-old">rdf:type
</del>
<ins class="diff-chg">ldp:MemberSubject
</ins>
</code>
<del class="diff-old">s.
5.2.8
LDPC
representations
SHOULD
NOT
use
RDF
container
types
rdf:Bag
,
</del>
<ins class="diff-chg">)
</ins></var><ins class="diff-chg">
triple,
but
LDP
imposes
no
requirement
to
materialize
such
a
triple
in
representations.
The
value
</ins>
<code>
<del class="diff-old">rdf:Seq
</del>
<ins class="diff-chg">ldp:MemberSubject
</ins>
</code>
<del class="diff-old">or
rdf:List
.
5.2.9
LDPC
servers
SHOULD
NOT
re-use
URIs,
regardless
of
</del>
<ins class="diff-chg">means
that
</ins>
the
<del class="diff-old">mechanism
</del>
<var>
<ins class="diff-chg">member-derived-URI
</ins></var><ins class="diff-chg">
is
the
URI
assigned
</ins>
by
<del class="diff-old">which
members
are
created
(
POST
,
PUT
,
etc.).
Certain
specific
cases
exist
where
a
LDPC
</del>
<ins class="diff-chg">the
</ins>
server
<del class="diff-old">MAY
delete
</del>
<ins class="diff-chg">to
</ins>
a
<del class="diff-old">resource
and
then
later
re-use
the
URI
when
</del>
<ins class="diff-chg">document
</ins>
it
<del class="diff-old">identifies
</del>
<ins class="diff-chg">creates;
for
example,
if
</ins>
the
<del class="diff-old">same
resource,
but
only
when
consistent
with
Web
architecture
[
WEBARCH
].
While
it
is
difficult
</del>
<ins class="diff-chg">client
POSTs
content
</ins>
to
<del class="diff-old">provide
absolute
implementation
guarantees
of
non-reuse
in
all
failure
scenarios,
re-using
URIs
creates
ambiguities
for
clients
</del>
<ins class="diff-chg">a
container
</ins>
that
<del class="diff-old">are
best
avoided.
5.2.10
Some
LDPC
s
have
membership
objects
</del>
<ins class="diff-chg">causes
the
container
to
create
a
new
LDPR,
</ins><code><ins class="diff-chg">
ldp:MemberSubject
</ins></code><ins class="diff-chg">
says
</ins>
that
<del class="diff-old">are
not
directly
URIs
minted
upon
LDPC
member
creation,
for
example
URIs
with
non-empty
fragment
identifier
[
RFC3986
].
To
determine
which
object
</del>
<ins class="diff-chg">the
</ins><var><ins class="diff-chg">
member-derived-URI
</ins></var><ins class="diff-chg">
is
the
</ins>
URI
<ins class="diff-new">assigned
</ins>
to
<del class="diff-old">use
for
</del>
the
<del class="diff-old">membership
triple,
LDPC
s
</del>
<ins class="diff-chg">newly
created
LDPR.
</ins></h2></section></section><section id="ldpc-linktypehdr"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
exposing
LDPCs
</ins>
MUST
<del class="diff-old">contain
one
triple
whose
subject
is
the
LDPC
URI,
predicate
is
</del>
<ins class="diff-chg">advertise
their
LDP
support
by
exposing
a
HTTP
</ins>
<code>
<del class="diff-old">ldp:membershipObject
,
</del>
<ins class="diff-chg">Link
</ins></code><ins class="diff-chg">
header
</ins>
with
<del class="diff-old">an
object
MO
.
Where
MO
and
the
HTTP
</del>
<ins class="diff-chg">a
target
</ins>
URI
<del class="diff-old">R
from
</del>
<ins class="diff-chg">of
</ins>
<code>
<del class="diff-old">POST
</del>
<ins class="diff-chg">http://www.w3.org/ns/ldp#Container
</ins></code>,<ins class="diff-chg">
and
a
link
relation
type
of
</ins><code><ins class="diff-chg">
type
</ins>
</code>
<del class="diff-old">create
(as
found
</del>
<ins class="diff-chg">(that
is,
</ins><code><ins class="diff-chg">
rel='type'
</ins></code><ins class="diff-chg">
)
</ins>
in
<ins class="diff-new">all
responses
to
requests
made
to
the
LDPC's
</ins>
HTTP
<del class="diff-old">response
</del>
<code>
<del class="diff-old">Location
</del>
<ins class="diff-chg">Request-URI
</ins></code>.<a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
MAY
provide
additional
HTTP
</ins><code><ins class="diff-chg">
Link:
rel='type'
</ins>
</code>
<del class="diff-old">header)
can
be
used
</del>
<ins class="diff-chg">headers
</ins>
to
<del class="diff-old">locate
</del>
<ins class="diff-chg">advertise
their
support
for
</ins><a href="#ldpc-typecontainer"><ins class="diff-chg">
specific
LDPC
types
</ins></a>.<ins class="diff-chg">
The
</ins><a href="#ldpr-gen_linktypehdr"><ins class="diff-chg">
notes
on
the
corresponding
LDPR
constraint
</ins></a><ins class="diff-chg">
apply
equally
to
LDPCs.
</ins></h2></section><section id="ldpc-prefer"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a><ins class="diff-chg">
SHOULD
respect
all
of
</ins>
a
<del class="diff-old">triple
</del>
<ins class="diff-chg">client's
LDP-defined
hints,
for
example
</ins><a href="#prefer-parameters"><ins class="diff-chg">
which
subsets
</ins>
of
<ins class="diff-new">LDP-defined
state
</ins></a>
the
<del class="diff-old">form:
(R,
MO,
N)
and
where
N
can
be
used
</del>
<ins class="diff-chg">client
is
interested
in
processing,
</ins>
to
<del class="diff-old">construct
</del>
<ins class="diff-chg">influence
</ins>
the
<del class="diff-old">membership
triple
</del>
<ins class="diff-chg">set
</ins>
of
<del class="diff-old">the
form:
(membership
subject,
membership
predicate,
N)
.
When
ldp:membershipPredicateInverse
is
used
instead
</del>
<ins class="diff-chg">triples
returned
in
representations
</ins>
of
<del class="diff-old">ldp:membershipPredicate
,
</del>
<ins class="diff-chg">an
LDPC,
particularly
for
large
LDPCs.
Non-normative
note:
</ins>
the
<del class="diff-old">membership
triple
MUST
</del>
<ins class="diff-chg">LDPC
might
</ins>
be
<del class="diff-old">of
the
form:
(N,
membership
predicate,
membership
subject)
.
To
indicate
</del>
<ins class="diff-chg">paged;
</ins><a title="Paged resource"><ins class="diff-chg">
paged
resources
</ins></a><ins class="diff-chg">
provide
no
guarantee
</ins>
that
<del class="diff-old">the
member
resource
URI
is
the
membership
object
(the
default
</del>
<ins class="diff-chg">all
triples
of
a
given
subset,
for
example
</ins><a title="Containment triples"><ins class="diff-chg">
containment
triples
</ins></a>,<ins class="diff-chg">
are
grouped
together
on
one
page
</ins>
or
<del class="diff-old">typical
case),
the
object
MUST
be
set
to
predefined
URI
ldp:MemberSubject
such
that
it
forms
the
triple:
(
LDPC
URI,
ldp:membershipObject
,
ldp:MemberSubject
)
.
</del>
<ins class="diff-chg">on
a
sequence
of
consecutive
</ins><a title="Single-page resource"><ins class="diff-chg">
pages
</ins></a><ins class="diff-chg">
(see
</ins><a href="#ldpr-Paging" class="sectionRef">
<del class="diff-old">5.3
</del>
</a>
<ins class="diff-chg">).
</ins></h2></section></section><section id="ldpc-HTTP_GET"><h2>
HTTP
GET
<del class="diff-old">5.3.1
</del>
</h2>
<section id="ldpc-get-mbrtriples">
<h2 class="normal">
The
representation
of
a
LDPC
MUST
contain
a
set
of
<a title="Membership triples">
<ins class="diff-new">membership
</ins>
triples
<del class="diff-old">with
a
consistent
subject
and
predicate
whose
objects
indicate
members
</del>
</a>
<ins class="diff-chg">following
one
</ins>
of
the
<del class="diff-old">container.
</del>
<ins class="diff-chg">consistent
patterns
from
that
definition.
</ins>
The
<del class="diff-old">subject
</del>
<ins class="diff-chg">membership-constant-URI
</ins>
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">&nbsp;See
</del>
<ins class="diff-chg">&#160;See
</ins>
also
<del class="diff-old">5.2.3
.
5.3.2
</del>
<ins class="diff-chg">section
on
</ins><a href="#ldpc-mbrpred">
LDPC
<ins class="diff-chg">membership
predicates
</ins></a>.</h2></section><section id="ldpc-sortcriteriaobj"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
</ins>
servers
</a>
MAY
represent
the
members
of
a
paged
LDPC
in
a
sequential
order.
<del class="diff-old">&nbsp;If
</del>
<ins class="diff-chg">&#160;If
</ins>
the
server
does
so,
it
MUST
<del class="diff-old">be
</del>
specify
the
order
using
a
triple
whose
subject
is
the
page
URI,
whose
predicate
is
<code>
ldp:containerSortCriteria
</code>,
and
whose
object
is
a
<code>
rdf:List
</code>
of
<code>
ldp:containerSortCriterion
</code>
resources.
The
resulting
order
MUST
be
as
defined
by
SPARQL
<code>
SELECT
</code>
’s
<code>
ORDER
BY
</code>
clause
<del class="diff-old">[
SPARQL-QUERY
].
</del>
<ins class="diff-chg">[[!SPARQL-QUERY]].
</ins>
Sorting
criteria
<del class="diff-old">MUST
&nbsp;be
</del>
<ins class="diff-chg">MUST&#160;be
</ins>
the
same
for
all
pages
of
a
representation;
if
the
criteria
were
allowed
to
vary,
the
ordering
among
members
of
a
container
across
pages
would
be
undefined.
The
first
list
entry
provides
the
primary
sorting
criterion,
any
second
entry
provides
a
secondary
criterion
used
to
order
members
considered
equal
according
to
the
primary
criterion,
and
so
on.
See
section
<del class="diff-old">5.1.4
Ordering
</del>
<a href="#ldpc-ordering" class="sectionRef">
</a>
for
an
example.
<del class="diff-old">5.3.3
</del>
</h2>
</section>
<section id="ldpc-sortliteraltype">
<h2 class="normal">
LDPC
page
representations
ordered
using
<code>
ldp:containerSortCriteria
</code>
MUST
contain,
in
every
<code>
ldp:containerSortCriterion
</code>
list
entry,
a
triple
whose
subject
is
the
sort
criterion
identifier,
whose
predicate
is
<code>
ldp:containerSortPredicate
</code>
and
whose
object
is
the
predicate
whose
value
is
used
to
order
members
between
pages
(the
<dfn>
page-ordering
values
</dfn>
).
The
only
<del class="diff-old">predicate
</del>
<ins class="diff-chg">literal
</ins>
data
types
whose
behavior
LDP
constrains
are
those
defined
by
SPARQL
<code>
SELECT
</code>
’s
<code>
ORDER
BY
</code>
clause
<del class="diff-old">[
SPARQL-QUERY
].
</del>
<ins class="diff-chg">[[!SPARQL-QUERY]].
</ins>
Other
data
types
can
be
used,
but
LDP
assigns
no
meaning
to
them
and
interoperability
will
be
limited.
<del class="diff-old">5.3.4
</del>
</h2>
</section>
<section id="ldpc-sortorder">
<h2 class="normal">
LDPC
page
representations
ordered
using
<code>
ldp:containerSortCriteria
</code>
MUST
contain,
in
every
<code>
ldp:containerSortCriterion
</code>
list
entry,
a
triple
whose
subject
is
the
sort
criterion
identifier,
whose
predicate
is
<code>
ldp:containerSortOrder
</code>
and
whose
object
describes
the
order
used.
LDP
defines
two
values,
<code>
ldp:Ascending
</code>
and
<code>
ldp:Descending
</code>,
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.
<del class="diff-old">5.3.5
</del>
</h2>
</section>
<section id="ldpc-sortcollation">
<h2 class="normal">
LDPC
page
representations
ordered
using
<code>
ldp:containerSortCriteria
</code>
MAY
contain,
in
any
<code>
ldp:containerSortCriterion
</code>
list
entry,
a
triple
whose
subject
is
the
sort
criterion
identifier,
whose
predicate
is
<code>
ldp:containerSortCollation
</code>
and
whose
object
identifies
the
collation
used.
LDP
defines
no
values
for
use
as
the
object
of
this
triple.
While
it
is
better
for
interoperability
to
use
open
standardized
values,
any
value
can
be
used.
When
the
<code>
ldp:containerSortCollation
</code>
triple
is
absent
and
the
<a title="page-ordering values">
page-ordering
values
</a>
are
strings
or
simple
literals
<del class="diff-old">[
SPARQL-QUERY
],
</del>
<ins class="diff-chg">[[!SPARQL-QUERY]],
</ins>
the
resulting
order
is
as
defined
by
SPARQL
SELECT’s
ORDER
BY
clause
<del class="diff-old">[
SPARQL-QUERY
]
</del>
<ins class="diff-chg">[[!SPARQL-QUERY]]
</ins>
using
two-argument
<code>
fn:compare
</code>,
that
is,
it
behaves
as
if
<code>
http://www.w3.org/2005/xpath-functions/collation/codepoint
</code>
was
the
specified
collation.
When
the
<code>
ldp:containerSortCollation
</code>
triple
is
present
and
the
<a title="page-ordering values">
page-ordering
values
</a>
are
strings
or
simple
literals
<del class="diff-old">[
SPARQL-QUERY
],
</del>
<ins class="diff-chg">[[!SPARQL-QUERY]],
</ins>
the
resulting
order
is
as
defined
by
SPARQL
SELECT’s
ORDER
BY
clause
<del class="diff-old">[
SPARQL-QUERY
]
</del>
<ins class="diff-chg">[[!SPARQL-QUERY]]
</ins>
using
three-argument
<code>
fn:compare
</code>,
that
is,
the
specified
collation.
The
<code>
ldp:containerSortCollation
</code>
triple
<del class="diff-old">SHOULD
</del>
<ins class="diff-chg">MUST
</ins>
be
omitted
for
comparisons
involving
<a title="page-ordering values">
page-ordering
values
</a>
for
which
<del class="diff-old">[
SPARQL-QUERY
]
</del>
<ins class="diff-chg">[[!SPARQL-QUERY]]
</ins>
does
not
use
collations.
</h2>
</section>
<del class="diff-old">5.4
</del>
</section>
<section id="ldpc-HTTP_POST">
<h2>
HTTP
POST
</h2>
<p>
<del class="diff-old">This
specification
imposes
the
following
new
requirements
on
</del>
<ins class="diff-chg">Per
[HTTP11],
this
</ins>
HTTP
<del class="diff-old">POST
for
LDPCs
only
when
an
LDPC
supports
that
method.
This
</del>
<ins class="diff-chg">method
is
optional
and
this
</ins>
specification
does
not
<del class="diff-old">impose
any
new
requirement
</del>
<ins class="diff-chg">require
</ins><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a>
to
support
<del class="diff-old">that
</del>
<ins class="diff-chg">it.
When
a
LDP
server
chooses
to
support
this
</ins>
method,
<del class="diff-old">and
[
HTTP11
</del>
<ins class="diff-chg">this
specification
imposes
the
following
new
requirements
for
LDPCs.
</ins></p><p><ins class="diff-chg">
Any
server-imposed
constraints
on
creation
or
update
</ins><a href="#ldpr-gen-pubclireqs"><ins class="diff-chg">
must
be
advertised
</ins>
</a>
<del class="diff-old">]
makes
it
optional.
</del>
<ins class="diff-chg">to
clients.
</ins>
</p>
<del class="diff-old">5.4.1
</del>
<section id="ldpc-post-created201">
<h2 class="normal">
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.
</ins>
If
the
resource
was
created
successfully,
<del class="diff-old">LDPC
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MUST
respond
with
status
code
201
(Created)
and
the
<code>
Location
</code>
header
set
to
the
new
resource’s
URL.
Clients
shall
not
expect
any
representation
in
the
response
entity
body
on
a
201
(Created)
response.
<del class="diff-old">5.4.2
After
</del>
</h2>
</section>
<section id="ldpc-post-createdmbr-contains">
<h2 class="normal">
<ins class="diff-chg">When
</ins>
a
successful
HTTP
<code>
POST
</code>
request
to
a
LDPC
<del class="diff-old">,
</del>
<ins class="diff-chg">results
in
</ins>
the
<del class="diff-old">new
resource
</del>
<ins class="diff-chg">creation
of
an
LDPR,
the
newly
created
document
</ins>
MUST
appear
as
a
<del class="diff-old">member
</del>
<ins class="diff-chg">contained
resource
</ins>
of
the
LDPC
until
the
<del class="diff-old">new
resource
</del>
<ins class="diff-chg">newly
created
document
</ins>
is
deleted
or
removed
by
other
methods.
<del class="diff-old">An
</del>
</h2>
</section>
<section id="ldpc-post-createdmbr-member">
<h2 class="normal">
<ins class="diff-chg">When
a
successful
HTTP
</ins><code><ins class="diff-chg">
POST
</ins></code><ins class="diff-chg">
request
to
a
</ins>
LDPC
<del class="diff-old">MAY
also
contain
resources
that
were
added
through
other
means
-
for
example
through
</del>
<ins class="diff-chg">results
in
</ins>
the
<del class="diff-old">user
interface
</del>
<ins class="diff-chg">creation
</ins>
of
<ins class="diff-new">an
LDPR,
</ins>
the
<del class="diff-old">site
</del>
<ins class="diff-chg">LDPC
MUST
update
its
membership
triples
to
reflect
</ins>
that
<del class="diff-old">implements
</del>
<ins class="diff-chg">addition,
and
</ins>
the
<del class="diff-old">LDPC
.
5.4.3
LDPC
</del>
<ins class="diff-chg">resulting
membership
triple
MUST
be
consistent
with
any
LDP-defined
predicates
it
exposes.
A
Direct
or
Indirect
container's
membership
triples
MAY
also
be
modified
via
through
other
means.
</ins></h2></section><section id="ldpc-post-createbins"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
</ins>
servers
</a>
MAY
accept
an
HTTP
<code>
POST
</code>
of
<del class="diff-old">non-
RDF
</del>
<ins class="diff-chg">non-RDF
</ins>
representations
<a title="Linked Data Platform Binary Resource">
<ins class="diff-new">(LDP-BRs)
</ins></a>
for
creation
of
any
kind
of
resource,
for
example
binary
resources.
See
<del class="diff-old">5.4.13
</del>
<a href="#ldpc-post-acceptposthdr">
<ins class="diff-chg">the
Accept-Post
section
</ins>
</a>
for
<del class="diff-old">introspection
details.
5.4.4
For
servers
that
support
create,
</del>
<ins class="diff-chg">details
on
how
clients
can
discover
whether
a
</ins>
LDPC
<ins class="diff-chg">supports
this
behavior.
</ins></h2></section><section id="ldpc-post-createrdf"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
</ins>
servers
<del class="diff-old">MUST
</del>
</a>
<ins class="diff-chg">that
successfully
</ins>
create
<del class="diff-old">an
LDPR
</del>
<ins class="diff-chg">a
resource
</ins>
from
a
RDF
representation
in
the
request
entity
<del class="diff-old">body.
</del>
<ins class="diff-chg">body
MUST
honor
the
client's
requested
interaction
model(s).
</ins>
The
<del class="diff-old">newly
</del>
created
<del class="diff-old">LDPR
could
also
</del>
<ins class="diff-chg">resource
can
</ins>
be
<del class="diff-old">a
</del>
<ins class="diff-chg">thought
of
as
an
RDF
</ins><a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph"><ins class="diff-chg">
named
graph
</ins></a><ins class="diff-chg">
[[rdf11-concepts]].
If
any
model
cannot
be
honored,
the
server
MUST
fail
the
request.
</ins></h2><ul><li><ins class="diff-chg">
If
the
request
header
</ins><a href="#ldpr-gen-linktypehdr"><ins class="diff-chg">
specifies
an
LDPR
interaction
model
</ins></a>,<ins class="diff-chg">
then
the
server
MUST
create
an
LDPR.
</ins></li><li><ins class="diff-chg">
If
the
request
header
</ins><a href="#ldpc-linktypehdr"><ins class="diff-chg">
specifies
an
</ins>
LDPC
<del class="diff-old">,
therefore
servers
MAY
allow
</del>
<ins class="diff-chg">interaction
model
</ins></a>,<ins class="diff-chg">
then
</ins>
the
<del class="diff-old">creation
</del>
<ins class="diff-chg">server
MUST
create
an
LDPC.
</ins></li><li><ins class="diff-chg">
This
specification
does
not
constrain
the
server's
behavior
in
other
cases.
</ins></li><li style="list-style: none; display: inline"><p><ins class="diff-chg">
Note:
A
consequence
</ins>
of
<ins class="diff-chg">this
is
that
</ins>
LDPCs
<del class="diff-old">within
a
LDPC
.
5.4.5
LDPC
</del>
<ins class="diff-chg">can
be
used
to
create
LDPCs,
if
the
server
supports
doing
so.
</ins></p></li></ul></section><section id="ldpc-post-turtle"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
</ins>
servers
</a>
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></h2></section><section id="ldpc-post-contenttype"><h2 class="normal">
<del class="diff-old">].
5.4.6
LDPC
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
SHOULD
use
the
<code>
Content-Type
</code>
request
header
to
determine
the
representation
format
when
the
request
has
an
entity
body.
<del class="diff-old">When
the
header
is
absent,
LDPC
servers
MAY
infer
the
content
type
by
inspecting
the
entity
body
contents
[
HTTP11
].
5.4.7
</del>
</h2>
</section>
<section id="ldpc-post-rdfnullrel">
<h2 class="normal">
In
RDF
representations,
<del class="diff-old">LDPC
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
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">&nbsp;
5.4.8
LDPC
</del>
<ins class="diff-chg">&#160;
</ins></h2></section><section id="ldpc-post-serverassignuri"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
</ins>
servers
</a>
SHOULD
assign
the
<del class="diff-old">subject
</del>
URI
for
the
resource
to
be
created
using
server
application
specific
rules
in
the
absence
of
a
<a href="#ldpc-post-slug">
client
hint
</a>.
<del class="diff-old">5.4.9
LDPC
</del>
</h2>
</section>
<section id="ldpc-post-mincontraints">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
SHOULD
allow
clients
to
create
new
resources
without
requiring
detailed
knowledge
of
application-specific
constraints.
This
is
a
consequence
of
the
requirement
to
enable
simple
creation
and
modification
of
<del class="diff-old">LPDRs.
5.4.10
LDPC
</del>
<ins class="diff-chg">LDPRs.
</ins></h2></section><section id="ldpc-post-slug"><h2 class="normal"><a title="LDP server"><ins class="diff-chg">
LDP
</ins>
servers
</a>
MAY
allow
clients
to
suggest
the
URI
for
a
resource
created
through
<code>
POST
</code>,
using
the
HTTP
<code>
Slug
</code>
header
as
defined
in
<del class="diff-old">[
RFC5023
].
</del>
<ins class="diff-chg">[[!RFC5023]].
</ins>
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.
<del class="diff-old">5.4.11
LDPC
</del>
</h2>
</section>
<section id="ldpc-post-dontreuseuris">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
that
allow
member
creation
via
<code>
POST
</code>
SHOULD
NOT
re-use
<del class="diff-old">URIs,
per
the
general
requirements
on
LDPCs
.
5.4.12
</del>
<ins class="diff-chg">URIs.
</ins></h2></section><section id="ldpc-post-createbinlinkmetahdr"><h2 class="normal">
Upon
successful
creation
of
a
<del class="diff-old">non-
RDF
and
therefore
non-
LDPR
member
</del>
<a title="Linked Data Platform Binary Resource">
<ins class="diff-chg">LDP-BR
</ins></a>
(HTTP
status
code
of
201-Created
and
URI
indicated
by
<code>
Location
</code>
response
header),
<del class="diff-old">LDPC
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
MAY
create
an
associated
<del class="diff-old">LDPR
</del>
<a title="Linked Data Platform RDF Resource">
<ins class="diff-chg">LDP-RR
</ins></a>
to
contain
data
about
the
<ins class="diff-new">newly
</ins>
created
<del class="diff-old">resource.
</del>
<ins class="diff-chg">LDP-BR.
</ins>
If
an
LDPC
server
creates
this
associated
<del class="diff-old">LDPR
</del>
<a title="Linked Data Platform RDF Resource">
<ins class="diff-chg">LDP-RR
</ins></a>
it
MUST
indicate
its
location
on
the
HTTP
response
using
the
HTTP
<del class="diff-old">response
header
</del>
<code>
Link
</code>
<del class="diff-old">and
relationship
type
</del>
<ins class="diff-chg">response
header
with
link
relation
</ins>
<code>
meta
</code>
and
<code>
href
</code>
to
be
the
URI
of
the
meta-resource
<del class="diff-old">[
RFC5988
</del>
<ins class="diff-chg">[[!RFC5988]].
</ins></h2></section><section id="ldpc-post-acceptposthdr"><h2 class="normal">
<del class="diff-old">].
5.4.13
LDPC
</del>
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
that
support
<code>
POST
</code>
MUST
include
an
<a href="#header-accept-post">
<code>
Accept-Post
</code>
response
header
</a>
on
HTTP
<code>
OPTIONS
</code>
responses,
listing
post
document
media
type(s)
supported
by
the
server.
LDP
only
specifies
the
use
of
<code>
POST
</code>
for
the
purpose
of
creating
new
resources,
but
a
server
can
accept
<code>
POST
</code>
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
<code>
POST
</code>
request
will
result
in
the
creation
of
a
new
resource;
they
must
rely
on
out
of
band
information
for
knowledge
of
which
<code>
POST
</code>
requests,
if
any,
will
have
the
"create
new
resource"
semantics.
This
requirement
on
LDP
servers
is
intentionally
stronger
than
the
one
levied
in
the
<a href="#header-accept-post">
header
registration
</a>
;
it
is
unrealistic
to
expect
all
existing
resources
that
support
<code>
POST
</code>
to
suddenly
return
a
new
header
or
for
all
new
specifications
constraining
<code>
POST
</code>
to
be
aware
of
its
existence
and
require
it,
but
it
is
a
reasonable
requirement
for
new
specifications
such
as
LDP.
<del class="diff-old">5.4.14
</del>
</h2>
</section>
<section id="ldpc-post-ldpcreated">
<h2 class="normal">
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
<code>
<del class="diff-old">ldp:created
</del>
<ins class="diff-chg">ldp:contains
</ins>
</code>
predicate
for
this
purpose.
An
LDPC
that
tracks
members
created
through
the
LDPC
MUST
add
a
triple
<ins class="diff-new">to
the
container
</ins>
whose
subject
is
the
container's
URI,
whose
predicate
is
<code>
<del class="diff-old">ldp:created
</del>
<ins class="diff-chg">ldp:contains
</ins>
</code>,
and
whose
object
is
the
newly
created
member
resource's
URI;
it
MAY
add
other
triples
as
well.
</h2>
</section>
<del class="diff-old">5.5
HTTP
PUT
This
specification
imposes
the
following
new
requirements
on
HTTP
</del>
<section id="ldpc-post-indirectmbrrel">
<h2 class="normal">
<ins class="diff-chg">LDPCs
whose
</ins>
<code>
<del class="diff-old">PUT
</del>
<ins class="diff-chg">ldp:insertedContentRelation
</ins>
</code>
<del class="diff-old">for
LDPCs
only
when
</del>
<ins class="diff-chg">triple
has
</ins>
an
<del class="diff-old">LDPC
supports
</del>
<ins class="diff-chg">object
</ins><strong><ins class="diff-chg">
other
than
</ins></strong><code><ins class="diff-chg">
ldp:MemberSubject
</ins></code><ins class="diff-chg">
and
</ins>
that
<del class="diff-old">method.
</del>
<ins class="diff-chg">create
new
resources
MUST
add
a
triple
to
the
container
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
resource's
URI
(which
will
be
different
from
the
</ins><var><a href="#ldpc-indirectmbr"><ins class="diff-chg">
member-derived
URI
</ins></a></var><ins class="diff-chg">
in
this
case).
</ins>
This
<code>
<ins class="diff-new">ldp:contains
</ins></code><ins class="diff-new">
triple
can
be
the
only
link
from
the
container
to
the
newly
created
resource
in
certain
cases.
</ins></h2></section></section><section id="ldpc-HTTP_PUT"><h2><ins class="diff-new">
HTTP
PUT
</ins></h2><p><ins class="diff-new">
Per
[HTTP11],
this
HTTP
method
is
optional
and
this
</ins>
specification
does
not
<del class="diff-old">impose
any
new
requirement
</del>
<ins class="diff-chg">require
</ins><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a>
to
support
<del class="diff-old">that
</del>
<ins class="diff-chg">it.
When
a
LDP
server
chooses
to
support
this
</ins>
method,
<del class="diff-old">and
[
HTTP11
</del>
<ins class="diff-chg">this
specification
imposes
the
following
new
requirements
for
LDPCs.
</ins></p><p><ins class="diff-chg">
Any
server-imposed
constraints
on
creation
or
update
</ins><a href="#ldpr-gen-pubclireqs"><ins class="diff-chg">
must
be
advertised
</ins>
</a>
<del class="diff-old">]
makes
it
optional.
</del>
<ins class="diff-chg">to
clients.
</ins>
</p>
<del class="diff-old">5.5.1
LDPC
</del>
<section id="ldpc-put-mbrprops">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
</a>
SHOULD
NOT
allow
HTTP
<code>
PUT
</code>
to
update
a
<del class="diff-old">LDPC
’s
</del>
<ins class="diff-chg">LDPC’s
</ins><a>
membership
triples
</a>
;
if
the
server
receives
such
a
request,
it
SHOULD
respond
with
a
409
(Conflict)
status
code.
<del class="diff-old">5.5.2
LDPC
servers
MAY
allow
updating
LDPC
non-membership
properties
using
HTTP
PUT
on
a
corresponding
non-member
resource
,
which
MAY
exclude
server-managed
properties
such
as
ldp:membershipSubject
,
ldp:membershipPredicate
and
ldp:membershipPredicateInverse
.
The
section
5.9
describes
the
process
by
which
clients
use
HTTP
OPTIONS
to
discover
whether
the
server
offers
such
a
resource,
and
if
so
its
URL.
5.5.3
LDPC
</del>
</h2>
</section>
<section id="ldpc-put-create">
<h2 class="normal">
<a title="LDP server">
<ins class="diff-chg">LDP
</ins>
servers
<del class="diff-old">SHOULD
NOT
allow
HTTP
PUT
requests
with
inlined
member
information
in
the
request
representation.
See
section
5.1.1
Container
Member
Information
</del>
</a>
<del class="diff-old">for
additional
details.
5.5.4
LDPC
servers
</del>
that
allow
member
creation
via
<code>
PUT
</code>
SHOULD
NOT
re-use
<del class="diff-old">URIs,
per
the
general
requirements
on
LDPCs
.
</del>
<ins class="diff-chg">URIs.
For
RDF
representations
(LDP-RRs),the
created
resource
can
be
thought
of
as
a
RDF
</ins><a href="http://www.w3.org/TR/rdf11-concepts/#dfn-named-graph"><ins class="diff-chg">
named
graph
</ins></a><ins class="diff-chg">
[[rdf11-concepts]].
</ins></h2>
</section>
<del class="diff-old">5.6
</del>
</section>
<section id="ldpc-HTTP_DELETE">
<h2>
HTTP
DELETE
</h2>
<p>
<del class="diff-old">This
specification
imposes
the
following
new
requirements
on
</del>
<ins class="diff-chg">Per
[HTTP11],
this
</ins>
HTTP
<del class="diff-old">DELETE
for
LDPRs
</del>
<ins class="diff-chg">method
is
optional
</ins>
and
<del class="diff-old">LDPCs
only
when
a
LDPC
supports
that
method.
This
</del>
<ins class="diff-chg">this
</ins>
specification
does
not
<del class="diff-old">impose
any
new
requirement
</del>
<ins class="diff-chg">require
</ins><a title="LDP server"><ins class="diff-chg">
LDP
servers
</ins></a>
to
support
<del class="diff-old">that
</del>
<ins class="diff-chg">it.
When
a
LDP
server
chooses
to
support
this
</ins>
method,
<del class="diff-old">and
[
HTTP11
]
makes
it
optional.
</del>
<ins class="diff-chg">this
specification
imposes
the
following
new
requirements
for
LDPCs.
</ins>
</p>
<del class="diff-old">5.6.1
</del>
<section id="ldpc-del-contremovesmbrtriple">
<h2 class="normal">
When
a
LDPC
<del class="diff-old">member
</del>
<ins class="diff-chg">contained
</ins>
resource
<del class="diff-old">originally
created
by
the
LDPC
(for
example,
one
whose
representation
was
HTTP
POST
ed
to
the
LDPC
and
then