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
*,
(RDF*,
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
upon
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]].
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
].
[[HTTP11]].
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#>.
The status of the sections of Linked Data Platform 1.0 (this document) is as follows:
A
conforming
LDP
Server
server
is
an
application
program
that
processes
HTTP
requests
and
generates
HTTP
responses
that
conform
to
the
rules
defined
in
sections
on
LDPRs
and
LDPCs
.
A
conforming
LDP
Client
client
is
an
application
program
that
generates
HTTP
requests
and
processes
HTTP
responses
that
conform
to
the
rules
defined
in
sections
on
LDPRs
and
LDPCs
.
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. 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
.
LDPRs.
This
document
also
explains
how
to
include
information
about
each
member
in
the
resource’s
own
representation
and
how
to
paginate
the
resource
representation
if
it
gets
too
big.
Request-URI
of
the
LDPR
is
typically
the
subject
of
most
triples
in
the
response.
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
Link
header
with
a
target
URI
of
http://www.w3.org/ns/ldp/Resource
,
and
a
link
relation
type
of
type
(that
is,
rel="type"
)
in
all
responses
to
requests
made
to
the
resource's
HTTP
Request-URI
.
This
is
notionally
equivalent
to
the
presence
of
a
(subject-URI,
rdf:type
,
ldp:Resource
)
triple
in
the
resource.
The
HTTP
Link
header
is
the
method
by
which
servers
assert
their
support
for
the
LDP
spec
in
a
way
that
clients
can
introspect
dynamically
at
run-time.
Conservative
clients
should
note
that
a
server
can
host
a
mixture
of
LDPRs
and
other
resources,
and
therefore
there
is
no
implication
that
LDP
support
advertised
on
one
HTTP
Request-URI
means
that
other
resources
on
the
same
server
are
also
LDPRs.
Each
HTTP
Request-URI
needs
to
be
individually
introspected
by
a
conservative
client,
in
the
absence
of
outside
information.
GET
Method
for
text/turtle
representation
of
the
requested
LDPR
text/turtle
MUST
be
returned.
rdf:type
.
rdf:type
values
of
a
given
LDPR
can
change
over
time.
This
specification
adds
no
new
requirements
on
HTTP
POST
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
Creation
of
LDPRs
is
done
via
HTTP
POST
to
a
LDPC,
see
the
4.4
in
the
LDPC
parent
section
for
more
details.
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
]
[[!HTTP11]]
makes
it
optional.
PUT
is
performed
on
an
existing
resource,
LDPR
servers
MUST
replace
the
entire
persistent
state
of
the
identified
resource
with
the
entity
representation
in
the
body
of
the
request.
dcterms:modified
and
dcterms:creator
if
they
are
not
under
client
control.
Any
LDPR
servers
that
wish
to
support
a
more
sophisticated
merge
of
data
provided
by
the
client
with
existing
state
stored
on
the
server
for
a
resource
MUST
use
HTTP
PATCH
,
not
HTTP
PUT
.
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
SHOULD
require
the
HTTP
If-Match
header
and
HTTP
ETags
to
detect
collisions.
LDPR
servers
MUST
respond
with
status
code
412
(Condition
Failed)
if
ETag
s
fail
to
match
PUT
to
update
the
resource.
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
PUT
.
This
specification
imposes
the
following
new
requirements
on
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
]
[[!HTTP11]]
makes
it
optional.
Additional
requirements
on
HTTP
DELETE
of
LDPRs
within
containers
can
be
found
in
section
5.6
.
Request-URI
.
After
a
successful
HTTP
DELETE
,
a
subsequent
HTTP
GET
on
the
same
Request-URI
MUST
result
in
a
404
(Not
found)
or
410
(Gone)
status
code.
Clients
SHOULD
note
that
servers
MAY
reuse
a
URI
under
some
circumstances.
DELETE
request.
For
example,
it
is
acceptable
for
the
server
to
remove
triples
from
other
resources
whose
subject
or
object
is
the
deleted
resource.
It
is
also
acceptable
and
common
for
LDPR
servers
to
not
do
this
–
behavior
is
server
application
specific.
Note
that
certain
LDP
mechanisms,
such
as
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
.
HEAD
method.
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
]
[[!HTTP11]]
makes
it
optional.
PATCH
to
allow
modifications,
especially
partial
replacement,
of
their
resources
PATCH
.
POST
(to
an
PUT
should
be
used
as
the
standard
way
to
create
new
PATCH
format
MUST
include
an
Accept-Patch
HTTP
response
header
[[!RFC5789]]
on
HTTP
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]].
Other
sections
of
this
specification,
for
example
PATCH
,
Accept-Post
and
Paging
,
add
other
requirements
on
OPTIONS
responses.
OPTIONS
method.
OPTIONS
request
on
the
LDPR’s
URL
with
the
HTTP
Method
tokens
in
the
HTTP
response
header
Allow
.
It
sometimes
happens
that
a
resource
is
too
large
to
reasonably
transmit
its
representation
in
a
single
HTTP
response.
This
will
be
used,
especially
true
if
the
resource
representation
includes
many
triples
both
from
its
own
representation
and
from
the
representations
of
any
of
its
members.
A
client
could
anticipate
that
a
resource
will
be
too
large
-
for
example,
a
client
tool
that
accesses
defects
may
assume
that
an
individual
defect
will
usually
be
of
sufficiently
constrained
size
that
it
makes
sense
to
request
all
of
it
at
once,
but
that
the
container
of
all
the
defects
ever
created
will
typically
be
too
big.
Alternatively,
a
server
could
recognize
that
a
resource
that
has
been
requested
is
too
big
to
return
in
a
single
message.
To
address
this
problem,
LDPRs
should
support
a
technique
called
Paging.
Paging
can
be
achieved
with
a
simple
RDF
pattern.
For
each
resource,
<resourceURL>
,
we
define
a
new
'first
page'
resource.
In
this
example,
its
URL
will
be
<containerURL>?firstPage
,
but
servers
are
free
to
construct
the
URL
as
opposed
they
see
fit.
The
triples
in
the
representation
of
the
each
page
are
a
subset
of
the
triples
in
the
resource
-
same
subject,
predicate
and
object.
LDPR
servers
may
respond
to
POST
requests
for
a
resource
by
redirecting
the
client
to
the
first
page
resource
–
using
a
303
“See
Other”
redirect
to
the
actual
URL
for
the
page
resource.
Looking
at
an
example
resource
representing
JohnZSmith's
net
worth,
we’ll
split
the
response
across
two
pages.
To
find
the
URL
of
the
first
page,
the
client
makes
a
OPTIONS
request
to
the
resource's
URL,
and
in
the
response
looks
for
a
HTTP
Link
header
with
rel="first"
;
the
target
URI
in
the
header
is
the
URL
of
the
first
page
resource.
The
client
then
requests
the
first
page
as
http://example.org/netWorth/nw1/assetContainer/?firstPage
:
# The following is the representation of
# http://example.org/netWorth/nw1/assetContainer/?firstPage
@prefix rdf: <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/>
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>
a ldp:Page;
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;
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.
<http://example.org/netWorth/nw1/assetContainer/a2>
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/>
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/?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;
o:asset
<http://example.org/netWorth/nw1/assetContainer/a5>.
<http://example.org/netWorth/nw1/assetContainer/a5>
a o:Stock;
dcterms:title "Big Co.";
o:value 200.02.
In
this
example,
there
is
only
one
member
in
the
container
in
the
final
page.
To
indicate
this
is
the
last
page,
a
given
mime
type?
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.
In
addition
to
the
requirements
set
forth
in
section
(HTTP
GET
),
LDPR
servers
that
support
paging
must
also
follow
the
requirements
in
this
section
GET
requests
with
an
LDPR
as
the
Request-URI
,
LDPR
servers
that
support
paging
SHOULD
provide
an
HTTP
Link
header
whose
target
URI
is
the
first
page
resource,
and
whose
link
relation
type
is
first
[[!RFC5988]].
This
is
the
mechanism
by
which
clients
discover
the
URL
of
the
first
page.
If
no
such
Link
header
is
present,
then
conservative
clients
will
assume
that
the
LDPR
does
not
support
paging.
For
example,
if
there
is
a
LDPR
with
URL
<resourceURL>
that
supports
paging
and
whose
first
page
URL
is
<resourceURL>?theFirstPage
,
then
the
corresponding
link
header
would
be
Link:
<?theFirstPage>;rel="first"
.
The
representation
for
any
page,
including
the
first,
will
include
the
URL
for
the
next
page. See
for
additional
details.
303
See
Other
response
with
an
HTTP
Location
header
providing
the
first
page
resource
URL.
rdf:type
and
object
is
ldp:Page
.
It
also
SHOULD
have
1
triple
to
indicate
the
resource
it
is
paging,
whose
subject
is
the
URL
of
the
page,
predicate
is
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
.
OPTIONS
request
on
the
LDPR’s
URL
with
the
HTTP
response
header
for
link
relations
using
the
header
name
of
Link
and
link
relation
type
first
[[!RFC5988]].
Feature At Risk
The LDP Working Group proposes incorporation of the features described in this section.
Feedback, both positive and negative, is invited by sending email to the mailing list in Status of This Document .
Servers whose resources are relatively granular may wish to optimistically provide more information in a response than what the client actually requested, in order to reduce the average number of client application HTTP flows. LDP provides some basic building blocks to enable this, that implementations can re-use to build complete solutions, and they may serve as complete solutions in applications with sufficient controls on resource content. These building blocks are 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 to influence which (if any) resources are inlined in any given response.
Servers
can
return
extra
triples
on
any
response,
but
fail
to
meet
the
definition
of
resource
inlining
,
by
either
returning
a
subset
of
the
other
resource(s)
triples
or
by
failing
to
assert
that
all
triples
were
included
(even
through
they
were).
Clients
might
still
find
the
extra
information
useful,
but
the
only
way
for
clients
to
be
sure
they
had
all
available
information
would
be
to
make
a
HTTP
GET
request
against
all
the
other
resource(s).
In
some
applications,
knowing
that
these
requests
are
unnecessary
saves
significant
latency
and
server/network
load.
The
building
blocks
LDP
provides
can
only
be
safely
used
if
certain
assumptions
hold.
Said
another
way,
resource
inlining
solves
a
subset
of
scenarios,
not
all
scenarios
in
the
general
case
—
so
if
you
care
about
any
of
the
following
in
a
given
application,
your
server
should
avoid
returning
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 is impossible for a client to reliably know which triples came from which HTTP resource(s). A general solution allowing quotation is RDF Datasets; that is expected to be standardized independently, and can be used in these cases once it is available.
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.
In addition to the requirements set forth in other sections, LDPR servers that support resource inlining must also follow the requirements in this section.
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
is
usually
not
part
of
the
HTTP
resource's
state,
and
its
presence
does
not
indicate
that
the
LDPR
server
supports
paging
in
general.
LDPR
servers
that
include
the
ldp:Page
resource
for
inlining
and
also
support
paging
MUST
use
the
same
ldp:Page
resource
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
the
set
of
HTTP
resources
whose
state
is
included
in
a
representation,
allowing
clients
to
avoid
HTTP
GET
requests
for
them.
ldp:Page
resource
described
in
section
4.10.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
Request-URI
of
an
inlined
resource
[[!HTTP11]].
GET
requests
against
any
resource
whose
HTTP
Request-URI
is
the
object
of
a
triple
of
the
form
described
in
section
4.10.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
any
inlined
resource(s)
may
have
changed
due
to
subsequent
requests.
ldp:Page
resource
or
lacking
the
triple
described
in
section
4.10.3.2
contain
all
the
triples
for
any
resource(s)
listed
in
the
representation
whose
HTTP
Request-URI
differs
from
the
HTTP
Request-URI
used
by
the
client.
The
representation
might
in
fact
contain
all
such
triples,
or
some
subset
of
them,
and
that
might
or
might
not
be
completely
adequate
for
the
client's
intended
usage,
but
an
LDP
client
has
no
way
to
discern
from
such
a
representation
which
interpretation
is
accurate.
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
It
goes
on
to
include
information
about
each
member
in
the
container’s
own
representation
and
explain
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
learn
about
a
member
of
more
than
one
container.
For
both
types
set
of
containers,
members
are
only
added
by
related
resources,
they
may
have
been
created
using
POST,
which
both
creates
the
resource
and
inserts
a
membership
triple.
A
request
POST
or
through
other
means.
It
also
defines
behavior
when
POST
created
resources
are
deleted,
to
delete
a
composite
clean
up
container
that
has
members,
will
result
in
all
the
members
membership,
and
the
container
itself
will
be
deleted.
A
member
resource
is
removed
from
a
composite
container
by
deleting
the
resource
directly,
which
containers
removes
the
membership
triple
from
the
container.
information
and
possibly
perform
some
cleanup
tasks
on
unreferenced
member
resoruces.
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#>. <> a ldp:Container;dcterms:title "A very simple container"; rdfs:member <member1>, <member2>, <member3>.ldp:membershipSubject <> ldp:membershipPredicate rdfs:member; 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,
predicate.
Let's
start
with
a
domain
resource
for
a
person's
net
worth,
as
illustrated
below.
below:
# The following is a partial representation of
# 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>.
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
below:
# The following is an elaborated representation of
# 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>.
<assetContainer/>
a ldp:Container;
ldp:membershipSubject <http://example.org/netWorth/nw1>;
dcterms:title "The assets of JohnZSmith";
ldp:membershipSubject <.>;
ldp:membershipPredicate o:asset.
<http://example.org/netWorth/nw1>
a o:NetWorth;
o:asset
<a1>,
<a2>.
<liabilityContainer/>
a ldp:Container;
dcterms:title "The liabilities of JohnZSmith";
ldp:membershipSubject <.>;
ldp:membershipPredicate o:liability.
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
predicates
are
o:asset
and
o:liability
–
a
predicate
predicates
from
the
domain
model.
A
POST
of
an
asset
representation
to
this
the
asset
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
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.
# 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/>. <> a ldp:Container; ldp:membershipSubject <http://example.org/netWorth/nw1>; ldp:membershipPredicate o:asset. <http://example.org/netWorth/nw1> a o:NetWorth; o:asset <a1>, <a2>.
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 ldp: <http://www.w3.org/ns/ldp#>. @prefix o: <http://example.org/ontology/>. <> 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 <a1>, <a3>, <a2>. <a1> a o:Stock; o:value 10000. <a2> a o:Bond; o:value 20000. <a3> a o:RealEstateHolding;o:value 300000.o:value 300000.
In
a
similar
manner,
when
the
representation
for
the
resource
of
asset
.../<a1>
is
returned
a
server
may
include
the
membership
triple
of
the
form
(.../assetContainer/,
o:asset,
.../a1).
5.1.2
Retrieving
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”,
“
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
http://example.org/container1/
.
In
this
case,
the
and
adding
query
string
non-member
resource
is
identified
by
the
URL
:
?non-member-properties
:
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-8ETag: "_87e52ce291112"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/> a ldp:Container;dcterms:title "A Linked Data Platform Container of Acme Resources";dcterms:title "A Linked Data Platform Container of Acme Resources"; ldp:membershipSubject http://example.org/container1/; ldp:membershipPredicate rdfs:member;dcterms:publisher <http://acme.com/>.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
could
anticipate
that
a
container
will
be
too
large
-
for
example,
a
client
tool
that
accesses
defects
may
assume
that
an
individual
defect
will
usually
be
of
sufficiently
constrained
size
that
it
makes
sense
to
request
all
of
it
at
once,
but
that
the
container
of
all
While
the
defects
ever
created
will
typically
be
too
big.
Alternatively,
a
server
same
non-member
resource
could
recognize
that
a
container
that
has
been
requested
is
too
big
to
return
in
a
single
message.
To
address
this
problem,
LDPCs
should
support
a
technique
called
Paging.
Paging
can
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
used
to
update
the
first
page
resource
–
non-member
properties
via
PUT,
LDP
recommends
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
client
requests
the
first
page
as
http://example.org/netWorth/nw1/assetContainer/?firstPage
:
# The following is the representation of
# http://example.org/netWorth/nw1/assetContainer/?firstPage
@prefix rdf: <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/>
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>
a ldp:Page;
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;
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.
<http://example.org/netWorth/nw1/assetContainer/a2>
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
PATCH
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/>
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/?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;
o:asset
<http://example.org/netWorth/nw1/assetContainer/a5>.
<http://example.org/netWorth/nw1/assetContainer/a5>
a o:Stock;
dcterms:title "Big Co.";
o:value
200.02.
In
this
example,
there
is
only
one
member
in
the
container
in
the
final
page.
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.
purpose.
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
more
important
for
LDPC
servers
when
containers
are
paginated.
If
the
server
does
not
respect
ordering
when
constructing
pages,
the
client
is
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
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
When
the
server
sort
is
descending,
the
opposite
order
is
used.
Since
more
than
one
value
may
use
be
used
to
communicate
sort
members,
the
LDPC
specification
allows
servers
to
assert
the
client
which
predicates
were
used
for
page
ordering.
Multiple
predicate
values
may
have
been
ordered
list
of
sort
criteria
used
for
sorting,
so
to
sort
the
value
members,
using
the
ldp:containerSortCriteria
relation.
Each
member
of
this
predicate
is
an
the
ordered
list.
list
exposes
one
ldp:containerSortCriterion
,
consisting
of
a
ldp:containerSortPredicate
,
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/ @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";dcterms:title "The assets of JohnZSmith"; ldp:membershipSubject <http://example.org/netWorth/nw1>; ldp:membershipPredicate o:asset. <?firstPage> a ldp:Page; ldp:pageOf <>;ldp:containerSortPredicates (o:value).ldp:ContainerSortCriteria (#SortValueAscending). <#SortValueAscending> a ldp:ContainerSortCriterion; ldp:containerSortOrder ldp:ascendingOrder; ldp:containerSortPredicate o:value. <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.o:value 300000.
As
you
can
see
by
the
addition
of
the
predicate,
the
ldp:containerSortPredicates
ldp:ContainerSortCriteria
o:value
predicate
is
used
to
define
the
ordering
of
order
the
results.
It
page
members
in
ascending
order.
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 LDPCs .
rdfs:member
predicate.
ldp:membershipSubject
,
and
whose
object
ldp:membershipPredicate
or
ldp:membershipPredicateInverse
.
The
object
of
the
triple
is
constrained
by
other
sections,
such
as
5.2.5.1
or
5.2.5.2
.
ldp:membershipPredicate
,
the
rdfs:member
.
This
triple's
ldp:membershipPredicate
,
P)
.
For
the
membership
predicate
URI
object
ldp:membershipPredicateInverse
,
the
object
MUST
be
the
URI
of
the
membership
predicate
ldp:membershipPredicateInverse
,
P)
.
For
the
membership
predicate
URI
object
used
in
the
triple
T
,
it
would
be
found
in
a
resource's
object
subject
R
and
same
predicate
P
membership
triples
of
the
form:
(
MR
,
P
,
R
),
where
MR
represents
URI
of
a
member
resource.
GET
on
each
member
individually.
See
section
5.1.1
Container
Member
Information
for
additional
details.
rdf:type
of
ldp:Container
,
but
it
MAY
have
additional
rdf:type
s.
rdf:Bag
,
rdf:Seq
or
rdf:List
.
POST
,
PUT
,
etc.).
Certain
specific
cases
exist
where
a
LDPC
server
MAY
delete
a
resource
and
then
later
re-use
the
URI
when
it
identifies
the
same
resource,
but
only
when
consistent
with
Web
architecture
[[WEBARCH]].
While
it
is
difficult
to
provide
absolute
implementation
guarantees
of
non-reuse
in
all
failure
scenarios,
re-using
URIs
creates
ambiguities
for
clients
that
are
best
avoided.
ldp:membershipObject
,
with
an
object
MO
.
Where
MO
and
the
HTTP
URI
R
from
POST
create
(as
found
in
HTTP
response
Location
header)
can
be
used
to
locate
a
triple
of
the
form:
(R,
MO,
N)
and
where
N
can
be
used
to
construct
the
membership
triple
of
the
form:
(membership
subject,
membership
predicate,
N)
.
When
ldp:membershipPredicateInverse
is
used
instead
of
ldp:membershipPredicate
,
the
membership
triple
MUST
be
of
the
form:
(N,
membership
predicate,
membership
subject)
.
To
indicate
that
the
member
resource
URI
is
the
membership
object
(the
default
or
typical
case),
the
object
MUST
be
set
to
predefined
URI
ldp:MemberSubject
such
that
it
forms
the
triple:
(LDPC
URI,
ldp:membershipObject
,
ldp:MemberSubject
)
.
<containerURL>
”
by
using
the
Request-URI
“
ldp:containerSortCriteria
,
and
whose
object
is
a
<containerURL>?firstPage
rdf:List
<containerURL>?firstPage
ldp:containerSortCriterion
firstPage
SELECT
ORDER
BY
clause
[[!SPARQL-QUERY]].
Sorting
criteria
MUST be
the
ldp:containerSortCriteria
MUST
ldp:containerSortCriterion
list
entry,
a
rdf:type
ldp:containerSortPredicate
and
whose
object
is
ldp:pageOf
,
SELECT
’s
ORDER
BY
clause
[[!SPARQL-QUERY]].
Other
data
types
can
be
used,
but
LDP
assigns
no
meaning
to
them
and
ldp:containerSortCriteria
MUST
ldp:containerSortCriterion
list
entry,
a
triple
ldp:nextPage
ldp:containerSortOrder
and
whose
object
ldp:nextPage
ldp:ascending
and
rdf:nil
.
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
ldp:containerSortPredicates
ldp:containerSortCriterion
ldp:containerSortCollation
and
whose
object
identifies
the
collation
used.
LDP
defines
no
values
for
use
as
the
object
ldp:containerSortCollation
triple
is
absent
and
the
page-ordering
values
are
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
fn:compare
,
that
is,
the
specified
collation.
When
the
ldp:containerSortCollation
triple
SHOULD
be
omitted
for
comparisons
involving
page-ordering
values
for
which
[[!SPARQL-QUERY]]
does
not
use
collations.
This
specification
imposes
the
following
new
requirements
on
HTTP
POST
for
LDPCs
only
when
an
LDPC
supports
that
method.
This
specification
does
not
impose
any
new
requirement
to
support
that
method,
and
[
HTTP11
]
[[!HTTP11]]
makes
it
optional.
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
POST
of
Content-Type
with
value
of
text/turtle
Content-Type
request
header
to
determine
the
representation
format
when
the
request
has
an
entity
body.
When
the
header
is
absent,
LDPC
servers
MAY
infer
the
content
type
by
inspecting
the
entity
body
contents
POST
,
using
the
HTTP
Slug
header
as
defined
in
[[!RFC5023]].
LDP
adds
no
new
requirements
to
this
usage,
so
its
presence
functions
as
a
client
hint
to
the
server
providing
a
desired
string
to
be
incorporated
into
the
server's
final
choice
of
resource
URI.
POST
SHOULD
NOT
re-use
URIs,
per
the
general
requirements
on
LDPCs
.
Location
response
header),
LDPC
servers
MAY
create
an
associated
LDPR
to
contain
data
about
the
created
resource.
If
an
LDPC
server
creates
this
associated
LDPR
it
MUST
indicate
its
location
on
the
HTTP
response
using
the
HTTP
response
header
Link
and
relationship
type
meta
and
href
to
be
the
URI
of
the
meta-resource
[[!RFC5988]].
POST
requests
create
new
resources.
Note from editor: the MUST here keeps this aligned with what we decided for OPTIONS on PATCH; in both cases the header registration says SHOULD, and the LDP spec says MUST. What makes that look a bit odd is that in the Accept-Post case, the registration and LDP are the same document. Thus I added informative text here explicitly talking to the apparent discrepancy.
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"
semantic.
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:contains
predicate
for
this
purpose.
An
LDPC
that
tracks
members
created
through
the
LDPC
MUST
add
a
triple
whose
subject
is
the
container's
URI,
whose
predicate
is
ldp:contains
,
and
whose
object
is
the
newly
created
member
resource's
URI;
it
MAY
add
other
triples
as
well.
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
]
[[!HTTP11]]
makes
it
optional.
PUT
to
update
a
PUT
on
ldp:membershipSubject
,
ldp:membershipPredicate
and
ldp:membershipPredicate
ldp:membershipPredicateInverse
.
Section
5.7.1
HTTP
HEAD
describes
the
process
by
which
clients
discover
whether
the
server
offers
such
a
resource,
and
if
so
its
URL.
PUT
requests
with
member
information
in
the
request
representation.
See
section
5.1.1
Container
Member
Information
for
additional
details.
PUT
SHOULD
NOT
re-use
URIs,
per
the
general
requirements
on
LDPCs
.
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
]
[[!HTTP11]]
makes
it
optional.
POST
'd
to
the
LDPC
and
then
referenced
by
a
membership
triple)
is
deleted,
and
the
LDPC
server
is
aware
of
the
member's
deletion
(for
example,
the
member
is
managed
by
the
same
server),
the
LDPC
server
MUST
also
remove
it
from
the
LDPC
by
removing
the
corresponding
membership
triple.
rdf:type
DELETE
Request-URI
.
The
LDPC
server
MAY
rdf:type
ldp:contains
ldp:contains
triple.
POST
'd
to
the
There
are
no
additional
requirements
Note
that
certain
LDP
mechanisms,
such
as
paging,
rely
on
HTTP
HEAD.
headers,
and
HTTP
generally
requires
that
HEAD
responses
include
the
same
headers
as
GET
responses.
Also
LDPR
servers
must
also
include
HTTP
headers
on
response
to
OPTIONS
,
see
4.6.2
.
Thus,
implementers
supporting
HEAD
should
also
carefully
read
the
5.8
and
.
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
]
[[!HTTP11]]
makes
it
optional.
PATCH
as
the
preferred
method
for
updating
LDPC
non-membership
properties.
This
specification
imposes
the
following
new
requirements
on
HTTP
OPTIONS
for
LDPCs.
OPTIONS
requests
with
an
LDPC
as
the
Request-URI
,
LDPC
servers
that
define
a
non-member
resource
SHOULD
provide
an
HTTP
Link
header
whose
target
URI
is
the
non-member
resource
,
and
whose
link
relation
type
is
http://www.w3.org/ns/ldp#non-member-resource
[[!RFC5988]].
This
is
the
mechanism
by
which
clients
discover
the
URL
of
the
non-member
resource.
If
no
such
Link
header
is
present,
then
conservative
clients
will
assume
that
the
LDPC
does
not
have
a
corresponding
non-member
resource.
For
example,
if
there
is
a
LDPC
with
URL
<containerURL>
whose
corresponding
non-member
resource
URL
is
<containerURL>?nonMemberProperties
,
then
the
corresponding
link
header
would
be
Link:
<?nonMemberProperties>;rel="http://www.w3.org/ns/ldp#non-member-resource"
POST
'd
to
the
LDPC
and
then
referenced
by
a
membership
triple)
it
might
create
an
associated
LDPR
to
contain
data
about
the
non-LDPR
(see
5.4.12
).
For
non-LDPRs
that
have
this
associated
LDPR,
an
LDPC
server
MUST
provide
an
HTTP
Link
header
whose
target
URI
is
the
associated
LDPR,
and
whose
link
relation
type
is
meta
[[!RFC5988]].
Feature At Risk
The LDP Working Group proposes incorporation of the features described in this section.
Feedback, both positive and negative, is invited by sending email to the mailing list in Status of This Document .
One of the most commonly cited scenarios for resource inlining is to save clients enumerating a container of m members from having to perform m+1 HTTP requests (or m+p , if the container is paged into p pages). The desire is to allow the server to reduce the number of HTTP round-trips by returning some (perhaps all) members' content as part of the container's representation. In addition to the general resource inlining mechanism useful in cases where only a subset of the members' content is inlined, LDP also provides a predicate for the special case where all of a container's or page's members are inlined. Rather than forcing the server to add a triple for each inlined member, forcing clients to compare the list of inlined members against the set of members in the representation, and enlarging the representation needlessly, a single triple can be used. This is called member inlining .
LDP does not provide clients with any way to detect whether or not the server is capable of resource inlining (all its resources or any specific resource), nor does it provide clients with any way to influence which (if any) resources are inlined in any given response.
The inlining building blocks LDP provides can only be safely used if certain assumptions hold. This is no less true for containers than for LDPRs in general. See the general cautions on resource inlining .
In
addition
to
the
requirements
set
forth
in
other
sections,
LDPC
servers
that
support
member
inlining
,
and
how
LDP
clients
aware
of
the
same
facility,
must
also
follow
the
requirements
in
this
section.
GET
on
the
member
URIs
to
retrieve
additional
triples.
marked
as
AT
RISK.
ldp:Page
resource
in
the
representation,
whether
or
not
the
representation
contains
multiple
pages,
as
described
in
section
4.10.3.1
.
In
addition
to
satisfying
those
requirements,
the
representation
MUST
contain
a
triple
whose
subject
is
the
ldp:Page
resource
URI,
whose
predicate
is
ldp:membersInlined
,
and
whose
object
is
true
.
This
is
means
by
which
the
server
communicates
to
LDP
clients
that
they
GET
requests
for
the
members
listed
on
the
page.
GET
requests
against
any
members
in
a
LDPC
representation
containing
a
ldp:Page
resource
with
the
triple
described
in
section
5.10.2.1
,
unless
there
are
application-specific
reasons
for
doing
so.
Clients
should
note
that
by
the
time
the
representation
is
received,
the
actual
state
of
inlined
members
may
have
changed
due
to
subsequent
requests.
ldp:Page
resource
or
lacking
the
triple
described
in
section
5.10.2.1
contain
all
the
triples
for
all
members
listed
in
the
representation.
The
representation
might
in
fact
contain
all
those
triples,
or
some
subset
of
them,
that
might
or
might
not
be
completely
adequate
for
the
client's
intended
usage,
but
an
LDP
client
has
no
way
to
discern
from
such
a
representation
which
interpretation
is
accurate.
This
section
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
non-normative.
modeled
after
the
Accept-Patch
header
defined
in
[[!RFC5789]].
Accept-Post
,
using
the
ABNF
syntax
defined
in
Section
2.1
of
[[!HTTP11]],
is:
Accept-Post = "Accept-Post" ":" 1#media-typeThe
Accept-Postheader specifies a comma-separated list of media- types (with optional parameters) as defined by [[!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]]).
Header field name: Accept-Post
Applicable Protocol: HTTP
Author/Change controller: W3C
Specification document: this specification
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,
Reza
B'Far,
Cody
Burleson,
Richard
Cyganiak,
Raúl
García
Castro,
Miguel
Esteban
Gutiérrez,
Sandro
Hawke,
Kingsley
Idehen,
Yves
Lafon,
Arnaud
Le
Hors,
Antonis
Loizou,
Ashok
Malhota,
Roger
Menday,
Nandana
Mihindukulasooriya,
Kevin
Page,
Eric
Prud'hommeaux,
Andy
Seaborne,
Steve
Speicher,
Henry
Story,
Ted
Thibodeau,
Bart
van
Leeuwen,
Miel
Vander
Sande,
Ruben
Verborgh,
Serena
Villata,
Erik
Wilde,
David
Wood,
Martin
P.
Nally
This
section
The
change
history
is
non-normative.
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.
FirstSecond Public Working Draft
SubmissionFirst Public Working Draft
ldp
namespace
(SS)
This section is non-normative. Other than LDP open actions and issues , included here are transient tasks and notes editors use. They have not meaning in final product of a published working draft and will be removed prior to publishing. Insert some additional examples 4.1.2: "the" subject ?= Request-URI ... not always (hash URIs) 4.1.5: refers to RDF *Primer* - is that intentful? 4.1.6.1: why does it have the extra .1, to avoid renumbering? should we divide General into subsections for vocab/client/server constraints? Do we need to define " LDPR server"? ...think about role vs artifact. If "an LDPR server" hosts both LDPRs and non- LDPR HTTP resources, 4.1.2 (if "the code" == LDPR server) could be read to say that in order to conform to spec it must serve up RDF for non- LDPRs . Hits 5.2.1 too. 4.1.7: define "explicitly"? 4.4.1: specifically calls out 2 props; issue-11 note talks about "server-managed props" which is not defined. 4.4.4/4.4.5 could be read to overlap/dup one another Deployment guide (was: 4.8 Common Properties) talks about rdfs:Range which implies inferencing. 4.1.7 spec says want to avoid putting that reqt on clients. 5.2.1: 4.1.6.1 issue linked to this text 5.2.2: I think we mean "resource" == any HTTP resource, not just LDPR . If so, perhaps we should be more explicit. 5.2.1 might be the place. 5.2.3-5.2.5: don't we need to tell clients to fetch LDPC 's non-member properties, introspect for these predicates, and (if either not found) supply the defaults? that is the net effect of what's here. 5.4.5: in light of the existence of server-managed properties, why not allow response body from create? Per David Wood, 'Sections 4.4.1, 4.5.1, 4.7.1, 5.4.1, 5.6.1 and 5.8.1 all relate to allowable write operations. I suggest adding the statement, "An LDPR server MAY require a user to be authenticated and authorized before this action is permitted." to each of those sections.', consider place to edit this in. ISSUE-37 Additional introductory text on the LDP data and interaction model ISSUE-5 Add a section explaining how LDP is related to Graph Store Protocol D. References D.1 Normative references [DC-RDF] M. Nilsson et al. Expressing Dublin Core metadata using the Resource Description Framework (RDF) . 14 January 2008. DCMI Recommendation. URL: http://dublincore.org/documents/dc-rdf/ [DC-TERMS] Dublin Core Metadata Initiative. Dublin Core Metadata Initiative Terms, version 1.1. 11 October 2010. DCMI Recommendation. URL: http://dublincore.org/documents/2010/10/11/dcmi-terms/ . [HTML401] David Raggett; Ian Jacobs; Arnaud Le Hors. HTML 4.01 Specification . 24 December 1999. W3C Recommendation. URL: http://www.w3.org/TR/1999/REC-html401-19991224 [HTTP11] R. Fielding et al. Hypertext Transfer Protocol - HTTP/1.1 . June 1999. RFC 2616. URL: http://www.ietf.org/rfc/rfc2616.txt [RDF-PRIMER] Frank Manola; Eric Miller. RDF Primer . 10 February 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-rdf-primer-20040210/ [RDF-SCHEMA] Dan Brickley; Ramanathan V. Guha. RDF Vocabulary Description Language 1.0: RDF Schema . 10 February 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-rdf-schema-20040210 [RFC2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt [RFC4627] D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON) . July 2006. RFC 4627. URL: http://www.ietf.org/rfc/rfc4627.txt [RFC5789] L Dusseault; J. Snell. PATCH Method for HTTP . March 2010. Internet Proposed Standard RFC 5789. URL: http://tools.ietf.org/html/rfc5789 [SPARQL-QUERY] E. Prud'hommeaux; A. Seaborne. SPARQL Query Language for RDF . W3C Recommendation. 15 January 2008. URL: http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/ [SPARQL-UPDATE] S. Schenk; P. Gearon. SPARQL 1.1 Update . W3C Working Draft. 26 January 2010. URL: http://www.w3.org/TR/2010/WD-sparql11-update-20100126/ [TURTLE] David Beckett; Tim Berners-Lee. Turtle: Terse RDF Triple Language . January 2008. W3C Team Submission. URL: http://www.w3.org/TeamSubmission/turtle/ D.2 Informative references [LINKED-DATA]Tim Berners-Lee. Linked Data Design Issues . 27 July 2006. W3C-Internal Document. URL: http://www.w3.org/DesignIssues/LinkedData.html [WEBARCH] Norman Walsh; Ian Jacobs. Architecture of the World Wide Web, Volume One . 15 December 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-webarch-20041215/Submission