This
document
describes
the
use
of
HTTP
for
accessing,
updating,
creating
and
deleting
resources
from
servers
that
expose
their
resources
as
Linked
Data.
It
It
provides
some
new
rules
as
well
as
clarifications
and
extensions
of
the
four
rules
of
Linked
Data
[
LINKED-DATA
]
[[LINKED-DATA]]:
1. Use URIs as names for things
2. Use HTTP URIs so that people can look up those names
3.
When
someone
looks
up
a
URI,
provide
useful
information,
using
the
standards
(RDF*,
SPARQL)
SPARQL
)
4. Include links to other URIs. so that they can discover more things
The best practices and anti-patterns covered in this document are:
Resources - a summary of the HTTP and RDF standard techniques and best practices that you should use, and anti-patterns you should avoid, when constructing clients and servers that read and write linked data.
Containers
-
defines
resources
that
allow
new
resources
to
be
created
using
HTTP
POST
and
existing
resources
to
be
found
using
HTTP
GET.
GET.
Additionally,
it
is
the
intention
of
this
document
to
enable
additional
rules
and
layered
groupings
of
rules,
such
as
additional
specifications.
The
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
on
and
implementations
will
support.
Terminology
is
based
on
W3C
's
W3C's
Architecture
of
the
World
Wide
Web
[
WEBARCH
]
[[WEBARCH]]
and
Hyper-text
Transfer
Protocol
[
HTTP11
]
[[HTTP11]].
WEBARCH
LINKED-DATA
HTTP11
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.
[
HTTP11
request
[[HTTP11]].
2.1
Sample
resource
representations
are
provided
in
text/turtle
format
[
TURTLE
].
[[TURTLE]].
Commonly used namespace prefixes:
@prefix dcterms: <http://purl.org/dc/terms/>. @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix xsd:<http://www.w3.org/2001/XMLSchema#>.<http://www.w3.org/2001/XMLSchema#>.
As
well
as
The
status
of
the
sections
marked
of
Linked
Data
Platform
1.0
(this
document)
is
as
non-normative,
all
authoring
guidelines,
diagrams,
examples,
follows:
A
conforming
LDP
Server
is
an
application
program
that
processes
HTTP
requests
and
notes
in
this
specification
are
non-normative.
Everything
else
generates
HTTP
responses
that
conform
to
the
rules
defined
in
this
specification
is
normative.
sections
on
LDPRs
and
LDPCs
The
key
words
must
,
must
not
,
required
,
should
,
should
not
,
recommended
,
may
,
A
conforming
LDP
Client
is
an
application
program
that
generates
HTTP
requests
and
optional
in
this
specification
are
processes
HTTP
responses
that
conform
to
be
interpreted
as
described
the
rules
defined
in
[
RFC2119
sections
on
LDPRs
and
LDPCs
].
Linked
Data
Platform
Resources
(LDPRs)
(
LDPRs
)
are
HTTP
resources
that
conform
to
the
simple
patterns
and
conventions
in
this
section.
HTTP
requests
to
access,
modify,
create
or
delete
LDPRs
are
accepted
and
processed
by
LDPR
servers.
Most
LDPRs
are
domain-specific
resources
that
contain
data
for
an
entity
in
some
domain,
which
could
be
commercial,
governmental,
scientific,
religious,
or
other.
Some
of
the
rules
defined
in
this
document
provide
clarification
and
refinement
of
the
base
Linked
Data
rules
[
LINKED-DATA
],
[[LINKED-DATA]];
others
address
additional
needs.
The rules for Linked Data Platform Resources address basic questions such as:
Additional informative guidance is available on the working group's wiki that addresses deployment questions such as:
The following sections define the rules and guidelines for use of LDPRs.
rdf:type
to
represent
the
concept
of
type.
The
use
of
non-standard
type
predicates,
as
well
as
dcterms:type
,
is
rdf:type
set
explicitly.
ETag
header
values.
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.
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.
text/turtle
representation
of
the
requested
text/turtle
MUST
be
returned.
rdf:type
.
rdf:type
values
of
a
given
LDPR
There
are
This
specification
adds
no
additional
new
requirements
on
HTTP
POST
for
LDPRs.
This specification imposes the following new requirements on HTTP PUT for LDPRs only when the LDPR supports that method. This specification does not impose any new requirement to support that method, and [[!HTTP11]] makes it optional.
dcterms:modified
and
dcterms:creator
If-Match
header
and
HTTP
ETags
to
ensure
it
isn’t
modifying
a
resource
that
has
changed
since
the
client
last
retrieved
its
representation.
LDPR
servers
If-Match
header
and
HTTP
ETags
to
detect
collisions.
LDPR
servers
ETag
s
fail
to
match
if
there
are
no
other
errors
with
the
This
specification
imposes
the
types
of
clients
that
can
modify
resources.
For
some
server
applications,
excessive
constraints
following
new
requirements
on
modification
of
resources
may
be
required.
4.5
HTTP
DELETE
for
LDPRs
only
when
the
LDPR
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
[[!HTTP11]]
makes
it
optional.
Allow
”.
This specification imposes the following new requirements on HTTP PATCH for LDPRs only when the LDPR supports that method. This specification does not impose any new requirement to support that method, and [[!HTTP11]] makes it optional.
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:
This
document
defines
the
representation
and
behavior
of
containers
that
address
these
issues.
The
set
of
members
of
a
container
is
defined
by
a
set
of
triples
in
its
representation
(and
state)
called
the
membership
triples.
The
membership
triples
of
a
container
all
have
the
same
subject
and
predicate
–
the
objects
of
the
membership
triples
define
the
members
of
the
container.
The
subject
of
the
membership
triples
is
called
the
membership
subject
and
the
predicate
is
called
the
membership
predicate.
In
the
simplest
cases,
the
membership
subject
will
be
the
LDPC
resource
itself,
but
it
does
not
have
to
be.
The
membership
predicate
is
also
variable
and
will
often
be
a
predicate
from
the
server
application
vocabulary
or
the
rdfs:member
predicate.
This document includes a set of guidelines for using POST to create new resources and add them to the list of members of a container. This document also explains how to include information about each member in the container’s own representation and how to paginate the container representation if it gets too big.
The model for containers follow that of two distinct types: composition and aggregation. Due to composition constraints, the lifespan of the member resource must match that of its container and it a member resource can not be a member of more than one container. For both types of containers, members are only added by using POST, which both creates the resource and inserts a membership triple. A request to delete a composite container that has members, will result in all the members and the container itself will be deleted. A member resource is removed from a composite container by deleting the resource directly, which removes the membership triple from the container.
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):
# The following is the representation of # http://example.org/container1/ @prefix dcterms: <http://purl.org/dc/terms/>. @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix ldp: <http://www.w3.org/ns/ldp#>.<http://example.org/container1> a ldp:Container; dcterms:title "A very simple container"; rdfs:member <http://example.org/container1/member1>, <http://example.org/container1/member2>, <http://example.org/container1/member3>.<> a ldp:Container; dcterms:title "A very simple container"; rdfs:member <member1>, <member2>, <member3>.
This
example
is
very
straightforward
-
the
membership
predicate
is
rdfs:member
and
the
membership
subject
is
the
container
itself.
A
POST
to
this
container
will
create
a
new
resource
and
add
it
to
the
list
of
members
by
adding
a
new
membership
triple
to
the
container.
Sometimes
it
is
useful
to
use
a
subject
other
than
the
container
itself
as
the
membership
subject
and
to
use
a
predicate
other
than
rdfs:member
as
the
membership
predicate,
as
illustrated
below.
# The following is the representation of # http://example.org/netWorth/nw1/assetContainer/ @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix o: <http://example.org/ontology/>.<http://example.org/netWorth/nw1/assetContainer> a ldp:Container;<> a ldp:Container; ldp:membershipSubject <http://example.org/netWorth/nw1>;ldp:membershipPredicate o:asset.ldp:membershipPredicate o:asset. <http://example.org/netWorth/nw1>a o:NetWorth; o:asset <http://example.org/netWorth/nw1/assetContainer/a1>, <http://example.org/netWorth/nw1/assetContainer/a2>.a o:NetWorth; o:asset <a1>, <a2>.
The
essential
structure
of
the
container
is
the
same,
but
in
this
example,
the
membership
subject
is
not
the
container
itself
–
it
is
a
separate
net
worth
resource.
The
membership
predicate
is
o:asset
–
a
predicate
from
the
domain
model.
A
POST
to
this
container
will
create
a
new
asset
and
add
it
to
the
list
of
members
by
adding
a
new
membership
triple
to
the
container.
You
might
wonder
why
we
didn’t
just
make
http://example.org/netWorth/nw1
a
container
and
POST
the
new
asset
directly
there.
That
would
be
a
fine
design
if
http://example.org/netWorth/nw1
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
and
http://example.org/netWorth/nw1/assetContainer
http://example.org/netWorth/nw1/assetContainer/
container
resources
allows
both
assets
and
liabilities
to
be
created.
http://example.org/netWorth/nw1/liabilityContainer
http://example.org/netWorth/nw1/liabilityContainer/
In this example, clients cannot simply guess which resource is the membership subject and which predicate is the membership predicate, so the example includes this information in triples whose subject is the LDPC resource itself.
In many – perhaps most – applications involving containers, it is desirable for the client to be able to get information about each container member without having to do a GET on each one. LDPC allows servers to include this information directly in the representation of the container. The server decides the amount of data about each member that is provided. Some common strategies include providing a fixed number of standard properties, or providing the entire RDF representation of each member resource, or providing nothing. The server application domain and its use-cases will determine how much information is required.
Continuing on from the net worth example, there will be additional triples for the member resources (assets) in the representation:
# The following is the representation of # http://example.org/netWorth/nw1/assetContainer/ @prefix dcterms: <http://purl.org/dc/terms/>.@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.@prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix o: <http://example.org/ontology/>.<http://example.org/netWorth/nw1/assetContainer><> a ldp:Container;dcterms:title "The assets of JohnZSmith";dcterms:title "The assets of JohnZSmith"; ldp:membershipSubject <http://example.org/netWorth/nw1>; ldp:membershipPredicate o:asset. <http://example.org/netWorth/nw1>a o:NetWorth; o:asset <http://example.org/netWorth/nw1/assetContainer/a1>, <http://example.org/netWorth/nw1/assetContainer/a3>, <http://example.org/netWorth/nw1/assetContainer/a2>.a o:NetWorth; o:asset <a1>, <a3>, <a2>.<http://example.org/netWorth/nw1/assetContainer/a1> a o:Stock; o:value 10000. <http://example.org/netWorth/nw1/assetContainer/a2> a o:Bond; o:value 20000. <http://example.org/netWorth/nw1/assetContainer/a3> a o:RealEstateHolding; o:value<a1> a o:Stock; o:value 10000. <a2> a o:Bond; o:value 20000. <a3> a o:RealEstateHolding; o:value 300000.
The representation of a container that has many members will be large. There are several important cases where clients need to access only the non-member properties of the container. Since retrieving the whole container representation to get this information may be onerous for clients and cause unnecessary overhead on servers, it is desired to define a way to retrieve only the non-member property values. Defining for each LDPC a corresponding resource, called the “non-member resource”, whose state is a subset of the state of the container, does this.
The
example
listed
here
only
show
a
simple
case
where
only
a
few
simple
non-member
properties
are
retrieved.
In
real
world
situations
more
complex
cases
are
likely,
such
as
those
that
add
other
predicates
to
containers,
for
example
providing
validation
information
and
associating
SPARQL
endpoints.
[
SPARQL-QUERY
]
[[SPARQL-QUERY]]
Here
is
an
example
requesting
the
non-member
properties
of
a
container
identified
by
the
URL
and
adding
the
query
string
http://example.org/container1
http://example.org/container1/
?non-member-properties
:
Request:
GET /container1?non-member-properties HTTP/1.1 Host: example.orgAccept: text/turtle; charset=UTF-8Accept: text/turtle; charset=UTF-8
Response:
HTTP/1.1 200 OK Content-Type: text/turtle; charset=UTF-8 ETag: "_87e52ce291112" Content-Length: 325 @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>. @prefix dcterms: <http://purl.org/dc/terms/>. @prefix ldp: <http://www.w3.org/ns/ldp#>.<http://example.org/container1><http://example.org/container1/> a ldp:Container;dcterms:title "A Linked Data Platform Container of Acme Resources"; ldp:membershipPredicate rdfs:member;dcterms:title "A Linked Data Platform Container of Acme Resources"; ldp:membershipPredicate rdfs:member; dcterms:publisher <http://acme.com/>.
It sometimes happens that a container is too large to reasonably transmit its representation in a single HTTP response. This will be especially true if the container representation includes many triples from the representations of its members. A client may anticipate that a container will be too large - for example, a client tool that accesses defects may assume that an individual defect will usually be of sufficiently constrained size that it makes sense to request all of it at once, but that the container of all the defects ever created will typically be too big. Alternatively, a server may recognize that a container that has been requested is too big to return in a single message.
To
address
this
problem,
LDPCs
may
should
support
a
technique
called
Paging.
Paging
Paging
can
be
achieved
with
a
simple
RDF
pattern.
For
each
container
resource,
<containerURL>
,
we
define
a
new
resource
<containerURL>?firstPage
.
The
triples
in
the
representation
of
<containerURL>?firstPage
are
a
subset
of
the
triples
in
<containerURL>
-
same
subject,
predicate
and
object.
LDPC servers may respond to requests for a container by redirecting the client to the first page resource – using a 303 “See Other” redirect to the actual URL for the page resource.
Continuing
on
from
the
member
information
from
the
JohnZSmith
net
worth
example,
we’ll
split
the
response
across
two
pages.
The
The
client
requests
the
first
page
as
:
http://example.org/netWorth/nw1/assetContainer?firstPage
http://example.org/netWorth/nw1/assetContainer/?firstPage
# The following is the representation of # http://example.org/netWorth/nw1/assetContainer/?firstPage @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix dcterms: <http://purl.org/dc/terms/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix o: <http://example.org/ontology/>.<http://example.org/netWorth/nw1/assetContainer><http://example.org/netWorth/nw1/assetContainer/> a ldp:Container;dcterms:title "The assets of JohnZSmith"; ldp:membershipSubject <http://example.org/netWorth/nw1>; ldp:membershipPredicate o:asset.dcterms:title "The assets of JohnZSmith"; ldp:membershipSubject <http://example.org/netWorth/nw1>; ldp:membershipPredicate o:asset.<http://example.org/netWorth/nw1/assetContainer?firstPage><http://example.org/netWorth/nw1/assetContainer/?firstPage> a ldp:Page;ldp:pageOf <http://example.org/netWorth/nw1/assetContainer>; ldp:nextPage <http://example.org/netWorth/nw1/assetContainer?p=2>.ldp:pageOf <http://example.org/netWorth/nw1/assetContainer/>; ldp:nextPage <http://example.org/netWorth/nw1/assetContainer/?p=2>. <http://example.org/netWorth/nw1>a o:NetWorth;a o:NetWorth; o:asset <http://example.org/netWorth/nw1/assetContainer/a1>, <http://example.org/netWorth/nw1/assetContainer/a4>, <http://example.org/netWorth/nw1/assetContainer/a3>, <http://example.org/netWorth/nw1/assetContainer/a2>. <http://example.org/netWorth/nw1/assetContainer/a1>a o:Stock; o:value 100.00.a o:Stock; o:value 100.00. <http://example.org/netWorth/nw1/assetContainer/a2>a o:Cash; o:value 50.00.a o:Cash; o:value 50.00. # server initially supplied no data for a3 and a4 in this response
The following example is the result of retrieving the representation for the next page:
# The following is the representation of # http://example.org/netWorth/nw1/assetContainer/?p=2 @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix dcterms: <http://purl.org/dc/terms/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix o: <http://example.org/ontology/>.<http://example.org/netWorth/nw1/assetContainer><http://example.org/netWorth/nw1/assetContainer/> a ldp:Container;dcterms:title "The assets of JohnZSmith"; ldp:membershipSubject <http://example.org/netWorth/nw1>; ldp:membershipPredicate o:asset.dcterms:title "The assets of JohnZSmith"; ldp:membershipSubject <http://example.org/netWorth/nw1>; ldp:membershipPredicate o:asset.<http://example.org/netWorth/nw1/assetContainer?p=2> a ldp:Page; ldp:pageOf <http://example.org/netWorth/nw1/assetContainer>; ldp:nextPage rdf:nil.<http://example.org/netWorth/nw1/assetContainer/?p=2> a ldp:Page; ldp:pageOf <http://example.org/netWorth/nw1/assetContainer/>; ldp:nextPage rdf:nil. <http://example.org/netWorth/nw1>a o:NetWorth;a o:NetWorth; o:asset <http://example.org/netWorth/nw1/assetContainer/a5>. <http://example.org/netWorth/nw1/assetContainer/a5> a o:Stock;dcterms:title "Big Co.";dcterms:title "Big Co."; o:value 200.02.
In
this
example,
there
is
only
one
member
in
the
container
in
the
final
page.
To
To
indicate
this
is
the
last
page,
a
value
of
rdf:nil
is
used
for
the
ldp:nextPage
predicate
of
the
page
resource.
LDPC guarantees that any and all the triples about the members will be on the same page as the membership triple for the member.
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
o:value
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.
Order
only
becomes
important
for
LDPC
servers
when
containers
are
paginated.
If
the
server
does
not
respect
ordering
when
constructing
pages,
the
client
is
forced
to
retrieve
all
pages
before
sorting
the
members,
which
would
defeat
the
purpose
of
pagination.
In
cases
where
ordering
is
important,
a
LDPC
server
exposes
all
the
members
on
a
page
with
a
higher
sort
order
than
all
members
on
the
previous
page
and
lower
sort
order
than
all
the
members
on
the
next
page.
The
LDPC
specification
provides
a
predicate
-
ldp:containerSortPredicates
-
that
the
server
may
use
to
communicate
to
the
client
which
predicates
were
used
for
page
ordering.
Multiple
predicate
values
may
have
been
used
for
sorting,
so
the
value
of
this
predicate
is
an
ordered
list.
Here is an example container described previously, with representation for ordering of the assets:
# The following is the ordered representation of # http://example.org/netWorth/nw1/assetContainer/ @prefix dcterms: <http://purl.org/dc/terms/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix o: <http://example.org/ontology/>.<http://example.org/netWorth/nw1/assetContainer> a ldp:Container; dcterms:title "The assets of JohnZSmith"; ldp:membershipSubject <http://example.org/netWorth/nw1>; ldp:membershipPredicate o:asset.<> a ldp:Container; dcterms:title "The assets of JohnZSmith"; ldp:membershipSubject <http://example.org/netWorth/nw1>; ldp:membershipPredicate o:asset.<http://example.org/netWorth/nw1/assetContainer?firstPage><?firstPage> a ldp:Page;ldp:pageOf <http://example.org/netWorth/nw1/assetContainer>;ldp:pageOf <>; ldp:containerSortPredicates (o:value). <http://example.org/netWorth/nw1>a o:NetWorth; o:asset <http://example.org/netWorth/nw1/assetContainer/a1>, <http://example.org/netWorth/nw1/assetContainer/a3>, <http://example.org/netWorth/nw1/assetContainer/a2>.a o:NetWorth; o:asset <a1>, <a3>, <a2>.<http://example.org/netWorth/nw1/assetContainer/a1> a o:Stock; o:value 100.00. <http://example.org/netWorth/nw1/assetContainer/a2> a o:Cash; o:value 50.00. <http://example.org/netWorth/nw1/assetContainer/a3> a o:RealEstateHolding; o:value<a1> a o:Stock; o:value 100.00. <a2> a o:Cash; o:value 50.00. <a3> a o:RealEstateHolding; o:value 300000.
As
you
can
see
by
the
addition
of
the
ldp:containerSortPredicates
predicate,
the
o:value
predicate
is
used
to
define
the
ordering
of
the
results.
It
It
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.
The
Linked
Data
Platform
does
not
define
how
clients
discover
This
section
is
non-normative.
LDPCs
.
rdfs:member
predicate.
ldp:membershipSubject
predicate
ldp:membershipPredicate
predicate
rdfs:member
.
This
triple's
object
provides
clients
with
the
LDPC's
membership
predicate
URI.
rdf:type
of
ldp:Container
,
but
it
rdf:type
s.
rdf:Bag
,
rdf:Seq
rdf:List
.
non-member-properties
<containerURL>,
the
URL
to
request
the
non-membership
properties
would
be
<containerURL>?non-member-properties
.
<containerURL>?non-member-properties
”,
<containerURL>?non-member-properties
”,
MUST
return
a
HTTP
Redirection
3xx
status
code
such
as
301
(Moved
Permanently)
or
302
(Found).
<containerURL>
<containerURL>?firstPage
”,
<containerURL>?firstPage
”,
MUST
return
a
HTTP
Redirection
3xx
status
code
such
as
301
(Moved
Permanently)
or
302
(Found).
firstPage
”
on
the
query
component
of
the
LDPC
URL.
For
example,
if
there
is
a
LDPC
URL
<containerURL>
,
the
URL
to
request
the
first
page
would
be
<containerURL>?firstPage
.
The
representation
for
any
page,
including
the
first,
will
include
the
URL
for
the
next
firstPage
”
query
component
of
a
request
URL).
This
is
also
known
as
server-initiated
paging.
See
section
5.1.3
Paging
for
additional
details.
rdf:type
and
object
is
ldp:Page;
it
also
ldp:pageOf,
and
object
is
the
URL
of
the
LDPC.
ldp:nextPage
and
object
being
the
URL
for
the
subsequent
page.
ldp:nextPage
and
object
being
rdf:nil
.
ldp:containerSortPredicates
predicate
whose
subject
is
that
of
the
page
and
object
is
a
list
of
LDPC
ordinal
predicates.
ldp:containerSortPredicates
’,
,
the
predicate
used
to
indicate
ordering,
The
Linked
Data
Platform
This
specification
imposes
the
following
new
requirements
on
HTTP
POST
for
LDPCs
only
when
an
LDPC
supports
that
method.
This
specification
does
not
define
how
clients
discover
LDPCs.
impose
any
new
requirement
to
support
that
method,
and
[[!HTTP11]]
makes
it
optional.
Location
header
set
to
the
new
resource’s
URL.
Content-Type
with
value
of
text/turtle
Content-Type
request
This specification imposes the following new requirements on HTTP PUT for LDPCs only when an LDPC supports that method. This specification does not impose any new requirement to support that method, and [[!HTTP11]] makes it optional.
<containerURL>?non-member-properties
,
which
ldp:membershipSubject
and
ldp:membershipPredicate
.
This specification imposes the following new requirements on HTTP DELETE for LDPRs only when a LDPC supports that method. This specification does not impose any new requirement to support that method, and [[!HTTP11]] makes it optional.
rdf:type
predicate
with
an
object
of
ldp:AggregateContainer
,
the
server
MAY
also
delete
the
resources
that
are
referenced
as
its
contents.
The
LDPC
membership
triple
MUST
also
be
updated
as
defined
by
5.6.1
above.
rdf:type
predicate
with
an
object
of
ldp:CompositeContainer
,
the
server
There are no additional requirements on HTTP HEAD.
This specification imposes the following new requirements on HTTP PATCH for LDPCs only when a LDPC supports that method. This specification does not impose any new requirement to support that method, and [[!HTTP11]] makes it optional.
The following people have been instrumental in providing thoughts, feedback, reviews, content, criticism and input in the creation of this specification:
Arnaud
le
Hors,
Erik
Wilde,
Tim
Berners-Lee,
Steve
Battle,
Olivier
Berger,
Alexandre
Bertails,
Richard
Cyganiak,
Raúl
García
Castro,
Sandro
Hawke,
Kingsley
Idehen,
Yves
Lafon,
Antonis
Loizou,
Ashok
Malhota,
Roger
Menday,
Nandana
Mihindukulasooriya,
Kevin
Page,
Eric
Prud'hommeaux,
Andy
Seaborne,
Henry
Story,
Ted
Thibodeau,
Bart
van
Leeuwen,
Ruben
Verborgh,
David
Wood,
Martin
P.
Nally
John
Arwe
Arnaud
le
Hors
B.
This section is non-normative.First Public Working Draft
Submission
ldp
namespace
(SS)
Other than LDP open actions and issues , included here are transient tasks and notes editors use. They have not meaning in final product of a published working draft and will be removed prior to publishing.