W3C W3C Member Submission

Linked Data Basic Profile 1.0

W3C Member Submission 20 March 2012

This Version:
http://www.w3.org/Submission/2012/SUBM-bpld-20120320/
Latest Version:
http://www.w3.org/Submission/bpld/
Authors:
Martin Nally, IBM Corporation
Steve Speicher, IBM Corporation
John Arwe, IBM Corporation
Arnaud Le Hors, IBM Corporation

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.

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:

  1. Linked Data Basic Profile 1.0 (this document)
  2. 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

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 [4Rules]

1. Use URIs as names for things

2. Use HTTP URIs so that people can look up those names.

3. When someone looks up a URI, provide useful information, using the standards (RDF*, SPARQL)

4. Include links to other URIs. so that they can discover more things.

The best practices and anti-patterns covered in this document are:

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.

2. Terminology

Terminology is based on W3C's Architecture of the World Wide Web [WEBARCH] and Hyper-text Transfer Protocol [RFC2616] 

Link
A relationship between two resources when one resource (representation) refers to the other resource by means of a URI. [WEBARCH]
Linked Data
As defined by Tim Berners-Lee. [4Rules]
Profile
A specification that defines the needed components from other specifications as well as providing additional clarifications as needed.
Basic Profile Resource (BPR)
HTTP resource that conforms to the simple lifecycle patterns and conventions in this document.
Basic Profile Container (BPC)
BPR resource that also conforms to additional patterns and conventions in this document for managing membership.
Client
A program that establishes connections for the purpose of sending requests. [RFC2616]
Server
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. [RFC2616]

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.

3.1 Conventions used in this Document

