This
document
specification
describes
the
use
of
HTTP
for
accessing,
updating,
creating
and
deleting
resources
from
servers
that
expose
their
resources
as
Linked
Data.
It
It
provides
clarifications
and
extensions
of
the
four
rules
of
Linked
Data
[
LINKED-DATA
]:
[[LINKED-DATA]]:
This
specification
discusses
standard
HTTP
and
RDF
techniques
used
when
constructing
clients
and
servers
that
create,
read,
and
write
Linked
Data
Platform
Resources
.
A
companion
document
discusses
best
practices
that
you
should
use,
and
anti-patterns
you
should
avoid,
when
constructing
these
clients
and
servers
that
read
and
write
Linked
Data
servers.
This specification provides a widely re-usable pattern to deal with large resources. Depending on the server’s capabilities, a GET request on a resource can be redirected to a subset of the resource (one page) , that provides access to subsequent pages (see ).
A
This
specification
defines
a
special
type
of
Linked
Data
Platform
Resource
is
:
a
Container
.
Containers
are
very
useful
in
building
application
models
involving
collections
of
resources,
often
homogeneous
resources.
ones.
For
example,
universities
offer
a
collection
of
classes
and
have
a
collection
of
faculty
members,
each
faculty
member
teaches
a
collection
of
courses,
etc.
and
so
on.
This
specification
discusses
how
to
work
with
containers.
Resources
can
be
added
to
containers
in
several
ways.
As
a
special
case,
members
can
both
be
created
and
added
to
a
container
by
overloading
the
using
standard
HTTP
operations
like
POST
operation
(see
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
).
The
intention
of
this
document
specification
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.
For
context
and
background,
it
could
be
useful
to
read
Linked
Data
Platform
Use
Case
and
Requirements
[[LDP-UCR]]
and
2.
.
Terminology
is
based
on
W3C
's
W3C's
Architecture
of
the
World
Wide
Web
[
WEBARCH
]
[[WEBARCH]]
and
Hyper-text
Transfer
Protocol
[
HTTP11
].
[[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]].
].
membership-constant-URI | membership-predicate | member-derived-URI |
member-derived-URI | membership-predicate | membership-constant-URI |
ldp:member
and
dcterms:isPartOf
are
representative
examples.
Each
container
all
have
exposes
properties
(see
)
that
allow
clients
to
determine
which
pattern
it
uses,
what
the
same
subject
actual
membership-predicate
and
predicate,
membership-constant-URI
values
are,
and
(for
containers
that
allow
the
objects
creation
of
new
members)
what
value
is
used
for
the
membership
triples
identify
member-derived-URI
based
on
the
container's
members.
client's
input
to
the
creation
process.
Note:
the
choice
of
R
0
,
terms
was
designed
to
help
authors
and
readers
clearly
differentiate
between
the
entire
resource
being
paged
state
of
resources
accessed
through
,
and
the
other
individual
page
resources
request
URI(s)
,
in
cases
where
both
are
mentioned
in
close
proximity.
Link
<
P
1
...
>;
rel='first'
header
[[!RFC5988]].
Link
<
P
n
i
,
and
assertions
from
the
server
identifying
>;
rel='next'
header
[[!RFC5988]]
where
the
Link
<
P
n
identify
the
inlined
resource(s).
See
section
4.11
for
details.
>;
rel='last'
header
[[!RFC5988]].
Link
<
P
i
>;
rel='prev'
header
[[!RFC5988]]
where
the
Sample
resource
representations
are
provided
in
text/turtle
format
[
TURTLE
].
[[TURTLE]].
Commonly used namespace prefixes:
@prefix dcterms: <http://purl.org/dc/terms/>. @prefix foaf: <http://xmlns.com/foaf/0.1/>. @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix xsd: <http://www.w3.org/2001/XMLSchema#>.
The status of the sections of Linked Data Platform 1.0 (this document) is as follows:
A
conforming
LDP
server
client
is
an
application
program
that
processes
HTTP
requests
and
generates
a
conforming
HTTP
responses
client
[[!HTTP11]]
that
conform
to
follows
the
rules
defined
by
LDP
in
section
4.
Linked
Data
Platform
Resources
and
section
5.
Linked
Data
Platform
Containers
.
A
conforming
LDP
client
server
is
an
application
program
that
generates
HTTP
requests
and
processes
a
conforming
HTTP
responses
server
[[!HTTP11]]
that
conform
to
follows
the
rules
defined
by
LDP
in
section
4.
Linked
Data
Platform
Resources
when
it
is
serving
LDPRs,
and
section
5.
also
when
it
is
serving
LDPCs.
LDP
does
not
constrain
its
behavior
when
serving
other
HTTP
resources.
All of the following are conformance rules for LDP Clients .
rdf:type
.
rdf:type
values
of
a
given
LDP-RR
can
change
over
time.
GET
that
it
doesn’t
change
whether
it
understands
the
predicates
or
not,
when
its
intent
is
to
perform
an
update
using
HTTP
PUT
.
The
use
of
HTTP
PATCH
instead
of
HTTP
PUT
for
update
avoids
this
burden
for
clients
[[RFC5789]].
Linked
Data
Platform
Resources
(
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.
LDP
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
non-normative
guidance
is
available
on
in
the
working
group's
wiki
LDP
Best
Practices
and
Guidelines
editor's
draft
that
addresses
deployment
questions
such
as:
The
following
sections
define
the
conformance
rules
and
guidelines
for
use
of
LDPRs
.
LDP
servers
when
serving
LDPRs.
This
document
also
explains
how
to
include
information
about
each
member
in
the
resource’s
own
representation
and
how
to
paginate
the
resource
a
server
paginates
an
LDP-RR's
representation
if
it
gets
too
big.
Companion
non-normative
documents
describe
additional
guidelines
for
use
when
interacting
with
LDPRs.
An LDP server manages two kinds of LDPRs , 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.
The LDP-BRs and LDP-RRs are simply sub-types of LDPRs, as illustrated in .
Request-URI
of
the
rdf:type
set
explicitly.
Link
header
with
a
target
URI
of
http://www.w3.org/ns/ldp/Resource
http://www.w3.org/ns/ldp#Resource
,
and
a
link
relation
type
of
type
(that
is,
rel="type"
rel='type'
)
in
all
responses
to
requests
made
to
the
Request-URI
.
Note: The HTTP
Link
header is the method by which servers assert their support for the LDP specification on a specific resource in a way that clients canintrospectinspect dynamically at run-time.Conservative clients should note thatThis is not equivalent to the presence of a (subject-URI,rdf:type
,ldp:Resource
) 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 has Etags , has an RDF representation , and so on, which is not true of all Web resources served as RDF media types.Note: A LDP server can host a mixture of LDPRs and other resources , and therefore there is no implication that LDP support advertised on one HTTP
Request-URI
means that other resources on the same server are alsoLDPRs .LDPRs. Each HTTPRequest-URI
needs to be individuallyintrospected by a conservative client,inspected, in the absence of outside information.4.2.11 LDPR
Request-URI
when
the
resource
already
exists,
and
to
the
URI
of
the
created
resource
when
the
request
results
in
the
creation
of
a
new
resource.
rel='describedby'
[[!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
Link
header
on
its
4xx
responses
to
such
requests.
The
same
Link
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.
GET
Method
for
text/turtle
representation
of
the
requested
This
specification
adds
no
new
requirements
on
HTTP
POST
for
LDPRs
even
when
the
LDPR
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
[
HTTP11
]
[[!HTTP11]]
makes
it
optional.
Creation
of
LDPRs
Clients
can
be
done
create
LDPRs
via
POST
(
section
5.4
)
or
PUT
(
section
5.5
)
to
a
LDPC
,
LDPC,
see
those
sections
for
more
details.
Any
server-imposed
constraints
on
LDPR
creation
or
update
must
be
advertised
to
clients.
This
Per
[HTTP11],
this
HTTP
method
is
optional
and
this
specification
does
not
require
LDP
servers
to
support
it.
When
a
LDP
server
chooses
to
support
this
method,
this
specification
imposes
the
following
new
requirements
on
HTTP
PUT
for
LDPRs
only
when
the
LDPRs.
Any
server-imposed
constraints
on
LDPR
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
[
HTTP11
creation
or
update
must
be
advertised
]
makes
it
optional.
to
clients.
PUT
is
dcterms:modified
and
dcterms:creator
if
they
are
not
under
client
control.
Any
PATCH
,
not
HTTP
PUT
.
PUT
request
is
received
that
attempts
to
change
triples
the
server
does
not
allow
clients
to
modify,
LDP
servers
MUST
respond
with
a
4xx
range
status
code
(typically
409
Conflict).
LDP
servers
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.
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.
If-Match
header
and
HTTP
ETags
to
ensure
it
isn’t
modifying
a
resource
that
has
changed
since
the
client
last
retrieved
its
representation.
If-Match
header
and
HTTP
ETags
to
detect
collisions.
ETag
s
fail
to
match
when
there
are
no
other
errors
with
the
request
PUT
request
is
PUT
.
This
specification
imposes
the
following
new
requirements
on
Per
[HTTP11],
this
HTTP
DELETE
for
LDPRs
only
when
the
LDPR
supports
that
method.
This
method
is
optional
and
this
specification
does
not
impose
any
new
requirement
require
LDP
servers
to
support
that
it.
When
a
LDP
server
chooses
to
support
this
method,
and
[
HTTP11
]
makes
it
optional.
this
specification
imposes
the
following
new
requirements
for
LDPRs.
Additional
requirements
on
HTTP
DELETE
of
LDPRs
within
containers
can
be
found
in
section
5.6
.
Note
that
certain
LDP
mechanisms,
such
as
paging,
paging
,
rely
on
HTTP
headers,
and
HTTP
generally
requires
that
HEAD
responses
include
the
same
headers
as
GET
responses.
Thus,
implementers
should
also
carefully
read
section
4.3
sections
and
section
4.9
.
HEAD
method.
This
specification
imposes
the
following
new
requirements
on
Per
[HTTP11],
this
HTTP
PATCH
for
LDPRs
only
when
the
LDPR
supports
that
method.
This
method
is
optional
and
this
specification
does
not
impose
any
new
requirement
require
LDP
servers
to
support
that
it.
When
a
LDP
server
chooses
to
support
this
method,
and
[
HTTP11
]
makes
it
optional.
this
specification
imposes
the
following
new
requirements
for
LDPRs.
Any
server-imposed
constraints
on
LDPR
servers
MAY
implement
HTTP
PATCH
to
allow
modifications,
especially
partial
replacement,
of
their
resources
[
RFC5789
creation
or
update
must
be
advertised
to
clients.
PATCH
.
POST
(to
an
PUT
should
be
used
as
the
standard
way
to
create
new
PATCH
MUST
include
an
Accept-Patch
HTTP
response
header
OPTIONS
requests,
listing
patch
document
media
type(s)
supported
by
the
server.
This
specification
imposes
the
following
new
requirements
on
HTTP
OPTIONS
for
LDPRs
beyond
those
in
[
HTTP11
].
[[!HTTP11]].
Other
sections
of
this
specification,
for
example
PATCH
,
Accept-Post
and
Paging
,
add
other
requirements
on
OPTIONS
responses.
OPTIONS
method.
OPTIONS
request
on
the
Allow
.
It
sometimes
happens
that
a
resource
is
too
large
to
reasonably
transmit
its
representation
in
a
single
HTTP
response.
This
will
be
especially
true
if
the
resource
representation
includes
many
triples
both
from
its
own
representation
and
from
the
representations
of
any
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.
To
address
this
problem,
LDPRs
servers
should
support
a
technique
called
Paging.
Paging
can
be
achieved
with
When
a
client
retrieves
such
a
simple
RDF
pattern.
For
each
resource,
<resourceURL>
,
we
define
the
server
redirects
the
client
to
a
new
'first
page'
resource.
In
this
example,
"first
page"
resource,
and
includes
in
its
URL
will
be
<resourceURL>?firstPage
,
but
servers
are
free
response
a
link
to
construct
the
URL
as
they
see
fit.
next
part
of
the
resource's
state,
all
at
a
URLs
of
the
server's
choosing.
The
triples
in
the
representation
of
the
each
page
of
an
LDPR
are
typically
a
subset
of
the
triples
in
from
the
paged
resource
-
same
subject,
predicate
and
object.
.
LDPR
LDP
servers
may
respond
to
requests
for
a
resource
by
redirecting
the
client
to
the
first
page
of
the
resource
–
using
and,
with
that,
returning
a
303
“See
Other”
redirect
to
Link
<next-page-URL>;type='next'
header
containing
the
actual
URL
for
the
page
resource.
Alternatively,
clients
may
introspect
the
resource
next
page.
Clients
inspect
each
response
for
a
paged
representation
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]],
and
use
it
preferentially
when
available.
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.
Looking
at
an
example
resource
representing
Example
Co.'s
customer
relationship
data,
identified
by
the
URI
http://example.org/customer-relations
,
we’ll
split
the
response
across
two
pages.
To
find
the
URL
of
the
first
page,
the
The
client
makes
a
retrieves
,
and
OPTIONS
request
to
the
resource's
URL,
http://example.org/customer-relations
in
the
response
looks
for
a
HTTP
server
responds
with
status
code
Link
333
(Returning
Related)
header
with
,
a
rel="first"
Location:
http://example.org/customer-relations?page1
;
the
target
URI
in
the
header
is
the
URL
of
the
first
page
resource.
The
client
then
requests
HTTP
response
header,
and
the
first
page
as
http://example.org/customer-relations?firstPage
:
following
representation:
# 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: <http://example.org/customer-relations?p=2>; rel='next' # This Link header is how clients discover the URI of the next page in sequence, # and that the resource supports paging. @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix dcterms: <http://purl.org/dc/terms/>. @prefix foaf: <http://xmlns.com/foaf/0.1/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix o: <http://example.org/ontology/>. @base <http://example.org/customer-relations>.<http://example.org/customer-relations><> a o:CustomerRelations;dcterms:title "The customer information for Example Co."; o:client <client#JohnZSmith>, <client#BettyASmith>, <client#JoanRSmith>. <http://example.org/customer-relations?firstPage> a ldp:Page; ldp:pageOf <http://example.org/customer-relations>; ldp:nextPage <http://example.org/customer-relations?p=2>.dcterms:title "The customer information for Example Co."; o:client <#JohnZSmith>, <#BettyASmith>, <#JoanRSmith>.<client#JohnZSmith> a foaf:Person;<#JohnZSmith> a foaf:Person; o:status o:ActiveCustomer;foaf:name "John Z. Smith". <client#BettyASmith> a foaf:Person;foaf:name "John Z. Smith". <#BettyASmith> a foaf:Person; o:status o:PreviousCustomer;foaf:name "Betty A. Smith". <client#BettyASmith> a foaf:Person;foaf:name "Betty A. Smith". <#JoanRSmith> a foaf:Person; o:status o:PotentialCustomer;foaf:name "Joan R. Smith".foaf:name "Joan R. Smith".
Because
the
server
includes
a
Link:
<http://example.org/customer-relations?p=2>;
rel='next'
response
header,
and
the
status
code
is
3xx
(
333
(Returning
Related)
in
this
case),
the
client
knows
that
more
data
exists
and
where
to
find
it.
The
server
determines
the
size
of
the
pages
using
application
specific
methods
not
defined
within
this
specificiation.
Note
also,
the
actual
name
for
the
query
parameter
(such
as
?p=2)
The
next
page
link's
target
URI
is
also
defined
by
the
server
and
not
this
specification.
The
following
example
is
the
result
of
retrieving
the
representation
for
the
next
page:
page;
the
server
responds
with
status
code
200
(OK)
and
the
following
representation:
# The following is the representation of # http://example.org/customer-relations?p=2 # # There is no "next" Link in the server's response, so this is the final page. # @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>. @prefix dcterms: <http://purl.org/dc/terms/>. @prefix foaf: <http://xmlns.com/foaf/0.1/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix o: <http://example.org/ontology/>. @base <http://example.org/customer-relations>.<http://example.org/customer-relations> o:client <client#GlenWSmith>, <client#AlfredESmith>.<> o:client <#GlenWSmith>, <#AlfredESmith>.<http://example.org/customer-relations?p=2> a ldp:Page; ldp:pageOf <http://example.org/customer-relations>; ldp:nextPage rdf:nil. <client#GlenWSmith> a foaf:Person;<#GlenWSmith> a foaf:Person; o:status o:ActiveCustomer, o:GoldCustomer;foaf:name "Glen W. Smith".foaf:name "Glen W. Smith".<client#AlfredESmith> a foaf:Person;<#AlfredESmith> a foaf:Person; o:status o:ActiveCustomer, o:BronzeCustomer;foaf:name "Alfred E. Smith".foaf:name "Alfred E. Smith".
In
this
example,
there
are
only
two
customers
provided
in
the
final
page.
To
To
indicate
this
is
the
last
page,
a
value
of
rdf:nil
is
used
for
the
server
omits
the
ldp:nextPage
Link:
rel='next'
predicate
header
in
its
response.
As
mentioned
above,
retrieving
all
the
pages
offered
by
a
server
gives
no
guarantee
to
a
client
that
it
knows
the
entire
state
of
the
server.
For
example,
after
the
server
constructs
the
the
first
page
resource.
representation,
another
actor
could
delete
client#BettyASmith
from
the
server.
In
addition
to
the
requirements
set
forth
in
section
4.3
on
HTTP
GET
,
LDPR
LDP
servers
that
support
paging
must
also
follow
the
requirements
in
this
section
for
all
paged
resources
and
their
associated
single-page
resources
.
Non-normative note: As a result, clients retrieving any single-page resource several times can observe its place in the sequence change as the state of the paged resource changes. For example, a nominally last page's server might provide a next page link 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 pages.In
Request-URI
.
GET
requests
with
Request-URI
,
LDPR
.
first
GET
Request-URI
.
This
is
the
mechanism
by
which
clients
can
discover
the
URL
of
the
Link:
<?theFirstPage>;rel="first"
.
The
representation
for
any
page,
including
the
first,
will
include
the
URL
for
GET
requests
with
the
Request-URI
.
This
is
303
See
Other
GET
ldp:nextPage
and
object
being
Request-URI
.
This
is
one
mechanism
by
which
clients
can
discover
the
URL
rdf:type
GET
ldp:pageOf
,
and
object
Request-URI
.
This
is
one
mechanism
by
which
clients
can
discover
the
OPTIONS
Link
Link
http://www.w3.org/ns/ldp#Page
,
and
whose
link
relation
type
is
first
type
GET
requests
with
any
single-page
resource
as
the
Request-URI
.
This
is
one
mechanism
by
which
clients
know
that
the
resource
is
one
of
a
Feature At Risk
The
LDP
Working
Group
proposes
incorporation
of
the
features
described
in
this
section.
the
next
compliance
clause.
This
section
is
non-normative.
Servers
A
TAG
discussion
has
started,
whose
resources
are
relatively
granular
may
wish
to
optimistically
provide
more
information
in
a
response
than
what
the
client
actually
requested,
in
order
goal
is
to
reduce
the
average
number
of
client
application
HTTP
flows.
LDP
provides
some
basic
building
blocks
to
enable
this,
that
implementations
can
re-use
to
build
complete
solutions,
and
they
may
serve
as
complete
solutions
in
applications
with
sufficient
controls
on
resource
content.
These
building
blocks
are
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
need
for
two
request-response
round
trips
down
to
influence
which
(if
any)
resources
are
inlined
in
any
given
response.
Servers
can
return
extra
triples
on
any
response,
but
fail
one
when
retrieving
what
turns
out
to
meet
be
the
definition
first
page
of
resource
inlining
,
a
paged
resource,
by
either
returning
defining
a
subset
of
new
HTTP
response
code
in
the
other
resource(s)
triples
2xx
or
by
failing
to
assert
3xx
class
that
all
triples
were
included
(even
through
they
were).
Clients
might
still
find
the
extra
information
useful,
but
the
only
way
for
clients
to
be
sure
they
had
all
available
information
would
be
to
make
allow
a
HTTP
server
to
respond
to
GET
request-uri
request
against
all
the
other
resource(s).
In
some
applications,
knowing
that
these
requests
are
unnecessary
saves
significant
latency
and
server/network
load.
4.11.2
Use
with
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
the
general
case
—
so
if
you
care
about
any
representation
of
the
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
first
page
(whose
URI
is
impossible
for
first-page-uri
,
not
request-uri
)
of
a
client
to
reliably
know
which
triples
came
from
which
HTTP
resource(s).
A
general
solution
allowing
quotation
is
RDF
Datasets;
that
is
expected
to
be
standardized
independently,
and
can
be
used
in
these
cases
once
it
is
available.
multi-page
response.
The
response
may
contain
contradictions
that
are
trivially
obvious
(or
subtle),
and
those
may
or
may
not
be
a
problem
at
the
application
level.
For
a
trivial
example,
two
triples
may
have
identical
subjects
and
predicates
but
different
objects:
"75F
is
too
hot";
"75F
is
too
cold".
Again,
quotation
via
RDF
Datasets
(or
any
equivalent
mechanism)
is
believed
to
provide
a
long
term
solution
once
standardized.
4.11.3
HTTP
GET
In
addition
to
the
requirements
set
forth
in
other
sections,
LDPR
servers
that
support
resource
inlining
must
also
follow
the
requirements
in
purposes
of
drafting
this
section.
4.11.3.1
LDPR
servers
section,
we
assume
that
support
resource
inlining
MUST
include
a
ldp:Page
resource
in
the
representation
describing
the
set
of
inlined
resources,
whether
or
not
the
representation
contains
subsequent
pages.
The
ldp:Page
resource
conceptually
contains
metadata
about
the
representation;
it
new
code's
value
is
usually
not
part
of
the
HTTP
resource's
state,
333
(Returning
Related)
,
an
LDP
extrapolation
from
TAG
discussions,
and
its
presence
does
not
indicate
that
definition
is
given
by
Henry
Thompson's
strawman
,
with
the
LDPR
server
supports
paging
in
general.
LDPR
substitution
of
333
for
2xx.
Note:
nothing
prevents
servers
that
include
the
or
clients
from
using
ldp:Page
303
See
Other
resource
responses
to
requests
for
inlining
paged
resources
.
The
only
significant
difference
between
303
and
also
support
paging
MUST
use
333
responses
is
the
same
ldp:Page
resource
extra
round
trip
required
for
the
triples
required
by
both,
in
order
to
minimize
client
code
complexity.
The
ldp:Page
resource's
triples
are
the
LDP-defined
means
by
which
the
servers
communicate
to
LDP
clients
retrieve
the
set
representation
of
HTTP
resources
whose
state
the
first
page
when
using
303.
Once
LDP
is
included
in
a
representation,
allowing
clients
Candidate
Recommendation,
the
LDP
WG
will
make
an
assessment
based
on
the
status
at
IETF,
working
with
the
W3C
Director,
to
avoid
HTTP
GET
requests
for
them.
4.11.3.2
LDPR
servers
that
support
resource
inlining
MUST
include
either
use
the
ldp:Page
resource
described
newly
defined
response
code
as
documented
in
this
section
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
or
to
revert
to
a
classic
Request-URI
303
of
an
inlined
resource
[
response
pattern.
333
(Returning
Related)
to
successful
GET
requests
Request-URI
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
,
although
any
In
addition
to
subsequent
requests.
4.11.3.4
LDPR
clients
MUST
NOT
assume
that
LDPR
representations
lacking
a
ldp:Page
resource
or
lacking
the
triple
described
requirements
set
forth
in
section
4.11.3.2
contain
all
the
triples
for
any
resource(s)
listed
in
the
representation
whose
HTTP
Request-URI
differs
from
the
on
HTTP
,
LDP
servers
that
support
paging
must
also
follow
the
Request-URI
used
by
OPTIONS
client.
The
representation
might
requirements
in
fact
contain
this
section
for
all
such
triples,
or
some
subset
of
them,
and
paged
resources
.
Note
that
might
or
might
not
be
completely
adequate
for
the
client's
intended
usage,
but
an
LDP
client
has
no
way
to
discern
only
requires
enough
from
such
OPTIONS
for
discovery
of
paging
support
on
a
representation
resource,
which
interpretation
is
accurate.
considerably
less
than
is
required
for
HTTP
GET
.
This
lowers
server
implementation
effort.
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.
triples
that
follow
a
consistent
pattern
(see
the
linked-to
definition
for
the
possible
patterns).
The
membership
triples
of
a
container
all
have
the
same
subject
predicate,
called
the
membership
predicate,
and
predicate
either
the
subject
or
the
object
is
also
a
consistent
value
–
the
objects
remaining
position
of
the
membership
triples
(the
one
that
varies)
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
consistent
value
will
be
the
LDPC
resource
itself,
resource's
URI,
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
predicate.
rdfs:member
ldp:member
This
document
includes
a
set
of
guidelines
for
using
POST
to
create
creating
new
resources
and
add
adding
them
to
the
list
of
members
of
a
container.
It
goes
on
to
explain
how
to
learn
about
a
set
of
related
resources,
regardless
of
how
they
may
have
been
were
created
using
POST
or
through
other
means.
added
to
the
container's
membership.
It
also
defines
behavior
when
POST
created
resources
are
deleted,
to
clean
up
created
using
a
container
membership,
and
are
later
deleted;
deleting
containers
removes
membership
information
and
possibly
perform
performs
some
cleanup
tasks
on
unreferenced
member
resources.
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/c1/ # @base <http://example.org/c1/> @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#>. <>a ldp:Container; ldp:membershipSubject <> ldp:membershipPredicate rdfs:member; ldp:membershipObject ldp:MemberSubject; dcterms:title "A very simple container"; rdfs:member <member1>, <member2>, <member3>.a ldp:Container, ldp:BasicContainer; dcterms:title "A very simple container"; ldp:contains <r1>, <r2>, <r3>.
This
example
is
very
straightforward
-
the
membership
and
containment
predicate
is
are
both
and
the
other
consistent
membership
rdfs:member
ldp:contains
subject
value
is
the
container
itself.
container's
URI,
occurring
in
the
subject
position
of
the
triples.
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.
This
type
of
container
is
also
refered
to
as
LDP
Basic
Container
.
Sometimes
it
is
useful
to
use
a
subject
other
than
the
container
itself
as
the
consistent
membership
subject
and
value,
and/or
to
use
a
predicate
other
than
rdfs:member
from
an
application's
domain
model
as
the
membership
predicate.
Let's
start
with
a
domain
resource
for
a
person's
net
worth,
as
illustrated
below:
# The following is a partial representation of # http://example.org/netWorth/nw1 # @base <http://example.org/netWorth/nw1/> @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix o: <http://example.org/ontology/>. <> a o:NetWorth; o:netWorthOf <http://example.org/users/JohnZSmith>; o:asset <assetContainer/a1>, <assetContainer/a2>; o:liability <liabilityContainer/l1>, <liabilityContainer/l2>,<liabilityContainer/l3>.<liabilityContainer/l3>.
From
this
example,
there
is
a
rdf:type
of
o:NetWorth
indicating
the
resource
represents
an
instance
of
a
person's
net
worth
and
o:netWorthOf
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
in
the
3
examples
below:
# The following is an elaborated representation of LDPR # http://example.org/netWorth/nw1 # @base <http://example.org/netWorth/nw1/>. @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix dcterms: <http://purl.org/dc/terms/>. @prefix o: <http://example.org/ontology/>. <> a o:NetWorth; o:netWorthOf <http://example.org/users/JohnZSmith>; o:asset <assetContainer/a1>, <assetContainer/a2>; o:liability <liabilityContainer/l1>, <liabilityContainer/l2>, <liabilityContainer/l3>.
# The following is an elaborated representation of LDPC # http://example.org/netWorth/nw1/assetContainer/<assetContainer/> a ldp:Container;# @base <http://example.org/netWorth/nw1/assetContainer/> @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix dcterms: <http://purl.org/dc/terms/>. @prefix o: <http://example.org/ontology/>. <> a ldp:Container, ldp:DirectContainer; dcterms:title "The assets of JohnZSmith";ldp:membershipSubject <>; ldp:membershipPredicate o:asset; ldp:membershipObject ldp:MemberSubject.ldp:containerResource <>; ldp:containsRelation o:asset; ldp:contains <a1>, <a2>.
# The following is an elaborated representation of LDPC # http://example.org/netWorth/nw1/liabilityContainer/<liabilityContainer/> a ldp:Container;# @base <http://example.org/netWorth/nw1/liabilityContainer/> @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix dcterms: <http://purl.org/dc/terms/>. @prefix o: <http://example.org/ontology/>. <> a ldp:Container, ldp:DirectContainer; dcterms:title "The liabilities of JohnZSmith";ldp:membershipSubject <>; ldp:membershipPredicate o:liability; ldp:membershipObject ldp:MemberSubject.ldp:containerResource <>; ldp:containsRelation o:liability; ldp:contains <l1>, <l2>, <l3>.
The
essential
structure
of
the
container
is
the
same,
but
in
this
example,
the
consistent
membership
value
(still
in
the
subject
position)
is
not
the
container
itself
–
it
is
a
separate
net
worth
resource.
The
membership
predicates
are
o:asset
and
o:liability
–
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
resource
and
containment
triple
to
the
container.
You
might
wonder
why
http://example.org/netWorth/nw1
isn't
made
a
container
itself
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
http://example.org/netWorth/nw1/assetContainer/
and
http://example.org/netWorth/nw1/liabilityContainer/
container
resources
allows
both
assets
and
liabilities
to
be
created.
In
this
example,
clients
cannot
simply
guess
which
resource
This
type
of
container
is
refered
to
as
an
LDP
Direct
Container
.
An
LDP
Basic
Container
is
a
constrained
form
of
LDP
Direct
Container
where
the
membership
subject
and
which
predicate
is
ldp:contains
and
the
container
resource
is
the
container
itself.
As
seen
in
the
assetContainer/
example
,
clients
cannot
correctly
guess
at
the
membership
predicate,
triples,
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
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
for
the
client
net
worth
resource
and
then
two
others
for
asset
and
liability
containers.
This
allows
for
the
membership
triples
to
be
able
to
get
information
about
each
container
member
without
having
represented
with
the
named
graph
for
the
net
worth
resource,
while
the
containment
triples
would
be
represented
within
the
liability
and
asset
containers
[[rdf11-concepts]].
Generally,
the
membership
triples
belong
to
do
the
representation
of
a
GET
on
each
one.
LDPC
allows
servers
LDP-RR
and
the
containment
triples
belong
to
include
this
information
directly
in
the
representation
of
the
container.
The
server
decides
LDPC.
Additionally,
we
could
extend
our
net
worth
example
to
include
a
container
for
advisors
(people)
that
have
managed
the
amount
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.
# 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 <http://example.org/netWorth/nw1/> @prefix ldp: <http://www.w3.org/ns/ldp#>. @prefix dcterms: <http://purl.org/dc/terms/>. @prefix foaf: <http://xmlns.com/foaf/0.1/>. @prefix o: <http://example.org/ontology/>. <> a o:NetWorth; o:netWorthOf <http://example.org/users/JohnZSmith>; o:advisor <advisorContainer/bob#me>, <advisorContainer/marsha#me>. <advisorContainer/> a ldp:Container, ldp:IndirectContainer; dcterms:title "The asset advisors of JohnZSmith"; ldp:containerResource <>; ldp:containsRelation o:advisor; ldp:insertedContentRelation foaf:primaryTopic; ldp:contains <advisorContainer/bob>, <advisorContainer/marsha>.
To
handle
this
type
of
data
about
each
member
indirection,
the
triple
with
predicate
of
ldp:insertedContentRelation
and
object
of
foaf:primaryTopic
informs
clients
that
is
provided.
Some
common
strategies
when
POSTing
to
this
container,
they
need
to
include
providing
a
fixed
number
triple
of
standard
properties,
or
providing
the
entire
RDF
representation
form
(<>,
foaf:primaryTopic,
topic-URI)
to
inform
the
server
which
URI
to
use
(
topic-URI
)
in
the
new
membership
triple.
This
type
of
each
container
is
also
referred
to
as
an
LDP
Indirect
Container
.
It
is
similar
to
a
an
LDP
Direct
Container
but
it
provides
an
indirection
to
add
(via
a
create
request)
as
member
any
resource,
or
providing
nothing.
The
server
application
domain
and
its
use-cases
will
determine
how
much
information
such
as
a
URI
representing
a
real-world
object,
that
is
required.
different
from
the
document
that
is
created.
Continuing
on
from
illustrates
the
net
worth
example,
3
types:
Basic,
Direct
and
Indirect,
along
with
their
relationship
to
types
of
LDPRs.
It
is
not
expected
that
there
will
be
additional
triples
for
the
member
resources
(assets)
in
the
representation:
a
container
with
a
rdf:type
solely
of
ldp:Container
.
In
a
similar
manner,
when
the
representation
for
PENDING
--
table
work
in
progress,
if
found
valuable...we'll
keep.
The
following
table
illustrates
some
differences
between
membership
and
containment
triples.
For
details
on
the
resource
normative
behavior,
see
appropriate
sections
below.
Completed Request | Effects | |
---|---|---|
Membership | Containment | |
LDPR created in LDPC (any subtype) |
New
triple
based
on
type
of
| New triple: (LDPC, ldp:contains, LDPR) |
LDPR created in LDP-BC | New triple: (LDPC, ldp:contains, LDPR) | Same |
LDPR created in LDP-DC |
New
triple
links
LDP-RR
to
created
LDPR.
LDP-RR
URI
may
| New triple: (LDPC, ldp:contains, LDPR) |
LDPR created in LDP-IC | New triple links LDP-RR to content indicated URI | New triple: (LDPC, ldp:contains, LDPR) |
LDPR is deleted | Triples may be removed | Triples are removed |
LDPC is deleted | Triples and member resources may be removed |
Triples
of
|
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
subset
of
the
container's
properties
that
are
unrelated
to
member
resources
and
unrelated
to
contained
documents,
for
example
to
determine
the
membership
triple
pattern
and
membership
predicate
of
a
LDP-DC.
LDP
calls
these
empty-container
triples
,
because
they
are
what
remains
when
the
container.
container
has
zero
members
and
zero
contained
resources.
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
we
define
a
way
to
retrieve
only
the
non-member
these
property
values.
Defining
for
each
LDPC
values
(and
more
generally,
a
corresponding
resource,
called
way
to
retrieve
only
the
“
non-member
resource
”,
whose
state
is
a
subset
of
the
state
properties
used
to
address
other
major
clusters
of
use
cases).
LDP
adds
parameters
to
the
container,
does
this.
HTTP
Prefer
header's
return=representation
preference
for
this
(see
for
details).
The
example
listed
here
only
show
shows
a
simple
case
where
only
a
few
simple
non-member
properties
empty-container
triples
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
empty-container
triples
of
a
container
identified
by
the
URL
http://example.org/container1/
.
In
this
case,
the
non-member
resource
is
identified
by
the
URL
http://example.org/container1?non-member-properties
:
Request:
GET /container1 HTTP/1.1 Host: example.orgAccept: text/turtle; charset=UTF-8Accept: text/turtle; charset=UTF-8 Prefer: return=representation; include="http://www.w3.org/ns/ldp#PreferEmptyContainer"
Response:
HTTP/1.1 200 OK Content-Type: text/turtle; charset=UTF-8 ETag: "_87e52ce291112" Content-Length: 325 Link: <http://www.w3.org/ns/ldp/Container>; rel="type" Preference-Applied: return=representation@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/>a ldp:Container; dcterms:title "A Linked Data Platform Container of Acme Resources"; ldp:membershipSubject http://example.org/container1/; ldp:membershipPredicate rdfs:member; ldp:membershipObject ldp:MemberSubject; dcterms:publisher <http://acme.com/>.a ldp:Container, ldp:DirectContainer; dcterms:title "A Linked Data Platform Container of Acme Resources"; ldp:containerResource <http://example.org/container1/>; ldp:containsRelation ldp:member; ldp:insertedContentRelation ldp:MemberSubject; dcterms:publisher <http://acme.com/>.
While
the
same
non-member
resource
could
be
used
to
update
the
non-member
properties
via
PUT,
LDP
recommends
using
PATCH
to
update
these
properties,
if
necessary.
It
provides
no
facility
for
this
purpose.
updating
them
via
PUT
without
replacing
the
entire
container's
state.
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
becomes
more
important
for
LDPC
LDP
servers
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
higher
sort
order
no
lower
than
all
members
on
the
previous
page
and
lower
sort
order
no
higher
than
all
the
members
on
the
next
page.
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.
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
ldp:containerSortCriteria
relation.
Each
member
of
the
ordered
list
exposes
one
ldp:containerSortCriterion
,
consisting
of
a
ldp:containerSortOrder
,
ldp:containerSortPredicate
,
and
optionally
a
ldp:containerSortCollation
.
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/ # @base <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/>. <>a ldp:Container; dcterms:title "The assets of JohnZSmith"; ldp:membershipSubject <http://example.org/netWorth/nw1>; ldp:membershipPredicate o:asset; ldp:membershipObject ldp:MemberSubject.a ldp:Container, ldp:DirectContainer; dcterms:title "The assets of JohnZSmith"; ldp:containerResource <http://example.org/netWorth/nw1>; ldp:containsRelation o:asset; ldp:insertedContentRelation ldp:MemberSubject. <?firstPage> a ldp:Page;ldp:pageOf <>; ldp:containerSortCriteria (#SortValueAscending).ldp:pageOf <>; ldp:containerSortCriteria (<#SortValueAscending>). <#SortValueAscending> a ldp:ContainerSortCriterion;ldp:containerSortOrder ldp:Ascending;ldp:containerSortOrder ldp:Ascending; ldp:containerSortPredicate o:value. <http://example.org/netWorth/nw1>a o:NetWorth;a o:NetWorth; o:asset <a1>, <a3>, <a2>. <a1>a o:Stock; o:value 100.00.a o:Stock; o:value 100.00 . <a2>a o:Cash; o:value 50.00.a o:Cash; o:value 50.00 . <a3>a o:RealEstateHolding; o:value 300000.a o:RealEstateHolding; o:value 300000 .
As
you
can
see
by
the
addition
of
the
ldp:ContainerSortCriteria
predicate,
the
o:value
predicate
is
used
to
order
the
page
members
in
ascending
order.
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.
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.
The Linked Data Platform does not define how clients discover LDPCs .
rdf:type
of
ldp:BasicContainer
for
Linked
Data
Platform
Basic
Container
ldp:DirectContainer
for
Linked
Data
Platform
Direct
Container
ldp:IndirectContainer
for
Linked
Data
Platform
Indirect
Container
rdf:Bag
,
rdf:Seq
or
rdf:List
.
ldp:member
predicate
as
an
LDPC's
membership
predicate
if
there
is
no
obvious
predicate
from
an
application
vocabulary
to
use
(
LDP-BCs
always
use
ldp:contains
).
The
state
of
an
LDPC
includes
information
about
which
resources
are
its
ldp:membershipSubject
ldp:containerResource
,
and
whose
object
is
the
ldp:containerResource
,
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.
ldp:membershipPredicate
ldp:containsRelation
or
ldp:membershipPredicateInverse
ldp:containedByRelation
.
The
object
of
the
triple
is
constrained
by
other
sections,
such
as
ldp:membershipPredicate
ldp:containsRelation
,
ldp:membershipPredicate
ldp:containsRelation
,
ldp:contains
,
but
there
is
no
requirement
to
materialize
this
triple
ldp:membershipPredicateInverse
ldp:containedByRelation
,
ldp:membershipPredicateInverse
ldp:insertedContentRelation
,
GET
foaf:primaryTopic
rdf:type
ldp:insertedContentRelation
rdf:type
ldp:MemberSubject
rdf:Seq
ldp:MemberSubject
ldp:MemberSubject
says
that
ldp:membershipObject
,
Link
header
with
POST
http://www.w3.org/ns/ldp#Container
,
and
a
link
relation
type
of
type
rel='type'
)
in
all
responses
to
requests
made
to
the
LDPC's
HTTP
Location
Request-URI
.
LDP
servers
MAY
provide
additional
HTTP
Link:
rel='type'
ldp:containerSortCriteria
,
and
whose
object
is
a
rdf:List
of
ldp:containerSortCriterion
resources.
The
resulting
order
MUST
be
as
defined
by
SPARQL
SELECT
’s
ORDER
BY
clause
ldp:containerSortCriteria
MUST
contain,
in
every
ldp:containerSortCriterion
list
entry,
a
triple
whose
subject
is
the
sort
criterion
identifier,
whose
predicate
is
ldp:containerSortPredicate
and
whose
object
is
the
predicate
whose
value
is
used
to
order
members
between
pages
(the
page-ordering
values
).
The
only
SELECT
’s
ORDER
BY
clause
ldp:containerSortCriteria
MUST
contain,
in
every
ldp:containerSortCriterion
list
entry,
a
triple
whose
subject
is
the
sort
criterion
identifier,
whose
predicate
is
ldp:containerSortOrder
and
whose
object
describes
the
order
used.
LDP
defines
two
values,
ldp:Ascending
and
ldp:Descending
,
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.
ldp:containerSortCriteria
MAY
contain,
in
any
ldp:containerSortCriterion
list
entry,
a
triple
whose
subject
is
the
sort
criterion
identifier,
whose
predicate
is
ldp:containerSortCollation
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
ldp:containerSortCollation
triple
is
absent
and
the
page-ordering
values
are
strings
or
simple
literals
fn:compare
,
that
is,
it
behaves
as
if
http://www.w3.org/2005/xpath-functions/collation/codepoint
was
the
specified
collation.
When
the
ldp:containerSortCollation
triple
is
present
and
the
page-ordering
values
are
strings
or
simple
literals
fn:compare
,
that
is,
the
specified
collation.
The
ldp:containerSortCollation
triple
This
specification
imposes
the
following
new
requirements
on
Per
[HTTP11],
this
HTTP
POST
for
LDPCs
only
when
an
LDPC
supports
that
method.
This
method
is
optional
and
this
specification
does
not
impose
any
new
requirement
require
LDP
servers
to
support
that
it.
When
a
LDP
server
chooses
to
support
this
method,
and
[
HTTP11
this
specification
imposes
the
following
new
requirements
for
LDPCs.
Any
server-imposed
constraints
on
creation
or
update
must
be
advertised
]
makes
it
optional.
to
clients.
POST
to
a
known
Location
header
set
to
the
new
resource’s
URL.
Clients
shall
not
expect
any
representation
in
the
response
entity
body
on
a
201
(Created)
response.
POST
request
to
a
LDPC
POST
request
to
a
LDPC
POST
of
Note:
A
consequence
of
this
is
that
LDPCs
within
a
LDPC
.
5.4.5
LDPC
can
be
used
to
create
LDPCs,
if
the
server
supports
doing
so.
Content-Type
with
value
of
text/turtle
Content-Type
request
header
to
determine
the
representation
format
when
the
request
has
an
entity
body.
POST
,
using
the
HTTP
Slug
header
as
defined
in
POST
SHOULD
NOT
re-use
Location
response
header),
Link
meta
and
href
to
be
the
URI
of
the
meta-resource
POST
MUST
include
an
Accept-Post
response
header
on
HTTP
OPTIONS
responses,
listing
post
document
media
type(s)
supported
by
the
server.
LDP
only
specifies
the
use
of
POST
for
the
purpose
of
creating
new
resources,
but
a
server
can
accept
POST
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
POST
request
will
result
in
the
creation
of
a
new
resource;
they
must
rely
on
out
of
band
information
for
knowledge
of
which
POST
requests,
if
any,
will
have
the
"create
new
resource"
semantics.
This
requirement
on
LDP
servers
is
intentionally
stronger
than
the
one
levied
in
the
header
registration
;
it
is
unrealistic
to
expect
all
existing
resources
that
support
POST
to
suddenly
return
a
new
header
or
for
all
new
specifications
constraining
POST
to
be
aware
of
its
existence
and
require
it,
but
it
is
a
reasonable
requirement
for
new
specifications
such
as
LDP.
ldp:created
ldp:contains
predicate
for
this
purpose.
An
LDPC
that
tracks
members
created
through
the
LDPC
MUST
add
a
triple
to
the
container
whose
subject
is
the
container's
URI,
whose
predicate
is
ldp:created
ldp:contains
,
and
whose
object
is
the
newly
created
member
resource's
URI;
it
MAY
add
other
triples
as
well.
PUT
ldp:insertedContentRelation
ldp:MemberSubject
and
that
ldp:contains
,
and
whose
object
is
the
newly
created
resource's
URI
(which
will
be
different
from
the
member-derived
URI
in
this
case).
This
ldp:contains
triple
can
be
the
only
link
from
the
container
to
the
newly
created
resource
in
certain
cases.
Per
[HTTP11],
this
HTTP
method
is
optional
and
this
specification
does
not
impose
any
new
requirement
require
LDP
servers
to
support
that
it.
When
a
LDP
server
chooses
to
support
this
method,
and
[
HTTP11
this
specification
imposes
the
following
new
requirements
for
LDPCs.
Any
server-imposed
constraints
on
creation
or
update
must
be
advertised
]
makes
it
optional.
to
clients.
PUT
to
update
a
PUT
SHOULD
NOT
re-use
This
specification
imposes
the
following
new
requirements
on
Per
[HTTP11],
this
HTTP
DELETE
for
LDPRs
method
is
optional
and
LDPCs
only
when
a
LDPC
supports
that
method.
This
this
specification
does
not
impose
any
new
requirement
require
LDP
servers
to
support
that
it.
When
a
LDP
server
chooses
to
support
this
method,
and
[
HTTP11
]
makes
it
optional.
this
specification
imposes
the
following
new
requirements
for
LDPCs.
Non-normative note: TheLDPCLDP serverMAYmight perform additionalremoval of member resources.actions, as described in the normative references like [[HTTP11]]. For example, the server could perform additional cleanup tasks for resources it knows are no longer referenced or have not been accessed for some period of time.5.6.3 When the conditions in 5.6.1 hold, and the LDPC tracks member resources that it created using the ldp:created predicate, the LDPC server MUST also remove the deleted member's ldp:created triple. 5.6.4
Note
that
certain
LDP
mechanisms,
such
as
paging,
paging
,
rely
on
HTTP
headers,
and
HTTP
generally
requires
that
HEAD
responses
include
the
same
headers
as
GET
responses.
Also
LDPC
LDP
servers
must
also
include
HTTP
headers
on
response
to
OPTIONS
,
see
.
Thus,
implementers
supporting
HEAD
should
also
carefully
read
the
section
5.3
and
section
5.9
.
This
specification
imposes
the
following
new
requirements
on
Per
[HTTP11],
this
HTTP
PATCH
for
LDPCs
only
when
a
LDPC
supports
that
method.
This
method
is
optional
and
this
specification
does
not
impose
any
new
requirement
require
LDP
servers
to
support
that
it.
When
a
LDP
server
chooses
to
support
this
method,
and
[
HTTP11
this
specification
imposes
the
following
new
requirements
for
LDPCs.
Any
server-imposed
constraints
on
LDPR
creation
or
update
must
be
advertised
]
makes
it
optional.
to
clients.
PATCH
as
the
preferred
method
for
updating
This
specification
imposes
the
following
new
requirements
on
HTTP
OPTIONS
for
LDPCs
.
LDPCs.
POST
ed
to
the
LDPC
and
then
referenced
by
a
membership
triple)
it
might
create
an
associated
Link
header
whose
target
URI
is
the
associated
meta
The
LDP
Working
Group
proposes
incorporation
of
the
features
described
in
this
section.
The
addition
While
readers,
and
especially
implementers,
of
resource
inlining
LDP
are
assumed
to
save
application
latency
and
server/network
load
understand
the
information
in
controlled
environments.
Feedback,
both
positive
and
negative,
is
invited
by
sending
email
its
normative
references,
the
working
group
has
found
that
certain
points
are
particularly
important
to
understand.
For
those
thoroughly
familiar
with
the
mailing
list
in
Status
referenced
specifications,
these
points
might
seem
obvious,
yet
experience
has
shown
that
few
non-experts
find
all
of
This
Document
.
5.10.1
Introduction
them
obvious.
This
section
enumerates
these
topics;
it
is
non-normative.
One
of
simply
re-stating
(non-normatively)
information
locatable
via
the
most
commonly
cited
scenarios
for
resource
inlining
is
to
save
clients
enumerating
a
container
normative
references.
POST
,
PUT
,
etc.).
Certain
specific
cases
exist
where
a
LDPC
server
Request-URI
in
DELETE
request.
After
such
a
request,
a
subsequent
HTTP
ldp:Page
GET
Request-URI
usually
results
in
a
404
(Not
found)
or
ldp:Page
DELETE
GET
PATCH
GET
PATCH
ldp:Page
Content-Type
ldp:Page
GET
rdf:type
predicate.
Feature At Risk
The LDP Working Group proposes incorporation of the features described in this section.
Accept-Post
in
this
specification
is
pending
advancement
of
an
IETF
draft
that
would
fully
include
it,
This
specification
introduces
a
new
HTTP
response
header
Accept-Post
used
to
specify
the
document
formats
accepted
by
the
server
on
HTTP
POST
requests.
It
is
modeled
modelled
after
the
Accept-Patch
header
defined
in
[
RFC5789
].
[[!RFC5789]].
Accept-Post
,
using
the
ABNF
syntax
defined
in
Section
2.1
of
Accept-Post = "Accept-Post" ":" 1#media-type
The
Accept-Post
header specifies a comma-separated list of media- types (with optional parameters) as defined by[ HTTP11 ],[[!HTTP11]], Section 3.7.
Accept-Post
HTTP
header
SHOULD
appear
in
the
OPTIONS
response
for
any
resource
that
supports
the
use
of
the
POST
method.
The
presence
of
the
Accept-Post
header
in
response
to
any
method
is
an
implicit
indication
that
POST
is
allowed
on
the
resource
identified
by
the
Request-URI
.
The
presence
of
a
specific
document
format
in
this
header
indicates
that
that
specific
format
is
allowed
on
POST
requests
to
the
resource
identified
by
the
Request-URI
.
The Accept-Post response header must be added to the permanent registry (see
[ RFC3864 ]).[[!RFC3864]]).Header field name: Accept-Post
Applicable Protocol: HTTP
Author/Change controller: W3C
Specification document: this specification
This
specification
introduces
new
parameters
on
the
HTTP
Prefer
request
header's
return=representation
preference
[[!Prefer]],
used
optionally
by
clients
to
supply
a
hint
to
help
the
server
form
a
response
that
is
most
appropriate
to
the
client's
needs.
The
LDP-defined
parameters
suggest
the
portion(s)
of
a
resource's
state
that
the
client
application
is
interested
in
and,
if
received,
is
likely
to
be
processed.
LDP
Containers
with
large
numbers
of
associated
documents
and/or
members
will
have
large
representations,
and
many
client
applications
may
be
interested
in
processing
only
a
subset
of
the
LDPC's
information
(for
example,
only
membership
triples
or
only
containment
triples),
resulting
in
a
potentially
large
savings
in
server,
client,
and
network
processing.
Non-normative note: LDP server implementers should carefully consider the effects of these preferences on caching, as described in section 2 of [[!Prefer]].
Non-normative
note:
[[!Prefer]]
recommends
that
server
implementers
include
a
Preference-Applied
response
header
when
the
client
cannot
otherwise
determine
the
server's
behavior
with
respect
to
honoring
hints
from
the
response
content.
Examples
illustrates
some
cases
where
the
header
is
unnecessary.
include
hint
defines
a
subset
of
an
LDPR's
content
that
a
client
would
like
included
in
a
representation.
The
syntax
for
the
include
parameter
of
the
HTTP
Prefer
request
header's
return=representation
preference
[[!Prefer]]
is:
include-parameter = "include" *WSP "=" *WSP ldp-uri-list
Where
WSP
is whitespace [[!RFC5234]], andldp-uri-list
is a double-quoted blank-delimited unordered set of URIs whose ABNF is given below. The generic preference BNF [[!Prefer]] allows either a quoted string or a token as the value of a preference parameter; LDP assigns a meaning to the value only when it is a quoted string of the form:ldp-uri-list = DQUOTE *WSP URI *[ 1*WSP URI ] *WSP DQUOTE
where
DQUOTE
is a double quote [[!RFC5234]], andURI
is an absolute URI with an optional fragment component [[!RFC3986]].
omit
hint
defines
a
subset
of
an
LDPR's
content
that
a
client
would
like
omitted
from
a
representation.
The
syntax
for
the
omit
parameter
of
the
HTTP
Prefer
request
header's
return=representation
preference
[[!Prefer]]
is:
omit-parameter = "omit" *WSP "=" *WSP ldp-uri-list
Where
WSP
andldp-uri-list
are defined as above for include .
include
and
omit
parameters.
It
assigns
no
meaning
to
other
URIs,
although
other
specifications
MAY
do
so.
Containment triples |
http://www.w3.org/ns/ldp#PreferContainment
|
Membership triples |
http://www.w3.org/ns/ldp#PreferMembership
|
Empty-container triples |
http://www.w3.org/ns/ldp#PreferEmptyContainer
|
Non-normative note: all currently defined URIs are only coherent for LDP-RRs, and in fact only for LDPCs, however in the future it is
non-normative.possible that additional URIs with other scopes of applicability could be defined.
If we assume a container like the one below:
# The following is the representation of # http://example.org/netWorth/nw1/assetContainer/ # @base <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/>. <> a ldp:Container, ldp:DirectContainer; dcterms:title "The assets of JohnZSmith"; ldp:containerResource <http://example.org/netWorth/nw1>; ldp:containsRelation o:asset; ldp:insertedContentRelation ldp:MemberSubject. <http://example.org/netWorth/nw1> a o:NetWorth; o:asset <a1>, <a3>, <a2>. <a1> a o:Stock; o:value 100.00 . <a2> a o:Cash; o:value 50.00 . <a3> a o:RealEstateHolding; o:value 300000 .
Clients
interested
only
in
information
about
the
container
(for
example,
which
membership
predicate
it
uses)
might
use
this
hint
on
a
GET
request:
Prefer:
return=representation;
include="http://www.w3.org/ns/ldp#PreferEmptyContainer"
A
server
that
honors
this
hint
would
return
a
following
response
containing
the
HTTP
header
Preference-Applied:
return=representation
and
this
representation:
# The following is the ordered representation of # http://example.org/netWorth/nw1/assetContainer/ # @base <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/>. <> a ldp:Container, ldp:DirectContainer; dcterms:title "The assets of JohnZSmith"; ldp:containerResource <http://example.org/netWorth/nw1>; ldp:containsRelation o:asset; ldp:insertedContentRelation ldp:MemberSubject.
Clients
interested
only
in
information
about
the
container
(same
as
before)
might
use
this
hint
instead:
Prefer:
return=representation;
omit="http://www.w3.org/ns/ldp#PreferMembership
http://www.w3.org/ns/ldp#PreferContainment"
.
Note:
Treating
the
two
as
equivalent
is
not
recommended.
While
today
this
omit
parameter
value
is
equivalent
to
the
preceding
include
parameter
value,
they
may
not
be
equivalent
in
the
future
due
to
the
definition
of
empty-container
triples
.
Clients
should
preferentially
use
the
include
parameter,
as
it
more
precisely
communicates
their
needs.
A LDP 1.0 server that honors this hint would return the following response. Servers implementing later versions of LDP might return substantively different responses.
# The following is the ordered representation of # http://example.org/netWorth/nw1/assetContainer/ # @base <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/>. <> a ldp:Container, ldp:DirectContainer; dcterms:title "The assets of JohnZSmith"; ldp:containerResource <http://example.org/netWorth/nw1>; ldp:containsRelation o:asset; ldp:insertedContentRelation ldp:MemberSubject.
Clients
interested
only
in
information
about
the
container
(for
example,
which
membership
predicate
it
uses)
and
its
membership
might
use
this
hint
on
a
GET
request:
Prefer:
return=representation;
include="http://www.w3.org/ns/ldp#PreferMembership
http://www.w3.org/ns/ldp#PreferEmptyContainer"
A
server
that
honors
this
hint
would
return
(at
least)
the
following
response,
and
perhaps
only
this
(it
might
well
omit
containment
triples
if
they
are
not
specifically
requested).
In
cases
like
this
example,
where
a
client
can
detect
from
the
content
that
its
hints
were
honored
(the
presence
of
the
predicates
dcterms:title
and
o:asset
demonstrate
this
in
the
representation
below),
there
is
no
need
for
the
server
to
include
a
Preference-Applied
response
header
in
many
common
cases
like
a
200
(OK)
response.
In
other
cases,
like
status
code
303
,
the
header
would
still
be
required
for
the
client
to
know
that
the
303
response
entity
is
a
representation
of
the
resource
identified
by
the
Location
URI
instead
of
a
short
hypertext
note
(one
with
a
hyperlink
to
the
same
URI
reference
provided
in
the
Location
header
field
[[HTTPbis]]).
# The following is the representation of # http://example.org/netWorth/nw1/assetContainer/ # @base <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/>. <> a ldp:Container, ldp:DirectContainer; dcterms:title "The assets of JohnZSmith"; ldp:containerResource <http://example.org/netWorth/nw1>; ldp:containsRelation o:asset; ldp:insertedContentRelation ldp:MemberSubject. <http://example.org/netWorth/nw1> a o:NetWorth; o:asset <a1>, <a3>, <a2>.
The following people have been instrumental in providing thoughts, feedback, reviews, content, criticism and input in the creation of this specification:
Tim
Berners-Lee,
Steve
Battle,
Olivier
Berger,
Alexandre
Bertails,
Reza
B'Far,
Cody
Burleson,
Richard
Cyganiak,
Raúl
García
Castro,
Miguel
Esteban
Gutiérrez,
Sandro
Hawke,
Kingsley
Idehen,
Yves
Lafon,
Andrei
Sambra,
Andy
Seaborne,
Antonis
Loizou,
Arnaud
Le
Hors,
Antonis
Loizou,
Ashok
Malhota,
Roger
Menday,
Nandana
Mihindukulasooriya,
Kevin
Page,
Bart
van
Leeuwen,
Cody
Burleson,
David
Wood,
Eric
Prud'hommeaux,
Andy
Seaborne,
Steve
Speicher,
Erik
Wilde,
Henry
Story,
Ted
Thibodeau,
Bart
van
Leeuwen,
John
Arwe,
Kevin
Page,
Kingsley
Idehen,
Mark
Baker,
Martin
P.
Nally,
Miel
Vander
Sande,
Miguel
Esteban
Gutiérrez,
Nandana
Mihindukulasooriya,
Olivier
Berger,
Pierre-Antoine
Champin,
Raúl
García
Castro,
Reza
B'Far,
Richard
Cyganiak,
Roger
Menday,
Ruben
Verborgh,
Sandro
Hawke,
Serena
Villata,
Erik
Wilde,
David
Wood,
Martin
P.
Nally
Sergio
Fernandez,
Steve
Battle,
Steve
Speicher,
Ted
Thibodeau,
Tim
Berners-Lee,
Yves
Lafon
The change history is up to the editors to insert a brief summary of changes, ordered by most recent changes first and with heading from which public draft it has been changed from.
Internationalized Resource Identifiers (IRIs). January 2005. RFC. URL: http://www.ietf.org/rfc/rfc3987.txtLast Call Draft[RFC4627]D. Crockford.
. 15 January 2008. W3C Recommendation. URL: http://www.w3.org/TR/rdf-sparql-query/[SPARQL-UPDATE]Second Public Working DraftPaul Gearon; Alexandre Passant; Axel Polleres.
Turtle: Terse RDF Triple Language. January 2008. W3C Team Submission. URL: http://www.w3.org/TeamSubmission/turtle/First Public Working DraftB.2 Informative
ldp
namespace
(SS)
Architecture of the World Wide Web, Volume One. 15 December 2004. W3C Recommendation. URL: http://www.w3.org/TR/webarch/Submission