ldbp-diff-20120919.html
author Steve Speicher <sspeiche@gmail.com>
Mon, 26 Jan 2015 11:51:28 -0500
changeset 938 859f98c26867
parent 5 05f73dea05fd
permissions -rw-r--r--
AC rep comment #2 on clarity on types in examples
<!DOCTYPE html>
<html>
  <head>
    <title>Linked Data Basic Profile 1.0</title>
    <meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
    <!-- 
      === NOTA BENE ===
      For the three scripts below, if your spec resides on dev.w3 you can check them
      out in the same tree and use relative links so that they'll work offline,
     -->
    <script src='http://www.w3.org/Tools/respec/respec-w3c-common' class='remove' async></script> 
    <script class='remove'>
      var respecConfig = {
          // specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
          specStatus:           "ED",
          
          // the specification's short name, as in http://www.w3.org/TR/short-name/
          shortName:            "ldbp",
          // TODO: Confirm short name

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

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

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

          // if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
          // and its maturity status
          previousPublishDate:  "2012-03-26",
          previousMaturity:  	"Member-SUBM",
          previousURI: 			"http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/",

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

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

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

          // editors, add as many as you like
          // only "name" is required
          editors:  [
              { name: "Steve Speicher", url: "http://stevespeicher.blogspot.com",
                company: "IBM Corporation", companyURL: "http://ibm.com/" },
          ],

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

          //authors:  [
          //    { name: "Your Name", url: "http://example.org/",
          //      company: "Your Company", companyURL: "http://example.com/" },
          //],
          
          // name of the WG
          wg:           "Linked Data Platform Working Group",
          
          // URI of the public WG page
          wgURI:        "http://www.w3.org/2012/ldp",
          
          // name (without the @w3c.org) of the public mailing to which comments are due
          wgPublicList: "public-ldp-wg",
          
          // URI of the patent status for this WG, for Rec-track documents
          // !!!! IMPORTANT !!!!
          // This is important for Rec-track documents, do not copy a patent URI from a random
          // document unless you know what you're doing. If in doubt ask your friendly neighbourhood
          // Team Contact.
          wgPatentURI:  "http://www.w3.org/2004/01/pp-impl/55082/status",
          doRDFa: "1.1",
      };
    </script>
    <style type="text/css">
    	div.rule {padding-top: 1em;}
    </style>
<style type='text/css'>
.diff-old-a {
  font-size: smaller;
  color: red;
}

.diff-new { background-color: yellow; }
.diff-chg { background-color: lime; }
.diff-new:before,
.diff-new:after
    { content: "\2191" }
.diff-chg:before, .diff-chg:after
    { content: "\2195" }