Sample resource representations are provided in text/turtle format [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 bp:      <http://open-services.net/ns/basicProfile#>.
@prefix xsd:     <http://www.w3.org/2001/XMLSchema#>.

4. Basic Profile Resource

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.

Some of the rules defined in this document provide clarification and refinement of the base Linked Data rules [4Rules], others address additional needs.

The rules for Basic Profile Resources address basic questions such as:

The following sections define the rules and guidelines for use of BPRs.

4.1 General

4.1.1 BPR servers MUST at least be HTTP/1.1 conformant servers [RFC2616].
4.1.2 BPR servers MUST provide an RDF representation for BPRs. The subject is typically the BPR itself.
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.
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.
4.1.5 BPR predicates SHOULD use standard vocabularies such as Dublin Core [Dublin Core], RDF [RDF] and RDF Schema [RDF Schema], whenever possible. BPR SHOULD reuse existing vocabularies instead of creating their own duplicate vocabulary terms.
4.1.6 BPR predicates MUST use well-known RDF vocabularies as defined in section 5.8 Common Properties wherever a predicate’s meaning matches one of them.
4.1.6.1 BPRs MUST use the predicate rdf:type to represent the concept of type. The use of non-standard type predicates, as well as dcterms:type, is discouraged. [DC-RDF]
4.1.7 BPR representations SHOULD have at least one rdf:type set explicitly.  This makes the representations much more useful to client applications that don’t support inferencing.
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 a RDF Schema [RDF Schema] representation of these predicates.
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 [XSD Datatypes] and [RDF] are to be used:
URIDescription
http://www.w3.org/2001/XMLSchema#booleanBoolean type as specified by XSD Boolean
http://www.w3.org/2001/XMLSchema#dateDate type as specified by XSD date
http://www.w3.org/2001/XMLSchema#dateTimeDate and Time type as specified by XSD dateTime
http://www.w3.org/2001/XMLSchema#dateDate type as specified by XSD date
http://www.w3.org/2001/XMLSchema#decimalDecimal number type as specified by XSD Decimal
http://www.w3.org/2001/XMLSchema#doubleDouble floating-point number type as specified by XSD Double
http://www.w3.org/2001/XMLSchema#floatFloating-point number type as specified by XSD Float
http://www.w3.org/2001/XMLSchema#integerInteger number type as specified by XSD Integer
http://www.w3.org/2001/XMLSchema#stringString type as specified by XSD String
http://www.w3.org/1999/02/22-rdf-syntax-ns#XMLLiteralLiteral XML value as specified by RDF
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 represents the link (relationship) is enough and does not require the creation of an intermediate link resource to describe the relationship.
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 and JSON would be likely be common.
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. [SPARQL-UPDATE]
4.1.13 BPR server responses MUST contain accurate response ETag header values.

4.2 HTTP GET

4.2.1 BPR servers MUST support the HTTP GET Method for BPRs.
4.2.2 BPR servers MUST provide an application/rdf+xml representation of the requested BPR.
4.2.3 BPR servers SHOULD provide a text/turtle representation of the requested BPR.
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 rdf:type.
4.2.5 In the absence of special knowledge of the application or domain, BPR clients MUST assume that the rdf:type values of a given BPR may change over time.

4.3 HTTP POST

There are no additional requirements on HTTP POST for BPRs.

4.4 HTTP PUT

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 dcterms:modified and dcterms:creator 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.
4.4.2 BPR clients SHOULD use the HTTP If-Match header and HTTP ETags to ensure it isn’t modifying a resource that has changed since the client last retrieved its representation. BPR servers SHOULD require the HTTP If-Match header and HTTP ETags to detect collisions. BPR servers MUST respond with status code 412 (Condition Failed) if ETags fail to match if there are no other errors with the request. [RFC2616]
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.
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 when their intent is to perform a later HTTP PUT to update the resource.
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 [RFC5789].
4.4.6 BPR servers MAY choose to allow the creation of new resources using HTTP PUT.
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 rdf:type, 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 who can modify resources. For some server applications, excessive constraints on modification of resources may be required.

4.5 HTTP DELETE

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.
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.

4.6 HTTP HEAD

4.6.1 BPR servers MUST support the HTTP HEAD method.
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 “Allow”.

4.7 HTTP PATCH

4.7.1 BPR servers MAY implement HTTP PATCH to allow modifications, especially partial replacement, of their resources. [RFC5789] No minimal set of patch document formats is mandated by this document.
4.7.2 BPR servers SHOULD allow clients to update resources without requiring detailed knowledge of server-specific constraints.  It is common BPR servers to put restrictions on representations – for example, the range of rdf:type, 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.

4.8 Common Properties

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 description, and the application semantic of description is compatible with dcterms:description, then dcterms:description 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 rdfs:range for the properties.

4.8.1 From Dublin Core

URI: http://purl.org/dc/terms/

Property Range Comment
dcterms:contributor dcterms:Agent
dcterms:creator dcterms:Agent
dcterms:created xsd:dateTime
dcterms:description rdf:XMLLiteral Descriptive text about the resource represented as rich text in XHTML format. SHOULD include only content that is valid and suitable inside an XHTML <div> element.
dcterms:identifier rdfs:Literal
dcterms:modified xsd:dateTime
dcterms:relation rdfs:Resource 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.
dcterms:subject rdfs:Resource
dcterms:title rdf:XMLLiteral A name given to the resource. Represented as rich text in XHTML format. SHOULD include only content that is valid inside an XHTML <span> element.

The predicate dcterms:type SHOULD NOT be used, instead use rdf:type. [DC-RDF].

4.8.2 From RDF

URI: http://www.w3.org/1999/02/22-rdf-syntax-ns#

Property Range Comment
rdf:type rdfs:Class he type or types of the resource
4.8.3 From RDF Schema

URI: http://www.w3.org/2000/01/rdf-schema#

Property Range Comment
rdfs:member rdfs:Resource
rdfs:label rdfs:Resource Only use this in vocabulary documents, to define the name of the vocabulary term.

5. Basic Profile Container

5.1 Informative

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:

  1. To which URLs can I POST to create new resources?
  2. Where can I GET a list of existing resources?
  3. How is the order of the container entries expressed?
  4. How do I get information about the members along with the container?
  5. How do I GET the entries of a large container broken up into pages?
  6. How can I ensure the resource data is easy to query?

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 rdfs:member predicate.

This document includes a set of guidelines for using POST to create new resources and add them to the list of members of a container. This document also explains how to include information about each member in the container’s own representation and how to paginate the container representation if it gets too big.

The 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 bp: <http://open-services.net/ns/basicProfile#>.

<http://example.org/container1>
   a bp:Container;
   dcterms:title "A very simple container";
   rdfs:member
      <http://example.org/container1/member1>,
      <http://example.org/container1/member2>,
      <http://example.org/container1/member3>.

This example is very straightforward - the membership predicate is rdfs:member and the membership subject is the container itself. A POST to this container will create a new resource and add it to the list of members by adding a new membership triple to the container.

Sometimes it is useful to use a subject other than the container itself as the membership subject and to use a predicate other than rdfs:member as the membership predicate, as illustrated below.

# The following is the representation of
#   http://example.org/netWorth/nw1/assetContainer
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix bp: <http://open-services.net/ns/basicProfile#>.
@prefix o: <http://example.org/ontology/>.

<http://example.org/netWorth/nw1/assetContainer>
   a bp:Container;
   bp:membershipSubject <http://example.org/netWorth/nw1>;
   bp:membershipPredicate o:asset.

<http://example.org/netWorth/nw1>
   a o:NetWorth;
   o:asset
      <http://example.org/netWorth/nw1/assetContainer/a1>,
      <http://example.org/netWorth/nw1/assetContainer/a2>.

The essential structure of the container is the same, but in this example, the membership subject is not the container itself – it is a separate net worth resource. The membership predicate is o:asset – a predicate from the domain model. A POST to this container will create a new asset and add it to the list of members by adding a new membership triple to the container. You might wonder why we didn’t just make http://example.org/netWorth/nw1 a container and POST the new asset directly there. That would be a fine design if http://example.org/netWorth/nw1 has only assets, but if it has separate predicates for assets and liabilities, that design will not work because it is unspecified to which predicate the POST should add a membership triple. Having separate http://example.org/netWorth/nw1/assetContainer and http://example.org/netWorth/nw1/liabilityContainer container resources allows both assets and liabilities to be created.

In this example, clients cannot simply guess which resource 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.

5.1.1 Container Member Information
This section is informative

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.

Continuing on from the JohnZSmith net worth example, there will be additional triples for the member resources (assets) in the representation:

# The following is the representation of
#	 http://example.org/netWorth/nw1/assetContainer
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix rdfs:    <http://www.w3.org/2000/01/rdf-schema#>.
@prefix bp:      <http://open-services.net/ns/basicProfile#>.
@prefix o:       <http://example.org/ontology/>.

<http://example.org/netWorth/nw1/assetContainer>
   a bp:Container;
   dcterms:title "The assets of JohnZSmith";
   bp:membershipSubject <http://example.org/netWorth/nw1>;
   bp:membershipPredicate o:asset.

<http://example.org/netWorth/nw1>
   a o:NetWorth;
   o:asset
      <http://example.org/netWorth/nw1/assetContainer/a1>,
      <http://example.org/netWorth/nw1/assetContainer/a3>,
      <http://example.org/netWorth/nw1/assetContainer/a2>.

<http://example.org/netWorth/nw1/assetContainer/a1>
   a o:Stock;
   o:value 10000.
<http://example.org/netWorth/nw1/assetContainer/a2>
   a o:Bond;
   o:value 20000.
<http://example.org/netWorth/nw1/assetContainer/a3>
   a o:RealEstateHolding;
   o:value 300000.
5.1.2 Retrieving Only Non-member Properties
This section is informative

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.

The example listed here only show a simple case where only a few simple non-member properties are retrieved, which may not seem important enough to warrant addressing this problem.  There are cases that add other predicates to containers, for example providing validation information and associating SPARQL endpoints.

Here is an example requesting the non-member properties of a container identified by the URL http://example.org/container1 and adding the query string ?non-member-properties :

Request:

GET /container1?non-member-properties HTTP/1.1
Host: example.org
Accept: text/turtle; charset=UTF-8

Response:

HTTP/1.1 200 OK
Content-Type: text/turtle; chartset=UTF-8
ETag: "_87e52ce291112"
Content-Length: 325

@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix bp: <http://open-services.net/ns/basicProfile#>.

<http://example.org/container1>
   a bp:Container;
   dcterms:title "A Basic Profile Container of Acme Resources";
   bp:membershipPredicate rdfs:member;
   dcterms:publisher <http://acme.com/>.
5.1.3 Paging
This section is informative

It sometimes happens that a container is too large to reasonably transmit its representation in a single HTTP response. This will be especially true if the container representation includes many triples from the representations of its members. A client may anticipate that a container will be too large - for example, a client tool that accesses defects may assume that an individual defect will usually be of sufficiently constrained size that it makes sense to request all of it at once, but that the container of all the defects ever created will typically be too big. Alternatively, a server may recognize that a container that has been requested is too big to return in a single message.

To address this problem, BPCs may 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.

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.

Continuing on from the member information from the JohnZSmith net worth example, we’ll split the response across 2 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 bp: <http://open-services.net/ns/basicProfile#>.
@prefix o: <http://example.org/ontology/>.

<http://example.org/netWorth/nw1/assetContainer>
   a bp:Container;
   dcterms:title "The assets of JohnZSmith";
   bp:membershipSubject <http://example.org/netWorth/nw1>;
   bp:membershipPredicate o:asset.

<http://example.org/netWorth/nw1/assetContainer?firstPage>
   a bp:Page;
   bp:pageOf <http://example.org/netWorth/nw1/assetContainer>;
   bp: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 bp: <http://open-services.net/ns/basicProfile#>.
@prefix o: <http://example.org/ontology/>.

<http://example.org/netWorth/nw1/assetContainer>
   a bp:Container;
   dcterms:title "The assets of JohnZSmith";
   bp:membershipSubject <http://example.org/netWorth/nw1>;
   bp:membershipPredicate o:asset.

<http://example.org/netWorth/nw1/assetContainer?p=2>
   a bp:Page;
   bp:pageOf <http://example.org/netWorth/nw1/assetContainer>;
   bp: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 bp:nextPage predicate of the page resource.

BPC guarantees that any and all the triples about the members will be on the same page as the membership triple for the member.

5.1.4 Ordering
This section is informative

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 above, 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, BPC avoids the use of RDF constructs like Seq and List for expressing order.

Order only becomes important for BPC servers when containers are paginated. If the server does not respect ordering when constructing pages, the client would be forced to retrieve all pages before sorting the members, which would defeat the purpose of pagination. In cases where ordering is important, 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 - bp:containerSortPredicates - that the server may use to communicate to the client which predicates were used for page ordering. Multiple predicate values may have been used for sorting, so the value of this predicate is an ordered list.

Here is an example container described previously, with representation for ordering of the assets:

# The following is the ordered representation of
#   http://example.org/netWorth/nw1/assetContainer
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>.
@prefix dcterms: <http://purl.org/dc/terms/>.
@prefix bp: <http://open-services.net/ns/basicProfile#>.
@prefix o: <http://example.org/ontology/>.

<http://example.org/netWorth/nw1/assetContainer>
   a bp:Container;
   dcterms:title "The assets of JohnZSmith";
   bp:membershipSubject <http://example.org/netWorth/nw1>;
   bp:membershipPredicate o:asset.

<http://example.org/netWorth/nw1/assetContainer?firstPage>
   a bp:Page;
   bp:pageOf <http://example.org/netWorth/nw1/assetContainer>;
   bp:containerSortPredicates (o:value).

<http://example.org/netWorth/nw1>
   a o:NetWorth;
   o:asset
      <http://example.org/netWorth/nw1/assetContainer/a1>,
      <http://example.org/netWorth/nw1/assetContainer/a3>,
      <http://example.org/netWorth/nw1/assetContainer/a2>.

<http://example.org/netWorth/nw1/assetContainer/a1>
   a o:Stock;
   o:value 100.00.
<http://example.org/netWorth/nw1/assetContainer/a2>
   a o:Cash;
   o:value 50.00.
<http://example.org/netWorth/nw1/assetContainer/a3>
   a o:RealEstateHolding;
   o:value 300000.

As you can see the o:value 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.

5.2 General

This section is normative
5.2.1 BPC servers MUST also be conformant BPR servers. A Basic Profile Container is a resource that is a Basic Profile Resource.
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.
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 rdfs:member predicate.
5.2.4 A BPC MUST contain 1 triple for the bp:membershipSubject predicate that indicates the subject of the membership triples.
5.2.5 A BPC MUST contain 1 triple for the bp:membershipPredicate predicate that indicates the predicate of the membership triple when the container predicate is not rdfs:member.
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 5.1.1 titled “Container Member Information” for additional details.
5.2.7 The representation of a BPC MUST have rdf:type of bp:Container, but it MAY have additional rdf:types.
5.2.8 BPCs SHOULD NOT use RDF container types rdf:Bag, rdf:Seq and rdf:List.

5.3 HTTP GET

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 5.2.3.
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 "non-member-properties" on the query component of the BPC URL.  For example, if there is a BPC URL <containerURL>, the URL to request the non-membership properties would be <containerURL>?non-member-properties.  See section 5.1.2 titled “Retrieving Non-member Properties” for additional details. A BPC server that does not support a request to retrieve non-member resource properties via a Request-URI of “<containerURL>?non-member-properties”, MUST return a HTTP status code 404 (Not Found).
5.3.3 A BPC server that does not support a request to retrieve the first page resource representation via a known BPC as “<containerURL>”, the Request-URI of “<containerURL>?firstPage”, MUST return a HTTP status code 404 (Not Found).
5.3.4 BPC servers SHOULD support requests for splitting large BPCs into pages indicated by a client supplying the token “firstPage” on the query component of the BPC URL. For example, if there is a BPC URL <containerURL>, the URL to request the first page would be <containerURL>?firstPage. The representation for any page, including the first, will include the URL for the next page.  If paging is supported, the last page MUST be signaled by the presence of rdf:nil object as the URL for the next page.  See section 5.1.3 titled “Paging” for additional details.
5.3.5 BPC servers MAY split the response representation of a BPC regardless of what the client requested (client omitted “firstPage” query component of request URL). This is also known as server-initiated paging. See section 5.1.3 titled “Paging” for additional details.
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.
5.3.6 BPC servers that support paging MUST include in the page representation a representation for the BPC, such that:
5.3.6.1 The page resource representation SHOULD have 1 triple to indicate its type, whose subject is the URL of the page, whose predicate is rdf:type and object is bp:Page; it also SHOULD have 1 triple to indicate the container it is paging, whose  subject is the URL of the page, predicate is bp:pageOf, and object is the URL of the BPC.
5.3.6.2 The page resource representation MUST have 1 triple with the subject of the page, predicate of bp:nextPage and object being the URL for the subsequent page.
5.3.7 BPC servers MAY represent the members of a paged BPC in a sequential order.  The order MUST be specified using the bp:containerSortPredicates 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 [SPARQL].
5.3.7.1 The bp:containerSortPredicates’ object – predicate used to indicate ordering – MUST NOT change between subsequent pages, otherwise ordering between members of a container across pages is undefined. See section 5.1.4 titled “Ordering” for additional details.

The Basic Profile does not define how clients discover BPCs.

5.4 HTTP POST

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 Location header set to the new resource’s URL.
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.
5.4.3 BPC servers MAY accept a HTTP POST of non-RDF representations for creation of any kind of resource, for example binary resources.
5.4.4 For servers that support create, BPC servers MUST create a BPR from a RDF representation in the request entity body.
5.4.5 BPC servers SHOULD NOT include in 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.
5.4.6 For BPCs, servers MUST accept a request entity body with a content type of application/rdf+xml.
5.4.7 For BPCs, BPR servers SHOULD accept a request with an entity body content type of text/turtle.
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.  
5.4.9 BPC servers SHOULD assign the subject URI for the resource to be created using server application specific rules.
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 rdf:type, 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 create resources and therefore discouraged.

5.5 HTTP PUT

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.
5.5.2 BPC servers MAY allow updating BPC non-membership properties using HTTP PUT on <containerURL>?non-member-properties, which MAY exclude server managed properties such as bp:membershipSubject and bp:membershipPredicate.

5.6 HTTP DELETE

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.
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.

5.7 HTTP HEAD

There are no additional requirements on HTTP HEAD.

5.8 HTTP PATCH

5.8.1 BPC servers are RECOMMENDED to support HTTP PATCH as the preferred method for updating BPC non-membership 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
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 Typeshttp://www.iana.org/assignments/media-types/index.html
LinkedData
Linked Data at W3C http://www.w3.org/standards/semanticweb/data
RDF-MT
RDF Semantics, P. Hayes, Editor, W3C Recommendation, 10 February 2004, http://www.w3.org/TR/2004/REC-rdf-mt-20040210/. Latest version available at http://www.w3.org/TR/rdf-mt/.
RDF-REST
RDF Simple Data Interface Protocol – Level Zero, Latest version available at: http://www.w3.org/2001/sw/wiki/index.php?title=REST
REST
Representational State Transfer (REST), R. Fielding, Ph.D. dissertation, 2000, Latest version available at http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm .
SPARQL
SPARQL Query Language for RDF, E. Prud'hommeaux, A. Seaborne, Editor, W3C Recommendation, 15 January 2008, http://www.w3.org/TR/2008/REC-rdf-sparql-query-20080115/. Latest version available at http://www.w3.org/TR/rdf-sparql-query/.
SPARQL-HTTP
SPARQL 1.1 Graph Store HTTP Protocol, Latest version available at http://www.w3.org/2009/sparql/docs/http-rdf-update/
TURTLE
Turtle - Terse RDF Triple Language , D. Beckett, T. Berners-Lee, Team Submission, 28 March 2011, http://www.w3.org/TeamSubmission/2011/SUBM-turtle-20110328/. Latest version available at http://www.w3.org/TeamSubmission/turtle/.
WEBARCH
Architecture of the World Wide Web, Volume One , N. Walsh, I. Jacobs, Editors, W3C Recommendation, 15 December 2004, http://www.w3.org/TR/2004/REC-webarch-20041215/. Latest version available at http://www.w3.org/TR/webarch/.

7. Acknowledgements

Additional Contributors:

Arthur Ryman (IBM), Ian Green (IBM), Barbara McKee (IBM), Sally Hehir (IBM)