.diff-old { text-decoration: line-through; background-color: #FBB; }
.diff-old:before,
.diff-old:after
    { content: "\2193" }
:focus { border: thin red solid}
</style>
  </head>
<body>
<del class="diff-old">Linked
Data
Basic
Profile
1.0
W3C
Member
Submission
26
March
2012
This
Version:
http://www.w3.org/Submission/2012/SUBM-ldbp-20120326/
Latest
Version:
http://www.w3.org/Submission/ldbp/
Authors:
Martin
Nally,
IBM
Corporation
Steve
Speicher,
IBM
Corporation
John
Arwe,
IBM
Corporation
Arnaud
Le
Hors,
IBM
Corporation
Copyright
©
IBM
Corporation
2012.
This
document
is
available
under
the
W3C
Document
License
.
See
the
W3C
Intellectual
Rights
Notice
and
Legal
Disclaimers
for
additional
information.
Abstract
</del>
<section id='abstract'>
A
set
of
best
practices
and
simple
approach
for
a
read-write
Linked
Data
architecture,
based
on
HTTP
access
to
web
resources
that
describe
their
state
using
RDF.
<del class="diff-old">Status
of
This
Document
This
section
describes
the
status
of
this
document
at
the
time
of
its
publication.
Other
documents
may
supersede
this
document.
A
list
of
current
W3C
publications
can
be
found
in
the
W3C
technical
reports
index
at
http://www.w3.org/TR/.
This
document
is
a
part
of
the
Linked
Data
Basic
Profile
Submission,
which
comprises
two
documents:
Linked
Data
Basic
Profile
1.0
(this
document)
Linked
Data
Basic
Profile
1.0
-
Use
Cases
and
Requirements
By
publishing
this
document,
W3C
acknowledges
that
the
Submitting
Members
have
made
a
formal
Submission
request
to
W3C
for
discussion.
Publication
of
this
document
by
W3C
indicates
no
endorsement
of
its
content
by
W3C,
nor
that
W3C
has,
is,
or
will
be
allocating
any
resources
to
the
issues
addressed
by
it.
This
document
is
not
the
product
of
a
chartered
W3C
group,
but
is
published
as
potential
input
to
the
W3C
Process
.
A
W3C
Team
Comment
has
been
published
in
conjunction
with
this
Member
Submission.
Publication
of
acknowledged
Member
Submissions
at
the
W3C
site
is
one
of
the
benefits
of
W3C
Membership
.
Please
consult
the
requirements
associated
with
Member
Submissions
of
section
3.3
of
the
W3C
Patent
Policy
.
Please
consult
the
complete
list
of
acknowledged
W3C
Member
Submissions
.
Table
of
Contents
1.
Introduction
2.
Terminology
3.
Conformance
3.1
Conventions
Used
in
This
Document
4.
Basic
Profile
Resource
4.1
General
4.2
HTTP
GET
4.3
HTTP
POST
4.4
HTTP
PUT
4.5
HTTP
DELETE
4.6
HTTP
HEAD
4.7
HTTP
PATCH
4.8
Common
Properties
5.
Basic
Profile
Container
5.1
Informative
5.1.1
Container
Member
Information
5.1.2 Retrieving
Only
Non-member
Properties
5.1.3
Paging
5.1.4
Ordering
5.1
General
5.2
HTTP
GET
5.3
HTTP
POST
5.4
HTTP
PUT
5.5
HTTP
DELETE
5.6
HTTP
HEAD
5.7
HTTP
PATCH
6.
References
6.1
Normative
References
6.2
Informative
References
7.
Acknowledgements
</del>
</section>
<section>
<h1 id="intro">
<del class="diff-old">1.
</del>
Introduction
</h1>
<p>
This
document
describes
the
use
of
HTTP
for
accessing,
updating,
creating
and
deleting
resources
from
servers
that
expose
their
resources
as
Linked
Data.
 It
provides
some
new
rules
as
well
as
clarifications
and
extensions
of
the
four
rules
of
Linked
Data
<del class="diff-old">[4Rules]
</del>
<ins class="diff-chg">[[LINKED-DATA]]
</ins>
</p>
<p>
1.
Use
URIs
as
names
for
things
</p>
<p>
2.
Use
HTTP
URIs
so
that
people
can
look
up
those
names
</p>
<p>
3.
When
someone
looks
up
a
URI,
provide
useful
information,
using
the
standards
(RDF*,
SPARQL)
</p>
<p>
4.
Include
links
to
other
URIs.
so
that
they
can
discover
more
things
</p>
<p>
The
best
practices
and
anti-patterns
covered
in
this
document
are:
</p>
<ul>
<li>
<p>
<em>
Resources
</em>
-
a
summary
of
the
HTTP
and
RDF
standard
techniques
and
best
practices
that
you
should
use,
and
anti-patterns
you
should
avoid,
when
constructing
clients
and
servers
that
read
and
write
linked
data.
</p>
</li>
<li>
<p>
<em>
Containers
</em>
-
defines
resources
that
allow
new
resources
to
be
created
using
HTTP
POST
and
existing
resources
to
be
found
using
HTTP
GET. 
</p>
</li>
</ul>
<p>
Additionally,
it
is
the
intention
of
this
document
to
enable
additional
rules
and
layered
groupings
of
rules,
such
as
additional
profiles.
 The
scope
is
intentionally
narrow
to
provide
a
set
of
key
rules
for
reading
and
writing
Linked
Data
that
most,
if
not
all,
other
profiles
will
depend
on
and
implementations
will
support.
</p>
</section>
<section>
<h1 id="terms">
<del class="diff-old">2.
</del>
Terminology
</h1>
<p>
Terminology
is
based
on
W3C's
Architecture
of
the
World
Wide
Web
<del class="diff-old">[WEBARCH]
</del>
<ins class="diff-chg">[[WEBARCH]]
</ins>
and
Hyper-text
Transfer
Protocol
<del class="diff-old">[RFC2616] 
</del>
<ins class="diff-chg">[[HTTP11]] 
</ins>
</p>
<dl class="glossary">
<dt>
Link
</dt>
<dd>
A
relationship
between
two
resources
when
one
resource
(representation)
refers
to
the
other
resource
by
means
of
a
<del class="diff-old">URI.
[WEBARCH]
</del>
<ins class="diff-chg">URI.[[WEBARCH]]
</ins>
</dd>
<dt>
Linked
Data
</dt>
<dd>
As
defined
by
Tim
Berners-Lee.
<del class="diff-old">[4Rules]
</del>
<ins class="diff-chg">[[LINKED-DATA]]
</ins>
</dd>
<dt>
Profile
</dt>
<dd>
A
specification
that
defines
the
needed
components
from
other
specifications
as
well
as
providing
additional
clarifications
as
needed.
</dd>
<dt>
Basic
Profile
Resource
(BPR)
</dt>
<dd>
HTTP
resource
that
conforms
to
the
simple
lifecycle
patterns
and
conventions
in
this
document.
</dd>
<dt>
Basic
Profile
Container
(BPC)
</dt>
<dd>
BPR
resource
that
also
conforms
to
additional
patterns
and
conventions
in
this
document
for
managing
membership.
</dd>
<dt>
Client
</dt>
<dd>
A
program
that
establishes
connections
for
the
purpose
of
sending
requests.
<del class="diff-old">[RFC2616]
</del>
<ins class="diff-chg">[[HTTP11]]
</ins>
</dd>
<dt>
Server
</dt>
<dd>
An
application
program
that
accepts
connections
in
order
to
service
requests
by
sending
back
responses.
Any
given
program
may
be
capable
of
being
both
a
client
and
a
server;
our
use
of
these
terms
refers
only
to
the
role
being
performed
by
the
program
for
a
particular
connection,
rather
than
to
the
program's
capabilities
in
general.
Likewise,
any
server
may
act
as
an
origin
server,
proxy,
gateway,
or
tunnel,
switching
behavior
based
on
the
nature
of
each
request.
<del class="diff-old">[RFC2616]
</del>
<ins class="diff-chg">[[HTTP11]]
</ins>
</dd>
</dl>
<del class="diff-old">3.
Conformance
Conformance
is
defined
in
accordance
with
the
use
of
the
words
MUST
,
MUST
NOT
,
SHOULD
,
SHOULD
NOT
,
MAY
and
RECOMMENDED
as
described
in
RFC
2119
[RFC2119]
.
Conformance
statements
on
BPR
representations
apply
to
servers
and
clients
that
either
create
or
generate
representations
that
represent
the
state
of
a
BPR.
</del>
<section>
<h2 id="conventions">
<del class="diff-old">3.1
</del>
Conventions
Used
in
This
Document
</h2>
<p>
Sample
resource
representations
are
provided
in
<code>
text/turtle
</code>
format
<del class="diff-old">[TURTLE].
</del>
<ins class="diff-chg">[[TURTLE]].
</ins>
</p>
<p>
Commonly
used
namespace
prefixes:
</p>
<del class="diff-old">@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix rdfs:    &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
@prefix bp:      &lt;http://open-services.net/ns/basicProfile#&gt;.
</del>
	<pre style="word-wrap: break-word; white-space: pre-wrap;">
<ins class="diff-chg">	@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
	@prefix rdf:     &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
	@prefix rdfs:    &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
	@prefix bp:      &lt;http://open-services.net/ns/basicProfile#&gt;.
</ins>
@prefix
xsd:
 
 &lt;http://www.w3.org/2001/XMLSchema#&gt;.
</pre>
</section>
</section>
<section id='conformance'>
</section>
<section>
<h1 id="bpr">
<del class="diff-old">4.
</del>
Basic
Profile
Resource
</h1>
<p>
Basic
Profile
Resources
(BPRs)
are
HTTP
resources
that
conform
to
the
simple
patterns
and
conventions
in
this
section.
HTTP
requests
to
access,
modify,
create
or
delete
BPRs
are
accepted
and
processed
by
BPR
servers.
Most
BPRs
are
domain-specific
resources
that
contain
data
for
an
entity
in
some
domain,
which
could
be
commercial,
governmental,
scientific,
religious,
or
other.
</p>
<p>
Some
of
the
rules
defined
in
this
document
provide
clarification
and
refinement
of
the
base
Linked
Data
rules
<del class="diff-old">[4Rules],
</del>
<ins class="diff-chg">[[LINKED-DATA]],
</ins>
others
address
additional
needs.
</p>
<p>
The
rules
for
Basic
Profile
Resources
address
basic
questions
such
as:
</p>
<ul>
<li>
What
resource
formats
should
be
used?
</li>
<li>
What
literal
value
types
should
be
used?
</li>
<li>
Are
there
some
typical
vocabularies
that
should
be
reused?
</li>
<li>
How
is
optimistic
collision
detection
handled
for
updates?
</li>
<li>
What
should
client
expectations
be
for
changes
to
linked-to
resources,
such
as
type
changes?
</li>
<li>
What
can
servers
do
to
ease
the
burden
of
constraints
for
resource
creation?
</li>
</ul>
<p>
The
following
sections
define
the
rules
and
guidelines
for
use
of
BPRs.
</p>
<section>
<h2 id="bpr-general">
<del class="diff-old">4.1
</del>
General
</h2>
<div id="bpr-4_1_1" class="rule">
4.1.1
BPR
servers
MUST
at
least
be
HTTP/1.1
conformant
servers
<del class="diff-old">[RFC2616].
</del>
<ins class="diff-chg">[[!HTTP11]].
</ins>
</div>
<div id="bpr-4_1_2" class="rule">
4.1.2
BPR
servers
MUST
provide
an
RDF
representation
for
BPRs.
The
subject
is
typically
the
BPR
itself.
</div>
<div id="bpr-4_1_3" class="rule">
4.1.3
BPR
servers
MAY
host
a
mixture
of
BPRs
and
non-BPRs.
For
example,
it
is
common
for
BPR
servers
to
need
to
host
binary
or
text
resources
that
do
not
have
useful
RDF
representations.
</div>
<div id="bpr-4_1_4" class="rule">
4.1.4
Clients
can
access
a
BPR
using
multiple
URLs,
for
example
when
DNS
aliasing
is
used.
A
BPR
server
MUST
respond
to
each
of
those
requests
using
a
single
consistent
URL,
a
canonical
URL,
for
the
BPR
which
may
be
found
in
the
response's
Location
header
and
potentially
also
in
the
representation
of
the
BPR.
Clients
SHOULD
use
that
canonical
URL
to
identify
the
BPR.
</div>
<div id="bpr-4_1_5" class="rule">
4.1.5
BPR
predicates
SHOULD
use
standard
vocabularies
such
as
Dublin
Core
<del class="diff-old">[Dublin
Core],
</del>
<ins class="diff-chg">[[!DC-TERMS]],
</ins>
RDF
<del class="diff-old">[RDF]
</del>
<ins class="diff-chg">[[!RDF-PRIMER]]
</ins>
and
RDF
Schema
<del class="diff-old">[RDF
Schema],
</del>
<ins class="diff-chg">[[!RDF-SCHEMA]],
</ins>
whenever
possible.
BPRs
SHOULD
reuse
existing
vocabularies
instead
of
creating
their
own
duplicate
vocabulary
terms.
</div>
<div id="bpr-4_1_6" class="rule">
4.1.6
BPR
predicates
MUST
use
well-known
RDF
vocabularies
as
defined
in
section
<a href="#bpr-prop">
4.8
Common
Properties
</a>
wherever
a
predicate’s
meaning
matches
one
of
them.
</div>
<div id="bpr-4_1_6_1" class="rule">
4.1.6.1
BPRs
MUST
use
the
predicate
<code>
rdf:type
</code>
to
represent
the
concept
of
type.
The
use
of
non-standard
type
predicates,
as
well
as
<code>
dcterms:type
</code>,
is
discouraged.
<del class="diff-old">[DC-RDF]
</del>
<ins class="diff-chg">[[!DC-RDF]]
</ins>
</div>
<div id="bpr-4_1_7" class="rule">
4.1.7
BPR
representations
SHOULD
have
at
least
one
<code>
rdf:type
</code>
set
explicitly.
 This
makes
the
representations
much
more
useful
to
client
applications
that
don’t
support
inferencing.
</div>
<div id="bpr-4_1_8" class="rule">
4.1.8
Predicate
URIs
used
in
BPR
representations
SHOULD
be
HTTP
URLs.
 These
predicate
URIs
MUST
identify
BPRs
whose
representations
are
retrievable.
BPR
servers
SHOULD
provide
an
RDF
Schema
<del class="diff-old">[RDF
Schema]
</del>
<ins class="diff-chg">[[!RDF-SCHEMA]]
</ins>
representation
of
these
predicates.
</div>
<div id="bpr-4_1_9" class="rule">
4.1.9
BPR
representations
MUST
use
only
the
following
standard
datatypes.
RDF
does
not
by
itself
define
datatypes
to
be
used
for
literal
property
values,
therefore
a
set
of
standard
datatypes
based
on
<del class="diff-old">[XSD
Datatypes]
</del>
<ins class="diff-chg">[[!XMLSCHEMA11-2]]
</ins>
and
<del class="diff-old">[RDF]
</del>
<ins class="diff-chg">[[!RDF-PRIMER]]
</ins>
are
to
be
used:
</div>
<table border="1" cellspacing="5" summary="Datatype to use with RDF literals">
<thead>
<tr>
<th>
URI
</th>
<th>
Description
</th>
</tr>
</thead>
<tbody>
<tr>
<td>
<code>
http://www.w3.org/2001/XMLSchema#boolean
</code>
</td>
<td>
Boolean
type
as
specified
by
XSD
Boolean
</td>
</tr>
<tr>
<td>
<code>
http://www.w3.org/2001/XMLSchema#date
</code>
</td>
<td>
Date
type
as
specified
by
XSD
date
</td>
</tr>
<tr>
<td>
<code>
http://www.w3.org/2001/XMLSchema#dateTime
</code>
</td>
<td>
Date
and
Time
type
as
specified
by
XSD
dateTime
</td>
</tr>
<tr>
<td>
<code>
http://www.w3.org/2001/XMLSchema#decimal
</code>
</td>
<td>
Decimal
number
type
as
specified
by
XSD
Decimal
</td>
</tr>
<tr>
<td>
<code>
http://www.w3.org/2001/XMLSchema#double
</code>
</td>
<td>
Double
floating-point
number
type
as
specified
by
XSD
Double
</td>
</tr>
<tr>
<td>
<code>
http://www.w3.org/2001/XMLSchema#float
</code>
</td>
<td>
Floating-point
number
type
as
specified
by
XSD
Float
</td>
</tr>
<tr>
<td>
<code>
http://www.w3.org/2001/XMLSchema#integer
</code>
</td>
<td>
Integer
number
type
as
specified
by
XSD
Integer
</td>
</tr>
<tr>
<td>
<code>
http://www.w3.org/2001/XMLSchema#string
</code>
</td>
<td>
String
type
as
specified
by
XSD
String
</td>
</tr>
<tr>
<td>
<code>
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteral
</code>
</td>
<td>
Literal
XML
value
as
specified
by
RDF
</td>
</tr>
</tbody>
</table>
<div id="bpr-4_1_10" class="rule">
4.1.10
BPRs
MUST
use
at
least
one
RDF
triple
to
represent
a
link
(relationship)
to
another
resource.
In
other
words,
having
the
source
resource’s
URI
as
the
subject
and
the
target
resource’s
URI
as
the
object
of
the
triple
represent
the
link
(relationship)
is
enough
and
does
not
require
the
creation
of
an
intermediate
link
resource
to
describe
the
relationship.
</div>
<div id="bpr-4_1_11" class="rule">
4.1.11
BPR
servers
MAY
support
additional
standard
representations.
These
could
be
other
RDF
formats,
like
N3
or
NTriples,
but
non-RDF
formats
like
HTML
<del class="diff-old">and
</del>
<ins class="diff-chg">[[!HTML401]]and
</ins>
JSON
<ins class="diff-new">[[!RFC4627]]
</ins>
would
be
likely
be
common.
</div>
<div id="bpr-4_1_12" class="rule">
4.1.12
BPRs
MAY
be
created,
updated
and
deleted
using
methods
not
defined
in
this
document,
for
example
through
application-specific
means,
SPARQL
UPDATE,
etc.
<del class="diff-old">[SPARQL-UPDATE]
</del>
<ins class="diff-chg">[[!RDF-SPARQL-UPDATE]]
</ins>
</div>
<div id="bpr-4_1_13" class="rule">
4.1.13
BPR
server
responses
MUST
contain
accurate
response
<code>
ETag
</code>
header
values.
</div>
</section>
<section>
<h2 id="bpr-HTTP_GET">
<del class="diff-old">4.2
</del>
HTTP
GET
</h2>
<div id="bpr-4_2_1" class="rule">
4.2.1
BPR
servers
MUST
support
the
HTTP
GET
Method
for
BPRs.
</div>
<div id="bpr-4_2_2" class="rule">
4.2.2
BPR
servers
MUST
provide
an
<code>
application/rdf+xml
</code>
representation
of
the
requested
BPR.
</div>
<div id="bpr-4_2_3" class="rule">
4.2.3
BPR
servers
SHOULD
provide
a
<code>
text/turtle
</code>
representation
of
the
requested
BPR.
</div>
<div id="bpr-4_2_4" class="rule">
4.2.4
In
the
absence
of
special
knowledge
of
the
application
or
domain,
BPR
clients
MUST
assume
that
any
BPR
may
have
multiple
values
for
<code>
rdf:type
</code>.
</div>
<div id="bpr-4_2_5" class="rule">
4.2.5
In
the
absence
of
special
knowledge
of
the
application
or
domain,
BPR
clients
MUST
assume
that
the
<code>
rdf:type
</code>
values
of
a
given
BPR
may
change
over
time.
</div>
</section>
<section>
<h2 id="bpr-HTTP_POST">
<del class="diff-old">4.3
</del>
HTTP
POST
</h2>
<p>
There
are
no
additional
requirements
on
HTTP
POST
for
BPRs.
</p>
</section>
<section>
<h2 id="bpr-HTTP_PUT">
<del class="diff-old">4.4
</del>
HTTP
PUT
</h2>
<div id="bpr-4_4_1" class="rule">
4.4.1
If
HTTP
PUT
is
performed
on
an
existing
resource,
BPR
servers
MUST
replace
the
entire
persistent
state
of
the
identified
resource
with
the
entity
representation
in
the
body
of
the
request.
The
only
recognized
exception
are
the
properties
<code>
dcterms:modified
</code>
and
<code>
dcterms:creator
</code>
that
are
never
under
client
control
-
BPR
servers
MUST
ignore
any
values
of
these
properties
that
are
provided
by
the
client.
Any
BPR
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.
</div>
<div id="bpr-4_4_2" class="rule">
4.4.2
BPR
clients
SHOULD
use
the
HTTP
<code>
If-Match
</code>
header
and
HTTP
<code>
ETags
</code>
to
ensure
it
isn’t
modifying
a
resource
that
has
changed
since
the
client
last
retrieved
its
representation.
BPR
servers
SHOULD
require
the
HTTP
<code>
If-Match
</code>
header
and
HTTP
<code>
ETags
</code>
to
detect
collisions.
BPR
servers
MUST
respond
with
status
code
412
(Condition
Failed)
if
<code>
ETag
</code>
s
fail
to
match
if
there
are
no
other
errors
with
the
request.
<del class="diff-old">[RFC2616]
</del>
<ins class="diff-chg">[[!HTTP11]]
</ins>
</div>
<div id="bpr-4_4_3" class="rule">
4.4.3
BPR
clients
SHOULD
always
assume
that
the
set
of
predicates
for
a
resource
of
a
particular
type
at
an
arbitrary
server
is
open
in
the
sense
that
different
resources
of
the
same
type
may
not
all
have
the
same
set
of
predicates
in
its
triples,
and
the
set
of
predicates
that
are
used
in
the
state
of
a
resource
is
not
limited
to
any
pre-defined
set.
</div>
<div id="bpr-4_4_4" class="rule">
4.4.4
BPR
clients
SHOULD
assume
that
a
BPR
server
could
discard
triples
whose
predicates
the
server
does
not
recognize
or
otherwise
chooses
not
to
persist.
In
other
words,
BPR
servers
MAY
restrict
themselves
to
a
known
set
of
predicates,
but
BPR
clients
MUST
NOT
restrict
themselves
to
a
known
set
of
predicates
when
their
intent
is
to
perform
a
later
HTTP
PUT
to
update
the
resource.
</div>
<div id="bpr-4_4_5" class="rule">
4.4.5
A
BPR
client
MUST
preserve
all
triples
retrieved
using
HTTP
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
<del class="diff-old">[RFC5789].
</del>
<ins class="diff-chg">[[RFC5789]].
</ins>
</div>
<div id="bpr-4_4_6" class="rule">
4.4.6
BPR
servers
MAY
choose
to
allow
the
creation
of
new
resources
using
HTTP
PUT.
</div>
<div id="bpr-4_4_7" class="rule">
4.4.7
BPR
servers
SHOULD
allow
clients
to
update
resources
without
requiring
detailed
knowledge
of
server-specific
constraints.
 It
is
common
for
BPR
servers
to
put
restrictions
on
representations

for
example,
the
range
of
<code>
rdf:type
</code>,
datatypes
of
predicates
and
number
of
occurrences
of
predicates
in
triples,
but
servers
SHOULD
minimize
those
restrictions.
 In
other
words,
BPR
servers
need
to
enable
simple
modification
of
BPRs.
Enforcement
of
more
complex
constraints
will
greatly
restrict
the
types
of
clients
that
can
modify
resources.
For
some
server
applications,
excessive
constraints
on
modification
of
resources
may
be
required.
</div>
</section>
<section>
<h2 id="bpr-HTTP_DELETE">
<del class="diff-old">4.5
</del>
HTTP
DELETE
</h2>
<div id="bpr-4_5_1" class="rule">
4.5.1
BPR
servers
MUST
remove
the
resource
identified
by
the
Request-URI.
After
a
successful
HTTP
DELETE,
a
subsequent
HTTP
GET
on
the
same
Request-URI
MUST
result
in
a
404
(Not
found)
or
410
(Gone)
status
code,
until
another
resource
is
created
or
associated
with
the
same
Request-URI.
</div>
<div id="bpr-4_5_2" class="rule">
4.5.2
BPR
servers
MAY
alter
the
state
of
other
resources
as
a
result
of
an
HTTP
DELETE
request.
For
example,
it
is
acceptable
for
the
server
to
remove
triples
from
other
resources
whose
subject
or
object
is
the
deleted
resource.
It
is
also
acceptable
and
common
for
BPR
servers
to
not
do
this

behavior
is
server
application
specific.
</div>
</section>
<section>
<h2 id="bpr-HTTP_HEAD">
<del class="diff-old">4.6
</del>
HTTP
HEAD
</h2>
<div id="bpr-4_6_1" class="rule">
4.6.1
BPR
servers
MUST
support
the
HTTP
HEAD
method.
</div>
<div id="bpr-4_6_2" class="rule">
4.6.2
BPR
servers
MUST
indicate
their
support
for
HTTP
Methods
by
responding
to
a
HTTP
HEAD
request
on
the
BPR’s
URL
with
the
HTTP
Method
tokens
in
the
HTTP
response
header

<code>
Allow
</code>
”.
</div>
</section>
<section>
<h2 id="bpr-HTTP_PATCH">
<del class="diff-old">4.7
</del>
HTTP
PATCH
</h2>
<div id="bpr-4_7_1" class="rule">
4.7.1
BPR
servers
MAY
implement
HTTP
PATCH
to
allow
modifications,
especially
partial
replacement,
of
their
resources.
<del class="diff-old">[RFC5789]
</del>
<ins class="diff-chg">[[!RFC5789]]
</ins>
No
minimal
set
of
patch
document
formats
is
mandated
by
this
document.
</div>
<div id="bpr-4_7_2" class="rule">
4.7.2
BPR
servers
SHOULD
allow
clients
to
update
resources
without
requiring
detailed
knowledge
of
server-specific
constraints.
 It
is
common
for
BPR
servers
to
put
restrictions
on
representations

for
example,
the
range
of
<code>
rdf:type
</code>,
datatypes
of
predicates
and
number
of
occurrences
of
predicates
in
triples

but
server
enforcement
of
detailed,
domain-specific
constraints
will
greatly
restrict
the
types
of
clients
who
can
update
resources.
</div>
</section>
<section>
<h2 id="bpr-prop">
<del class="diff-old">4.8
</del>
Common
Properties
</h2>
<p>
This
section
summarizes
some
well-known
RDF
vocabularies
that
MUST
be
used
in
Basic
Profile
Resources
wherever
a
resource
needs
to
use
a
predicate
whose
meaning
matches
one
of
these.
For
example,
if
a
BP
resource
has
a
<em>
description
</em>,
and
the
application
semantic
of
that
<em>
description
</em>
is
compatible
with
<code>
dcterms:description
</code>,
then
<code>
dcterms:description
</code>
MUST
be
used.
If
needed,
additional
application-specific
predicates
MAY
be
used.
A
specification
for
a
domain
that
is
based
on
BP
may
require
one
or
more
of
these
properties
for
a
particular
resource
type.
The
Range
column
in
the
tables
below
identify
the
RECOMMENDED
<code>
rdfs:range
</code>
for
the
properties.
</p>
<div id="bpr-4_8_1" class="rule">
4.8.1
From
Dublin
Core
</div>
<p>
URI:
<code>
http://purl.org/dc/terms/
</code>
</p>
<table border="1" cellspacing="5" summary="Dublin Core properties recommended">
<tr>
<td>
Property
</td>
<td>
Range
</td>
<td>
Comment
</td>
</tr>
<tr>
<td>
<code>
dcterms:contributor
</code>
</td>
<td>
<code>
dcterms:Agent
</code>
</td>
<td>
</td>
</tr>
<tr>
<td>
<code>
dcterms:creator
</code>
</td>
<td>
<code>
dcterms:Agent
</code>
</td>
<td>
</td>
</tr>
<tr>
<td>
<code>
dcterms:created
</code>
</td>
<td>
<code>
xsd:dateTime
</code>
</td>
<td>
</td>
</tr>
<tr>
<td>
<code>
dcterms:description
</code>
</td>
<td>
<code>
rdf:XMLLiteral
</code>
</td>
<td>
Descriptive
text
about
the
resource
represented
as
rich
text
in
XHTML
format.
SHOULD
include
only
content
that
is
valid
and
suitable
inside
an
XHTML
<code>
&lt;div&gt;
</code>
element.
</td>
</tr>
<tr>
<td>
<code>
dcterms:identifier
</code>
</td>
<td>
<code>
rdfs:Literal
</code>
</td>
<td>
</td>
</tr>
<tr>
<td>
<code>
dcterms:modified
</code>
</td>
<td>
<code>
xsd:dateTime
</code>
</td>
<td>
</td>
</tr>
<tr>
<td>
<code>
dcterms:relation
</code>
</td>
<td>
<code>
rdfs:Resource
</code>
</td>
<td>
The
HTTP
URI
of
a
related
resource.
This
is
the
predicate
to
use
when
you
don't
know
what
else
to
use.
If
you
know
more
specifically
what
sort
of
relationship
it
is,
use
a
more
specific
predicate.
</td>
</tr>
<tr>
<td>
<code>
dcterms:subject
</code>
</td>
<td>
<code>
rdfs:Resource
</code>
</td>
<td>
</td>
</tr>
<tr>
<td>
<code>
dcterms:title
</code>
</td>
<td>
<code>
rdf:XMLLiteral
</code>
</td>
<td>
A
name
given
to
the
resource.
Represented
as
rich
text
in
XHTML
format.
SHOULD
include
only
content
that
is
valid
inside
an
XHTML
<code>
&lt;span&gt;
</code>
element.
</td>
</tr>
</table>
<p>
The
predicate
<code>
dcterms:type
</code>
SHOULD
NOT
be
used,
instead
use
<code>
rdf:type
</code>.
<del class="diff-old">[DC-RDF].
</del>
<ins class="diff-chg">[[!DC-RDF]].
</ins>
</p>
<div id="bpr-4_8_2" class="rule">
4.8.2
From
RDF
</div>
<p>
URI:
<code>
http://www.w3.org/1999/02/22-rdf-syntax-ns#
</code>
</p>
<table border="1" cellspacing="5" summary="RDF properties recommended">
<tr>
<td>
Property
</td>
<td>
Range
</td>
<td>
Comment
</td>
</tr>
<tr>
<td>
<code>
rdf:type
</code>
</td>
<td>
<code>
rdfs:Class
</code>
</td>
<td>
<del class="diff-old">he
</del>
<ins class="diff-chg">The
</ins>
type
or
types
of
the
resource
</td>
</tr>
</table>
<div id="bpr-4_8_3" class="rule">
4.8.3 From
RDF
Schema
</div>
<p>
URI:
<code>
http://www.w3.org/2000/01/rdf-schema#
</code>
</p>
<table border="1" cellspacing="5" summary="RDF Schema properties recommended">
<tr>
<td>
Property
</td>
<td>
Range
</td>
<td>
Comment
</td>
</tr>
<tr>
<td>
<code>
rdfs:member
</code>
</td>
<td>
<code>
rdfs:Resource
</code>
</td>
<td>
</td>
</tr>
<tr>
<td>
<code>
rdfs:label
</code>
</td>
<td>
<code>
rdfs:Resource
</code>
</td>
<td>
Only
use
this
in
vocabulary
documents,
to
define
the
name
of
the
vocabulary
term.
</td>
</tr>
</table>
</section>
</section>
<section>
<h1 id="bpc">
<del class="diff-old">5.
</del>
Basic
Profile
Container
</h1>
<section class="informative">
<h2 id="bpc-informative">
<del class="diff-old">5.1
</del>
Informative
</h2>
<p>
Many
HTTP
applications
and
sites
have
organizing
concepts
that
partition
the
overall
space
of
resources
into
smaller
containers.
Blog
posts
are
grouped
into
blogs,
wiki
pages
are
grouped
into
wikis,
and
products
are
grouped
into
catalogs.
Each
resource
created
in
the
application
or
site
is
created
within
an
instance
of
one
of
these
container-like
entities,
and
users
can
list
the
existing
artifacts
within
one.
Containers
answer
some
basic
questions,
which
are:
</p>
<ol>
<li>
To
which
URLs
can
I
POST
to
create
new
resources?
</li>
<li>
Where
can
I
GET
a
list
of
existing
resources?
</li>
<li>
How
is
the
order
of
the
container
entries
expressed?
</li>
<li>
How
do
I
get
information
about
the
members
along
with
the
container?
</li>
<li>
How
do
I
GET
the
entries
of
a
large
container
broken
up
into
pages?
</li>
<li>
How
can
I
ensure
the
resource
data
is
easy
to
query?
</li>
</ol>
<p>
This
document
defines
the
representation
and
behavior
of
containers
that
address
these
issues.
The
set
of
members
of
a
container
is
defined
by
a
set
of
triples
in
its
representation
(and
state)
called
the
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
BPC
resource
itself,
but
it
does
not
have
to
be.
The
membership
predicate
is
also
variable
and
will
often
be
a
predicate
from
the
server
application
vocabulary
or
the
<code>
rdfs:member
</code>
predicate.
</p>
<p>
This
document
includes
a
set
of
guidelines
for
using
POST
to
create
new
resources
and
add
them
to
the
list
of
members
of
a
container.
This
document
also
explains
how
to
include
information
about
each
member
in
the
container’s
own
representation
and
how
to
paginate
the
container
representation
if
it
gets
too
big.
</p>
<p>
The
following
illustrates
a
very
simple
container
with
only
three
members
and
some
information
about
the
container
(the
fact
that
it
is
a
container
and
a
brief
title):
</p>
<del class="diff-old"># The following is the representation of
</del>
<pre class="example"># The following is the representation of
#    http://example.org/container1
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
@prefix bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
&lt;http://example.org/container1&gt;
   a bp:Container;
   dcterms:title "A very simple container";
   rdfs:member
      &lt;http://example.org/container1/member1&gt;,
      &lt;http://example.org/container1/member2&gt;,
&lt;http://example.org/container1/member3&gt;.
</pre>
<p>
This
example
is
very
straightforward
-
the
membership
predicate
is
<code>
rdfs:member
</code>
and
the
membership
subject
is
the
container
itself.
A
POST
to
this
container
will
create
a
new
resource
and
add
it
to
the
list
of
members
by
adding
a
new
membership
triple
to
the
container.
</p>
<p>
Sometimes
it
is
useful
to
use
a
subject
other
than
the
container
itself
as
the
membership
subject
and
to
use
a
predicate
other
than
<code>
rdfs:member
</code>
as
the
membership
predicate,
as
illustrated
below.
</p>
<pre class="example">
# The following is the representation of
#   http://example.org/netWorth/nw1/assetContainer
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
@prefix bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer&gt;
   a bp:Container;
   bp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   bp:membershipPredicate o:asset.
&lt;http://example.org/netWorth/nw1&gt;
   a o:NetWorth;
   o:asset
      &lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;,
&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;.
</pre>
<p>
The
essential
structure
of
the
container
is
the
same,
but
in
this
example,
the
membership
subject
is
not
the
container
itself

it
is
a
separate
net
worth
resource.
The
membership
predicate
is
<code>
o:asset
</code>

a
predicate
from
the
domain
model.
A
POST
to
this
container
will
create
a
new
asset
and
add
it
to
the
list
of
members
by
adding
a
new
membership
triple
to
the
container.
You
might
wonder
why
we
didn’t
just
make
<code>
http://example.org/netWorth/nw1
</code>
a
container
and
POST
the
new
asset
directly
there.
That
would
be
a
fine
design
if
<code>
http://example.org/netWorth/nw1
</code>
had
only
assets,
but
if
it
has
separate
predicates
for
assets
and
liabilities,
that
design
will
not
work
because
it
is
unspecified
to
which
predicate
the
POST
should
add
a
membership
triple.
Having
separate
<code>
http://example.org/netWorth/nw1/assetContainer
</code>
and
<code>
http://example.org/netWorth/nw1/liabilityContainer
</code>
container
resources
allows
both
assets
and
liabilities
to
be
created.
</p>
<p>
In
this
example,
clients
cannot
simply
guess
which
resource
is
the
membership
subject
and
which
predicate
is
the
membership
predicate,
so
the
example
includes
this
information
in
triples
whose
subject
is
the
BPC
resource
itself.
</p>
<div id="bpc-member_data" class="rule">
5.1.1
Container
Member
Information
</div>
<em>
This
section
is
<del class="diff-old">informative
</del>
<ins class="diff-chg">non-normative
</ins>
</em>
<p>
In
many

perhaps
most

applications
involving
containers,
it
is
desirable
for
the
client
to
be
able
to
get
information
about
each
container
member
without
having
to
do
a
GET
on
each
one.
BPC
allows
servers
to
include
this
information
directly
in
the
representation
of
the
container.
The
server
decides
the
amount
of
data
about
each
member
that
is
provided.
Some
common
strategies
include
providing
a
fixed
number
of
standard
properties,
or
providing
the
entire
RDF
representation
of
each
member
resource,
or
providing
nothing.
The
server
application
domain
and
its
use-cases
will
determine
how
much
information
is
required.
</p>
<p>
Continuing
on
from
the
net
worth
example,
there
will
be
additional
triples
for
the
member
resources
(assets)
in
the
representation:
</p>
<del class="diff-old"># The following is the representation of
</del>
<pre class="example"># The following is the representation of
#	 http://example.org/netWorth/nw1/assetContainer
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix rdfs:    &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
@prefix bp:      &lt;http://open-services.net/ns/basicProfile#&gt;.
@prefix o:       &lt;http://example.org/ontology/&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer&gt;
   a bp:Container;
   dcterms:title "The assets of JohnZSmith";
   bp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   bp:membershipPredicate o:asset.
&lt;http://example.org/netWorth/nw1&gt;
   a o:NetWorth;
   o:asset
      &lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;,
      &lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;,
      &lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;
   a o:Stock;
   o:value 10000.
&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;
   a o:Bond;
   o:value 20000.
&lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;
   a o:RealEstateHolding;
 
 o:value
300000.
</pre>
<div id="bpc-get_non-member_props" class="rule">
5.1.2 Retrieving
Only
Non-member
Properties
</div>
<em>
This
section
is
<del class="diff-old">informative
</del>
<ins class="diff-chg">non-normative
</ins>
</em>
<p>
The
representation
of
a
container
that
has
many
members
will
be
large.
There
are
several
important
cases
where
clients
need
to
access
only
the
non-member
properties
of
the
container.
Since
retrieving
the
whole
container
representation
to
get
this
information
may
be
onerous
for
clients
and
cause
unnecessary
overhead
on
servers,
it
is
desired
to
define
a
way
to
retrieve
only
the
non-member
property
values.
Defining
for
each
BPC
a
corresponding
resource,
called
the
“non-member
resource”,
whose
state
is
a
subset
of
the
state
of
the
container,
does
this.
</p>
<p>
The
example
listed
here
only
show
a
simple
case
where
only
a
few
simple
non-member
properties
are
retrieved.
In
real
world
situations
more
complex
cases
are
likely,
such
as
those
that
add
other
predicates
to
containers,
for
example
providing
validation
information
and
associating
SPARQL
endpoints.
<ins class="diff-new">[[RDF-SPARQL-QUERY]]
</ins>
</p>
<p>
Here
is
an
example
requesting
the
non-member
properties
of
a
container
identified
by
the
URL
<code>
http://example.org/container1
</code>
and
adding
the
query
string
<code>
?non-member-properties
</code>
:
</p>
<p>
Request:
</p>
<del class="diff-old">GET /container1?non-member-properties HTTP/1.1
</del>
<pre class="example">GET /container1?non-member-properties HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8
</pre>
<p>
Response:
</p>
<del class="diff-old">HTTP/1.1 200 OK
</del>
<pre class="example">HTTP/1.1 200 OK
Content-Type: text/turtle; chartset=UTF-8
ETag: "_87e52ce291112"
Content-Length: 325
@prefix rdfs: &lt;http://www.w3.org/2000/01/rdf-schema#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
&lt;http://example.org/container1&gt;
   a bp:Container;
   dcterms:title "A Basic Profile Container of Acme Resources";
   bp:membershipPredicate rdfs:member;
dcterms:publisher
&lt;http://acme.com/&gt;.
</pre>
<div id="bpc-paging" class="rule">
5.1.3
Paging
</div>
<em>
This
section
is
<del class="diff-old">informative
</del>
<ins class="diff-chg">non-normative
</ins>
</em>
<p>
It
sometimes
happens
that
a
container
is
too
large
to
reasonably
transmit
its
representation
in
a
single
HTTP
response.
This
will
be
especially
true
if
the
container
representation
includes
many
triples
from
the
representations
of
its
members.
A
client
may
anticipate
that
a
container
will
be
too
large
-
for
example,
a
client
tool
that
accesses
defects
may
assume
that
an
individual
defect
will
usually
be
of
sufficiently
constrained
size
that
it
makes
sense
to
request
all
of
it
at
once,
but
that
the
container
of
all
the
defects
ever
created
will
typically
be
too
big.
Alternatively,
a
server
may
recognize
that
a
container
that
has
been
requested
is
too
big
to
return
in
a
single
message.
</p>
<p>
To
address
this
problem,
BPCs
may
support
a
technique
called
Paging.
 Paging
can
be
achieved
with
a
simple
RDF
pattern.
For
each
container
resource,
<code>
&lt;containerURL&gt;
</code>,
we
define
a
new
resource
<code>
&lt;containerURL&gt;?firstPage
</code>.
The
triples
in
the
representation
of
<code>
&lt;containerURL&gt;?firstPage
</code>
are
a
subset
of
the
triples
in
<code>
&lt;containerURL&gt;
</code>
-
same
subject,
predicate
and
object.
</p>
<p>
BPC
servers
may
respond
to
requests
for
a
container
by
redirecting
the
client
to
the
first
page
resource

using
a
303
“See
Other”
redirect
to
the
actual
URL
for
the
page
resource.
</p>
<p>
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
<code>
http://example.org/netWorth/nw1/assetContainer?firstPage
</code>:
</p>
<del class="diff-old"># The following is the representation of
</del>
<pre class="example"># The following is the representation of
#    http://example.org/netWorth/nw1/assetContainer?firstPage
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer&gt;
   a bp:Container;
   dcterms:title "The assets of JohnZSmith";
   bp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   bp:membershipPredicate o:asset.
&lt;http://example.org/netWorth/nw1/assetContainer?firstPage&gt;
   a bp:Page;
   bp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer&gt;;
   bp:nextPage &lt;http://example.org/netWorth/nw1/assetContainer?p=2&gt;.
 
&lt;http://example.org/netWorth/nw1&gt;
    a o:NetWorth;
	o:asset
	&lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;,
	&lt;http://example.org/netWorth/nw1/assetContainer/a4&gt;,
	&lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;,
	&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;
   a o:Stock;
   o:value 100.00.
&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;
   a o:Cash;
   o:value 50.00.
#
server
initially
supplied
no
data
for
a3
and
a4
in
this
response
</pre>
<p>
The
following
example
is
the
result
of
retrieving
the
representation
for
the
next
page:
</p>
<del class="diff-old"># The following is the representation of
</del>
<pre class="example"># The following is the representation of
#  http://example.org/netWorth/nw1/assetContainer?p=2
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer&gt;
   a bp:Container;
   dcterms:title "The assets of JohnZSmith";
   bp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   bp:membershipPredicate o:asset.
&lt;http://example.org/netWorth/nw1/assetContainer?p=2&gt;
   a bp:Page;
   bp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer&gt;;
   bp:nextPage rdf:nil.
&lt;http://example.org/netWorth/nw1&gt;
   a o:NetWorth;
   o:asset 
      &lt;http://example.org/netWorth/nw1/assetContainer/a5&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/a5&gt;
   a o:Stock;
   dcterms:title "Big Co.";
o:value
200.02.
</pre>
<p>
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
<code>
rdf:nil
</code>
is
used
for
the
<code>
bp:nextPage
</code>
predicate
of
the
page
resource.
</p>
<p>
BPC
guarantees
that
any
and
all
the
triples
about
the
members
will
be
on
the
same
page
as
the
membership
triple
for
the
member.
</p>
<div id="bpc-ordering" class="rule">
5.1.4
Ordering
</div>
<em>
This
section
is
<del class="diff-old">informative
</del>
<ins class="diff-chg">non-normative
</ins>
</em>
<p>
There
are
many
cases
where
an
ordering
of
the
members
of
the
container
is
important.
BPC
does
not
provide
any
particular
support
for
server
ordering
of
members
in
containers,
because
any
client
can
order
the
members
in
any
way
it
chooses
based
on
the
value
of
any
available
property
of
the
members.
In
the
example
below,
the
value
of
the
<code>
o:value
</code>
predicate
is
present
for
each
member,
so
the
client
can
easily
order
the
members
according
to
the
value
of
that
property.
In
this
way,
BPC
avoids
the
use
of
RDF
constructs
like
Seq
and
List
for
expressing
order.
</p>
<p>
Order
only
becomes
important
for
BPC
servers
when
containers
are
paginated.
If
the
server
does
not
respect
ordering
when
constructing
pages,
the
client
is
forced
to
retrieve
all
pages
before
sorting
the
members,
which
would
defeat
the
purpose
of
pagination.
In
cases
where
ordering
is
important,
a
BPC
server
exposes
all
the
members
on
a
page
with
a
higher
sort
order
than
all
members
on
the
previous
page
and
lower
sort
order
than
all
the
members
on
the
next
page.
The
BPC
specification
provides
a
predicate
-
<code>
bp:containerSortPredicates
</code>
-
that
the
server
may
use
to
communicate
to
the
client
which
predicates
were
used
for
page
ordering.
Multiple
predicate
values
may
have
been
used
for
sorting,
so
the
value
of
this
predicate
is
an
ordered
list.
</p>
<p>
Here
is
an
example
container
described
previously,
with
representation
for
ordering
of
the
assets:
</p>
<del class="diff-old"># The following is the ordered representation of
</del>
<pre class="example"># The following is the ordered representation of
#   http://example.org/netWorth/nw1/assetContainer
@prefix rdf: &lt;http://www.w3.org/1999/02/22-rdf-syntax-ns#&gt;.
@prefix dcterms: &lt;http://purl.org/dc/terms/&gt;.
@prefix bp: &lt;http://open-services.net/ns/basicProfile#&gt;.
@prefix o: &lt;http://example.org/ontology/&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer&gt;
   a bp:Container;
   dcterms:title "The assets of JohnZSmith";
   bp:membershipSubject &lt;http://example.org/netWorth/nw1&gt;;
   bp:membershipPredicate o:asset.
&lt;http://example.org/netWorth/nw1/assetContainer?firstPage&gt;
   a bp:Page;
   bp:pageOf &lt;http://example.org/netWorth/nw1/assetContainer&gt;;
   bp:containerSortPredicates (o:value).
&lt;http://example.org/netWorth/nw1&gt;
   a o:NetWorth;
   o:asset
      &lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;,
      &lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;,
      &lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;.
&lt;http://example.org/netWorth/nw1/assetContainer/a1&gt;
   a o:Stock;
   o:value 100.00.
&lt;http://example.org/netWorth/nw1/assetContainer/a2&gt;
   a o:Cash;
   o:value 50.00.
&lt;http://example.org/netWorth/nw1/assetContainer/a3&gt;
   a o:RealEstateHolding;
 
 o:value
300000.
</pre>
<p>
As
you
can
see
by
the
addition
of
the
<code>
bp:containerSortPredicates
</code>
predicate,
the
<code>
o:value
</code>
predicate
is
used
to
define
the
ordering
of
the
results.
 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.
</p>
</section>
<section class="informative">
<h2 id="bpc-general">
<del class="diff-old">5.2
</del>
General
</h2>
<del class="diff-old">This
section
is
normative
</del>
<div id="bpc-5_2_1" class="rule">
5.2.1
BPC
servers
MUST
also
be
conformant
BPR
servers.
A
Basic
Profile
Container
is
a
resource
that
is
a
Basic
Profile
Resource.
</div>
<div id="bpc-5_2_2" class="rule">
5.2.2
The
same
resource
MAY
be
a
member
of
multiple
BPCs.
This
happens
commonly
if
one
container
is
a
view
onto
a
larger
container.
</div>
<div id="bpc-5_2_3" class="rule">
5.2.3
The
representation
of
a
BPC
includes
information
about
which
resources
are
its
members.
The
set
of
members
of
a
container
is
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
BPC
resource
itself,
but
it
does
not
have
to
be.
The
membership
predicate
is
also
variable
and
will
often
be
a
predicate
from
the
server
application
vocabulary.
If
there
is
no
obvious
predicate
from
the
server
application
vocabulary
to
use,
BPC
servers
SHOULD
use
the
<code>
rdfs:member
</code>
predicate.
</div>
<div id="bpc-5_2_4" class="rule">
5.2.4
<del class="diff-old">When
the
container
subject
is
not
the
BPC
itself,
a
</del>
<ins class="diff-chg">A
</ins>
BPC
MUST
contain
one
triple
for
the
<code>
bp:membershipSubject
</code>
predicate
that
indicates
the
subject
of
the
membership
<del class="diff-old">triples.
5.2.5
When
the
</del>
<ins class="diff-chg">triples
when
</ins>
container
<del class="diff-old">predicate
</del>
<ins class="diff-chg">subject
</ins>
is
not
<del class="diff-old">rdfs:member
,
a
</del>
<ins class="diff-chg">the
BPC
itself.
</ins></div><div id="bpc-5_2_5" class="rule"><ins class="diff-chg">
5.2.5
A
</ins>
BPC
MUST
contain
one
triple
for
the
<code>
bp:membershipPredicate
</code>
predicate
that
indicates
the
predicate
of
the
membership
<del class="diff-old">triple.
</del>
<ins class="diff-chg">triple
when
the
container
predicate
is
not
</ins><code><ins class="diff-chg">
rdfs:member
</ins></code>.
</div>
<div id="bpc-5_2_6" class="rule">
5.2.6
The
representation
of
a
BPC
MAY
include
an
arbitrary
number
of
additional
triples
whose
subjects
are
the
members
of
the
container,
or
that
are
from
the
representations
of
the
members
(if
they
have
RDF
representations).
This
allows
a
BPC
server
to
provide
clients
with
information
about
the
members
without
the
client
having
to
do
a
GET
on
each
member
individually.
 See
section
<a href="#bpc-member_data">
5.1.1
Container
Member
Information
</a>
for
additional
details.
</div>
<div id="bpc-5_2_7" class="rule">
5.2.7
The
representation
of
a
BPC
MUST
have
<code>
rdf:type
</code>
of
<code>
bp:Container
</code>,
but
it
MAY
have
additional
<code>
rdf:type
</code>
s.
</div>
<div id="bpc-5_2_8" class="rule">
5.2.8
BPCs
SHOULD
NOT
use
RDF
container
types
<code>
rdf:Bag
</code>,
<code>
rdf:Seq
</code>
and
<code>
rdf:List
</code>.
</div>
</section>
<section>
<h2 id="bpc-HTTP_GET">
<del class="diff-old">5.3
</del>
HTTP
GET
</h2>
<div id="bpc-5_3_1" class="rule">
5.3.1
The
representation
of
a
BPC
MUST
contain
a
set
of
triples
with
a
consistent
subject
and
predicate
whose
objects
indicate
members
of
the
container.
The
subject
of
the
triples
MAY
be
the
container
itself
or
MAY
be
another
resource
(as
in
the
example
above).
 See
also
<a href="#bpc-5_2_3">
5.2.3
</a>.
</div>
<div id="bpc-5_3_2" class="rule">
5.3.2
BPC
servers
SHOULD
support
requests
for
information
about
a
known
BPC
without
retrieving
a
full
representation
including
all
of
its
members,
by
the
existence
of
the
token
"
<code>
non-member-properties
</code>
"
on
the
query
component
of
the
BPC
URL.
 For
example,
if
there
is
a
BPC
URL
<code>
&lt;containerURL&gt;,
</code>
the
URL
to
request
the
non-membership
properties
would
be
<code>
&lt;containerURL&gt;?non-member-properties
</code>.
 See
section
<a href="#bpc-get_non_member_props">
5.1.2
Retrieving
Non-member
Properties
</a>
for
additional
details.
A
BPC
server
that
does
not
support
a
request
to
retrieve
non-member
resource
properties
via
a
Request-URI
of

<code>
&lt;containerURL&gt;?non-member-properties
</code>
”,
MUST
return
a
HTTP
status
code
404
(Not
Found).
</div>
<div id="bpc-5_3_3" class="rule">
5.3.3
A
BPC
server
that
does
not
support
a
request
to
retrieve
the
first
page
resource
representation
via
a
known
BPC
as

<code>
&lt;containerURL&gt;
</code>
”,
the
Request-URI
of

<code>
&lt;containerURL&gt;?firstPage
</code>
”,
MUST
return
a
HTTP
status
code
404
(Not
Found).
</div>
<div id="bpc-5_3_4" class="rule">
5.3.4
BPC
servers
SHOULD
support
requests
for
splitting
large
BPCs
into
pages
indicated
by
a
client
supplying
the
token

<code>
firstPage
</code>

on
the
query
component
of
the
BPC
URL.
For
example,
if
there
is
a
BPC
URL
<code>
&lt;containerURL&gt;
</code>,
the
URL
to
request
the
first
page
would
be
<code>
&lt;containerURL&gt;?firstPage
</code>.
The
representation
for
any
page,
including
the
first,
will
include
the
URL
for
the
next
page. See
section
<a href="#bpc-paging">
5.1.3
titled
“Paging”
</a>
for
additional
details.
</div>
<div id="bpc-5_3_5" class="rule">
5.3.5
BPC
servers
MAY
split
the
response
representation
of
a
BPC
regardless
of
what
the
client
requested
(such
as
when
a
client
omits
a

<code>
firstPage
</code>

query
component
of
a
request
URL).
This
is
also
known
as
server-initiated
paging.
See
section
<a href="#bpc-paging">
5.1.3
Paging
</a>
for
additional
details.
</div>
<div id="bpc-5_3_5_1" class="rule">
5.3.5.1
BPC
servers
that
initiate
paging
SHOULD
respond
to
requests
for
a
BPC
by
redirecting
the
client
to
the
page
resource

using
a
303
“See
Other”
redirect
to
the
actual
URL
for
the
page
resource.
</div>
<div id="bpc-5_3_6" class="rule">
5.3.6
BPC
servers
that
support
paging
MUST
include
in
the
page
representation
a
representation
for
the
BPC,
such
that:
</div>
<div id="bpc-5_3_6_1" class="rule">
5.3.6.1
The
page
resource
representation
SHOULD
have
one
triple
to
indicate
its
type,
whose
subject
is
the
URL
of
the
page,
whose
predicate
is
<code>
rdf:type
</code>
and
object
is
<code>
bp:Page;
</code>
it
also
SHOULD
have
1
triple
to
indicate
the
container
it
is
paging,
whose
 subject
is
the
URL
of
the
page,
predicate
is
<code>
bp:pageOf,
</code>
and
object
is
the
URL
of
the
BPC.
</div>
<div id="bpc-5_3_6_2" class="rule">
5.3.6.2
The
page
resource
representation
MUST
have
one
triple
with
the
subject
of
the
page,
predicate
of
<code>
bp:nextPage
</code>
and
object
being
the
URL
for
the
subsequent
page.
</div>
<div id="bpc-5_3_6_3" class="rule">
5.3.6.3
The
last
page
resource
representation
MUST
have
one
triple
with
the
subject
of
the
last
page,
predicate
of
<code>
bp:nextPage
</code>
and
object
being
<code>
rdf:nil
</code>.
</div>
<div id="bpc-5_3_7" class="rule">
5.3.7
BPC
servers
MAY
represent
the
members
of
a
paged
BPC
in
a
sequential
order.
 The
order
MUST
be
specified
using
the
<code>
bp:containerSortPredicates
</code>
predicate
whose
subject
is
that
of
the
page
and
object
is
a
list
of
BPC
ordinal
predicates.
 The
default
ordering
is
ascending.
The
only
ordinal
predicate
literal
data
types
supported
are
those
as
defined
by
SPARQL
SELECT’s
ORDER
BY
clause
<del class="diff-old">[SPARQL].
</del>
<ins class="diff-chg">[[!RDF-SPARQL-QUERY]].
</ins>
</div>
<div id="bpc-5_3_7_1" class="rule">
5.3.7.1
The
object
of
<code>
bp:containerSortPredicates
</code>
’,
the
predicate
used
to
indicate
ordering,
MUST NOT
change
between
subsequent
pages.
If
it
does,
ordering
among
members
of
a
container
across
pages
is
undefined.
See
section
<a href="#bpc-ordering">
5.1.4
Ordering
</a>
for
additional
details.
</div>
<p>
The
Basic
Profile
does
not
define
how
clients
discover
BPCs.
</p>
</section>
<section>
<h2 id="bpc-HTTP_POST">
<del class="diff-old">5.4
</del>
HTTP
POST
</h2>
<div id="bpc-5_4_1" class="rule">
5.4.1
BPC
clients
SHOULD
create
resources
by
submitting
a
representation
as
the
entity
body
of
the
HTTP
POST
to
a
known
BPC.
BPC
servers
MUST
respond
with
status
code
201
(Created)
and
the
<code>
Location
</code>
header
set
to
the
new
resource’s
URL.
</div>
<div id="bpc-5_4_2" class="rule">
5.4.2
After
a
successful
HTTP
POST
request
to
a
BPC,
the
new
resource
MUST
appear
as
a
member
of
the
BPC
until
the
new
resource
is
deleted
or
removed
by
other
methods.
A
BPC
MAY
also
contain
resources
that
were
added
through
other
means
-
for
example
through
the
user
interface
of
the
site
that
implements
the
BPC.
</div>
<div id="bpc-5_4_3" class="rule">
5.4.3
BPC
servers
MAY
accept
an
HTTP
POST
of
non-RDF
representations
for
creation
of
any
kind
of
resource,
for
example
binary
resources.
</div>
<div id="bpc-5_4_4" class="rule">
5.4.4
For
servers
that
support
create,
BPC
servers
MUST
create
a
BPR
from
a
RDF
representation
in
the
request
entity
body.
</div>
<div id="bpc-5_4_5" class="rule">
5.4.5
BPC
servers
SHOULD
NOT
include
the
representation
of
the
created
resource
in
the
entity
body
of
a
201
(Created)
response.
In
other
words,
clients
should
not
expect
any
representation
in
the
response
entity
body
on
a
201
(Created)
response.
</div>
<div id="bpc-5_4_6" class="rule">
5.4.6
For
BPCs,
servers
MUST
accept
a
request
entity
body
with
a
content
type
of
<code>
application/rdf+xml
</code>.
</div>
<div id="bpc-5_4_7" class="rule">
5.4.7
For
BPCs,
BPR
servers
SHOULD
accept
a
request
with
an
entity
body
content
type
of
<code>
text/turtle
</code>.
</div>
<div id="bpc-5_4_8" class="rule">
5.4.8
For
RDF
representations,
BPC
servers
MUST
interpret
the
null
relative
URI
for
the
subject
of
triples
in
the
BPR
representation
in
the
request
entity
body
as
referring
to
the
entity
in
the
request
body.
Commonly,
that
entity
is
the
model
for
the
“to
be
created”
BPR,
so
triples
whose
subject
is
the
null
relative
URI
will
usually
result
in
triples
in
the
created
resource
whose
subject
is
the
created
resource.
 
</div>
<div id="bpc-5_4_9" class="rule">
5.4.9
BPC
servers
SHOULD
assign
the
subject
URI
for
the
resource
to
be
created
using
server
application
specific
rules.
</div>
<div id="bpc-5_4_10" class="rule">
5.4.10
BPC
servers
SHOULD
allow
clients
to
create
new
resources
without
requiring
detailed
knowledge
of
application-specific
constraints.
 Some
BPC
servers
put
restrictions
on
representations

for
example,
the
range
of
<code>
rdf:type
</code>,
datatypes
of
predicates
and
number
of
occurrences
of
predicates
in
triples
-
but
server
enforcement
of
detailed,
domain-specific
constraints
will
greatly
restrict
the
types
of
clients
that
can
create
resources
and
therefore
discouraged.
</div>
</section>
<section>
<h2 id="bpc-HTTP_PUT">
<del class="diff-old">5.5
</del>
HTTP
PUT
</h2>
<div id="bpc-5_5_1" class="rule">
5.5.1
BPC
servers
SHOULD
NOT
allow
HTTP
PUT
to
update
a
BPC’s
members
and
if
the
server
receives
such
a
request,
it
SHOULD
respond
with
a
409
(Conflict)
status
code.
</div>
<div id="bpc-5_5_2" class="rule">
5.5.2
BPC
servers
MAY
allow
updating
BPC
non-membership
properties
using
HTTP
PUT
on
<code>
&lt;containerURL&gt;?non-member-properties
</code>,
which
MAY
exclude
server
managed
properties
such
as
<code>
bp:membershipSubject
</code>
and
<code>
bp:membershipPredicate
</code>.
</div>
</section>
<section>
<h2 id="bpc-HTTP_DELETE">
5.6
HTTP
DELETE
</h2>
<div id="bpc-5_6_1" class="rule">
5.6.1
If
a
BPC
server
supports
deletion
of
the
BPC,
the
server
MAY
also
delete
the
resources
that
are
referenced
as
its
contents.
</div>
<div id="bpc-5_6_2" class="rule">
5.6.2
When
a
resource
that
is
contained
in
a
BPC
(for
example
referenced
by
a
membership
triple)
is
deleted,
the
server
MUST
also
remove
it
from
the
BPC
that
was
used
to
create
it
and
SHOULD
remove
it
from
any
other
containers
that
reference
it
that
the
server
manages
and
persists.
</div>
</section>
<section>
<h2 id="bpc-HTTP_HEAD">
<del class="diff-old">5.7
</del>
HTTP
HEAD
</h2>
<p>
There
are
no
additional
requirements
on
HTTP
HEAD.
</p>
</section>
<section>
<h2 id="bpc-HTTP_PATCH">
<del class="diff-old">5.8
</del>
HTTP
PATCH
</h2>
<div id="bpc-5_8_1" class="rule">
5.8.1
BPC
servers
are
RECOMMENDED
to
support
HTTP
PATCH
as
the
preferred
method
for
updating
BPC
non-membership
<del class="diff-old">properties.
6.
References
6.1
Normative
References
Dublin
Core
Dublin
Core
Metadata
Initiative
Terms
,
DCMI
Recommendation,
11
October
2010.
This
version
is
http://dublincore.org/documents/2010/10/11/dcmi-terms/.
 The
latest
version
is
http://dublincore.org/documents/dcmi-terms/.
RDF
</del>
<del class="diff-old">Resource
Description
Framework
(RDF):
Concepts
and
Abstract
Syntax
,
Klyne
G.,
Carroll
J.
(Editors),
W3C
Recommendation,
10
February
2004.
This
version
is
http://www.w3.org/TR/2004/REC-rdf-primer-20040210/.
The
latest
version
is
http://www.w3.org/TR/rdf-concepts/.
RFC2119
RFC
2119:
Key
words
for
use
in
RFCs
to
Indicate
Requirement
Levels
,
Scott
Bradner,
1997.
(See
http://www.ietf.org/rfc/rfc2119.txt)
RFC2616
Hypertext
Transfer
Protocol
-
HTTP/1.1
.
J.
Gettys,
J.
Mogul,
H.
Frystyk,
L.
Masinter,
P.
Leach,
T.
Berners-Lee,
June
1999.
Available
at
http://www.ietf.org/rfc/rfc2616.txt.
RFC3986
Uniform
Resource
Identifier
(URI):
Generic
Syntax
,
Berners-Lee,
Fielding,
Masinter,
January
2005.
RFC5789
PATCH
Method
for
HTTP
,
L
Dusseault,
J.
Snell,
March
2010.
Available
at
http://tools.ietf.org/html/rfc5789
RFC3987
Internationalized
Resource
Identifiers
(IRIs)
,
Duerst,
Suignard,
January
2005.
SPARQL-UPDATE
SPARQL
1.1
Update
,
S.
Schenk,
P.
Gearon,
Editor,
W3C
Working
Draft,
26
January
2010,
http://www.w3.org/TR/2010/WD-sparql11-update-20100126/.
Latest
version
available
at
http://www.w3.org/TR/sparql11-update/.
6.2
Informative
References
4Rules
Linked
Data
Design
Issues
,
Tim
Berners-Lee,
27
July
2006,
http://www.w3.org/DesignIssues/LinkedData.html
DC-RDF
Expressing
Dublin
Core
metadata
using
the
Resource
Description
Framework
(RDF)
,
M.
Nilsson
and
all,
14
January
2008,
http://dublincore.org/documents/2008/01/14/dc-rdf/.
Latest
available
at:
http://dublincore.org/documents/dc-rdf/.
HTML
4.01
HTML
4.01
Specification
,
D.
Raggett,
A.
Le
Hors,
and
I.
Jacobs,
1999.
(See
http://www.w3.org/TR/html4/)
IANA
Internet
Assigned
Numbers
Authority
(IANA)
MIME
Media
Types,
http://www.iana.org/assignments/media-types/index.html
LinkedData
Linked
Data
at
W3C
,
http://www.w3.org/standards/semanticweb/data
OSLC
Open
Services
for
Lifecycle
Collaboration
(OSLC)
,
http://open-services.net
RDF
Primer
Resource
Description
Framework
(RDF):
Concepts
and
Abstract
Syntax
,
Klyne
G.,
Carroll
J.
(Editors),
W3C
Recommendation,
10
February
2004.
This
version
is
http://www.w3.org/TR/2004/REC-rdf-primer-20040210/.
The
latest
version
is
http://www.w3.org/TR/rdf-primer/.
RDF-MT
RDF
Semantics
,
P.
Hayes,
Editor,
W3C
Recommendation,
10
February
2004,
http://www.w3.org/TR/2004/REC-rdf-mt-20040210/.
&lt;a href="h 
</del>