Content Negotiation by Profile

Abstract

This document describes how Internet clients may negotiate for content provided by servers based on data profiles to which the content conforms. This is distinct from negotiating by Media Type or Language: a profile may specify the content of information returned, which may be a subset of the information the responding server has about the requested resource, and may be structured in a specific way to meet interoperability requirements of a community of practice.

This section is non-normative.

Note

The standardization of the content-negotiation HTTP headers is the purview of the IETF. A first proposal for an Internet Draft for Indicating and Negotiating Profiles in HTTP [PROF-IETF] is available but has not yet been submitted to the IETF. The current version of the IETF draft (-00) is expected to be completely re-written in parallel work with this document and should be seen as a work-in-progress until this paragraph is removed from this document.

The HTTP Accept and Content-Type header fields [RFC7231] allow a client to specify acceptable Media Types (Accept) and a server to indicate the Media Type of the response's body (Content-Type). A Media Type registration can also specify an optional list of Media Type parameters. Some Media Type registrations (e. g. application/ld+json) have specified the use of a Media Type parameter "profile" that could be used to signal the profile to which that the body of the response conforms.

Example 1: Using the HTTP Accept header together with a 'profile' parameter

GET /resource/a HTTP/1.1
Accept: application/ld+json;q=0.9;profile="urn:example:profile-1", \
        application/ld+json;q=0.7;profile="urn:example:profile-2"

--

HTTP/1.1 200 OK
Content-Type: application/ld+json;profile="urn:example:profile-2"

During 2018, DXWG members had a longer discussion with the JSON-LD WG at the annual forum TPAC in Lyon, France and it was concluded that the "profile” parameter in the Accept and Content-Type headers should be seen to convey profiles that are specific to the Media Type, such as JSON-LD's "expanded" (http://www.w3.org/ns/json-ld#expanded) or "flattened" (http://www.w3.org/ns/json-ld#flattened). In order to signal the use of Media Type-independent profiles, the http header fields Accept-Profile and Link: <...>; rel="profile" are to be used.

The HTTP Link header field [RFC8288] relates a web resource (Link Context) to a target resource (Link Target) by specifying the relation between the two resources. One of the relation types is "profile", as defined in [RFC6906]. [RFC6906] defines a profile as "additional semantics that can be used to process a resource representation […] that do not alter the basic Media Type semantics" and specifically states that "creators and users of profiles MAY define and manage them in a way that allows them to be used across Media Types". So the "profile" relation seems like a suitable way to communicate information about acceptable profiles (requests) and content (responses).

Example 2: Using a Link header with a profile parameter

HEAD /resource/a HTTP/1.1
Accept: text/turtle;q=0.9,application/rdf+xml;q=0.5
Link: <http://example.com/profile/x>; rel="profile"

--

HTTP/1.1 200 OK
Content-Type: text/turtle
Link: <http://example.com/profile/x>; rel="profile"

The "profile" relation can be used by a server to indicate the profile of the response body There is, however, no possibility to convey quality information (q-values) in a request using the "profile" relation.

The http Prefer and Preference-Applied header fields [RFC7240] can be used to convey information about profile preferences. A client could use the Prefer header to tell the server about its preference for a resource's representation conforming to a specific profile. If the server sends a Preference-Applied header field in the response, the client will know that the preference was honoured.

Example 3: Using a Prefer header with a profile parameter

GET /resource/a HTTP/1.1
Accept: text/turtle
Prefer: profile="urn:example:schema"

--

HTTP/1.1 200 OK
Content-Type: text/turtle
Preference-Applied: profile="urn:example:schema"

This approach has two disadvantages. The first, as with the Link header, is that there is no possibility to work with q-values in request headers. The second is that the only way for a server to state that it ignored the preference indicated by the client is to omit sending a Preference-Applied header field. For the client, however, it is not clear if the Preference-Applied header is absent because the server did not honor the preference, or because the server did not understand the Prefer header. This could be solved by making it mandatory to send a Link: rel=profile header when answering a request with a Prefer: profile="" header in it. That solution requires that a client evaluate two different headers to find a response to its request for a specific profile, which would make client implementation more complicated. Further, [RFC7240] explicitly recommends that implementers "SHOULD NOT use the Prefer header mechanism for content negotiation."

This section describes a conceptual – abstract – model for content negotiation by profile, independent of any implementation it within specific environments.

Implementations of this Abstract Model for different environments are called Functional Profiles. To be a valid functional profile they MUST implement these Abstract Model functions. How they do this will be environment-specific.

Functional Profiles MAY extend upon this Abstract Model with additional features of their own as but these additions MUST NOT invalidate the functions defined here.

A data model for describing the representations of a resource that conform to different data profiles is given here and this model MUST be used by all Functional Profiles. How the data model is realized is left to implementers to determine. How conformance of implemented data models is demonstrated is not addressed here in detail and only this guidance is given: implementers SHOULD demonstrate conformance of their Alternate Representations Data Model implementations by providing a published mapping between their environment-specific realization of the model and a concrete realization of the model given in this specification, such as its OWL ontology representation.

All content negotiation over the Internet takes place between a client and a server with the former requesting a representation of a resource or a resource's metadata through a request and receiving the requested representation via a response. For any given pair of communicating machines, the roles of client and server may be reversed as information is requested back and forth.

An Internet resource may have many aspects over which a client/server pair of agents might negotiate for content. These aspects are to be treated independently so content negotiation for a resource involving negotiation by profile and negotiation by any other aspects will not affect each other.

In this Abstract Model, we don't assume any specific details about client, server, resource, metadata, request or response other than those details already provided those terms in the definitions section3. Definitions.

A client requesting the representation of a resource conforming to a data profile MUST identify the resource by a Uniform Resource Identifier (URI) [RFC3986] and MUST identify the profile either by a URI or a token.

If a URI is used for profile identification, it SHOULD be an HTTP URI that dereferences to a description of the profile. Other kinds or URIs, e. g. URNs, MAY also be used and these may not be dereferenceable. If a token is used, it MUST unambiguously identify the data profile within a request/response pair of messages. The server MUST declare the context within which the token may be mapped to a URI.

There are two main types of request that a client might make of a server regarding content negotiation by profile. A client wishing to negotiate for content via a profile adhering to this specification MUST be able to implement these two request types:

list profiles
a client requests the list of URIs of data profiles for which a server is able to deliver conformant resource representations
get resource by profile
a client requests a representation of the requested resource conforming to a particular profile

A server adhering to this specification MUST respond to each request with the following respective responses:

list profiles
a server responds to a client with the list of URIs of the data profiles for which it is able to deliver conformant resource representations
get resource by profile
a server responds with either a specific data profile for a resource conforming to a requested profile identified by the client or it responds with a default data profile

More detailed descriptions of these requests and their responses are given next.

A client wishes to know for which data profiles a server is able to deliver conformant representations of a resource. The list of profiles may be known either before a request for a particular resource representation is made or it may only be known after an initial request is made.

The list profiles request MUST be either an independent request or part of another functional profile's request.

The list profiles request MAY result in a response in one of a number of formats, provided that the data profiles to which representations of resources conform are unambiguously identified either by either a URI or a token. If the latter, it MUST be mappable to a URI within one particular client/server message pair.

A server MUST NOT list data profiles it is unable to deliver when presented with a get resource by profile request specifying that data profile.

Example 4 shows a request/response pair of messages conforming to the QSA Functional Profile, where the request is a list profiles request for a particular resource.

Example 4: Simple list profiles request & response messages (QSA Functional Profile)

# A request for all the profiles to which representations of resource a conform
GET /resource/a?_profile=alt HTTP/1.1

---

# The server returns a list of profiles both in its HTTP response header and also
# in the response body (HTML). Note that the action of returning the response message
# conforms to the QSA Functional Profile and this is indicated with the Link header
# combined with the "profile" relation
HTTP/1.1 200 OK
Content-Type: text/html
Link: <http://www.w3.org/ns/dx/connegp/profile/qsa>; rel="profile"
# This Link header indicates representations are available that conform to Profile X
# & Y and that the Profile X-conformant representations are available in HTML
# & XML Media Types.
Link:
  <http://example.org/resource/a?_profile=profile-x&_mediatype=text/html>;
          rel="canonical"; type="text/html";
          format="http://otherexample.org/profile/x",
  <http://example.org/resource/a?_profile=profile-x&_mediatype=text/xml>;
          rel="alternate";
          type="text/xml";
          format="http://otherexample.org/profile/x",
  <http://example.org/resource/a?_profile=profile-y&_mediatype=text/xml>;
          rel="alternate";
          type="text/xml";
          format="http://otherexample.org/profile/y"

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8">
    <title>Profiles for Resource A</title>
  </head>
  <body>
    <h1>Profiles available for Resource X</h1>
    <ul>
      <li><a href="?_profile=profile-x&_mediatype=text/html">X, in HTML</a></li>
      <li><a href="?_profile=profile-x&_mediatype=text/xml">X, in XML</a></li>
      <li><a href="?_profile=profile-y&_mediatype=text/xml">Y, in XML</a></li>
    </ul>
  </body>
</html>

The most basic request of content negotiation by profile is for a client to request a representation of a resource that is claimed to conform to a data profile.

A client executing a get resource by profile request MUST identify the data profile with either a URI or with a token mapping unambiguously to a URI within the session.

A client executing a get resource by profile MAY request a resource representation conforming to one of any number of data profiles with its preference expressed in a functional profile-specific ordering.

The server SHOULD attempt to reply with a profile that best matches the client request. The order of preference a server MUST follow to determine a best matching profile is: an exact match, followed the next most specific profile that the resource representation conforms to. Note that resource representations might conform to more general specifications or other profiles via a hierarchy (i.e. transitively).

If a server redirects to another resource it MUST indicate the selected choice of profile from the list requested by the client and SHOULD indicate a specific narrower profile expected to be returned (if known) in the redirection request (303 response).

Note: Redirection to another resource

Since get resource by profile requests are for representations of a resource, and that resources for which there are profile-conformant representations may not be information resources, it is important to note that a server's response may take the form of a redirect to another resource. This is as per the W3C's recommendations to handle the so-called 'httpRange-14' issue. An example of a redirecting response is given in Example 6.

A simple request/response message pair with Accept-Profile and Link: rel="profile" headers included, according to the HTTP Headers Functional Profile, is shown in Example 5 and an example with a redirect is shown in Example 6. Example 7 shows an HTTP Headers Functional Profile message pair indicating a narrower profile response than the requested profile.

Example 5: Simple get resource by profile request & response (HTTP Headers Functional Profile)

# A request for resource a according to Profile x is made
GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>

---

# The server returns a representation of Resource a conforming with Profile x
HTTP/1.1 200 OK
Link: <http://example.org/profile/x>; rel="profile"

[response body]

Example 6: Get resource by profile request & response (HTTP Headers Functional Profile) with 303 redirect

# A request for a non-information resource a according to Profile x is made
GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>

---

# The server returns a 303 Redirect to another URI identifying an information
# resource that then returns the requested resource representation. The redirecting
# server indicates the profile to which the redirected to resource representation
# conforms
HTTP/1.1 303 See Other
Location: http://example.org/info-resource/b
Link: <http://example.org/profile/x>; rel="profile"

---

# The client now requests the indicated information resource. Note that the
# Accept-Profile header is no longer needed since the original response has
# catered for that in the redirect response
GET /info-resource/b HTTP/1.1

---

# The final server response with the information resource. Note that this
# response does not include the profile-indicating Link rel="profile" header
HTTP/1.1 200 OK

[response body]

Example 7: Get resource by profile responding with a conforming, narrower, profile (HTTP Headers Functional Profile)

# A request for Resource A whose representation conforms
# to Profile X is made

GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>
[more request headers]

---

# The server is able to respond with a representation of
# Resource a according to Profile Y which it knows is a
# profile of Profile X

# The server responds with the list of profiles that it knows
# the resource representations conforms to ensuring that the
# requested profile, Profile X, is listed. Here Profile Y and
# a further profile irrelevant for the client, Profile Z, are
# indicated.

HTTP/1.1 200 OK
[other response headers]
Link: <http://example.org/profile/x>; rel="profile", \
      <http://example.org/profile/y>; rel="profile", \
      <http://example.org/profile/z>; rel="profile"
[more response headers]

[content conforming to to Profile X, Y & Z]

When a resource is returned that conforms to two or more profiles that are not within the same profile hierarchy (i.e. the resource conforms to a set of profiles, but some of these are independent, not being specialised profiles of others in the set), the server SHOULD indicate indicate conformance to each independent profile.

For example, using the HTTP Headers Functional Profile, a response from a server that conforms to both [GeoDCAT-AP] and also [STATDCAT-AP], given that neither profiles the other and thus no single indication of conformance will suffice for both, (note they both do profile [DCAT-AP], see the DCAT-AP Hierarchy example in [DX-PROF]), a response using profile URIs for [GeoDCAT-AP] and [STATDCAT-AP] could be:

Link: <https://joinup.ec.europa.eu/release/geodcat-ap-v10>; rel="profile", <https://joinup.ec.europa.eu/release/statdcat-ap/101>; rel="profile"

This data model MUST be used for describing the representations of a resource that conform to different profiles.

A graphical overview of this model is given in Figure 1.

Figure 1 A diagram of the Alternate Profiles data model implemented in OWL [OWL2-OVERVIEW].

Descriptions of alternate representations of a resource conforming to different profiles MAY be presented according to modelling systems implementing this model, depending on what is deemed to be relevant to the application profile for which this specification has been created. For example, the HTTP Application Profile (7.2 Hypertext Transfer Protocol Headers) is limited to text within the constraints of the HTTP specification's headers structure in [RFC7230] and thus syntactic communication of this data model in that environment must be implemented according to its constraints.

Tools for testing the conformance of data instances to some implementations of this data model are given in 9. Test Suites. Suggestions for concrete implementations of, and extensions to, this data model for use in expected situations are given in A.4 Alternate Representations Data Model - Details. Examples of suggested use are also given in that appendix.

A service MAY implement multiple functional profiles, including HTTP, QSA and possibly other approaches. In such cases a client may specify conflicting choices via different mechanisms, for example the common case of client sending default headers but asking for a specific representation. The order of precedence defined here determines which mechanism MUST be used.

The order of precedence is QSA over HTTP. This is on the basis that the more precisely a URI points to a resource, the more likely it is that the agent intends to request that precise resource irrespective of which HTTP headers are sent with that request.

If other potentially conflicting functional profiles of the abstract model are defined, then order of precedence will need to be established. No specific mechanism is proposed for how this may be declared.

Issue 505

This section illustrates a few functional profiles of this specification's Abstract Model for different system environments. They may be conformed to by systems operating within different environments wishing to conform to this specification. Conforming to the profiles illustrated here is not mandatory; conformance to any profile that conforms to the Abstract Model fulfills conformance to this specification.

This specification provides functional profiles of the abstract model for two environments: HTTP Header and human browser (URL Query String Arguments). It also provides a functional profile that has the single function to respond with which profile(s) a server response conforms to, and which can be used in multiple environments.

Issue 1022

For the human browser environment, two functional profiles are presented to demonstrate different modes of use. Further functional profiles of this specification MAY be implemented either for other environments and or even for constrained scenarios within these environments, and implementers are encouraged create additional profiles conforming to this specification.

Note: Conformance to multiple functional profiles

The functional profiles provided here are conformant with the Abstract Model. Systems may implement one or more of the profiles provided in this document or may develop other functional profiles that conform to the abstract model. Conformance to one of the profiles provided here guarantees conformance to the abstract model, but conformance can be achieved with other functional profiles also. Implementers of Content Negotiation by Profile need not ensure systems conform to multiple functional profiles of this specification; they need only conform to the functional profile(s) relevant to their environment.

The functional profiles of this specification provided here are listed in Figure 2. The namespace prefix for them is:

cnpr → http://www.w3.org/ns/dx/connegp/profile/

URI	Name	Description	Usage Note
`cnpr:http`	HTTP Headers Functional Profile	For conformance with the functional profile presented in 7.2 Hypertext Transfer Protocol Headers.	To be used if a resource conforms to the HTTP Headers Functional Profile
`cnpr:qsa`	QSA Functional Profile	For conformance with the functional profile presented in 7.3 URL Query String Arguments.	To be used if a resource conforms to the URL QSA functional profile using the Query String Arguments `_profile` and `_mediatype` as per the recommendations in 7.3 URL Query String Arguments.
`cnpr:qsa-alt`	QSA Alternate Keywords Functional Profile	For conformance with the functional profile presented in 7.3 URL Query String Arguments.	To be used if a resource conforms to the URL QSA functional profile but uses alternate keywords for the Query String Arguments `_profile` and `_mediatype`, as allowed by the recommendations in 7.3 URL Query String Arguments.
`cnpr:rrd`	Resource Representation Description	For conformance with 6.3.2 Get Resource by Profile.	To be used if a resource representation is able to indicate which profile(s) it conforms to, in its appropriate functional profile, as per the abstract specification in 6.3.2 Get Resource by Profile.

Figure 2 Profiles of this Content Negotiation by Profile specification to be used by resources and systems to indicate conformance to one or more forms of it.

The namespace used for the above functional profiles, http://www.w3.org/ns/dx/connegp/profile/, is part of the Dataset Exchange Working Group's reserved W3C namespace, http://www.w3.org/ns/dx/, which is provisioned for all namespace requirements to do with issues addressed by that Working Group. The /profile/ path segment indicates a register of profile objects which currently contains just the 4 instances above from Figure 2.

A functional profile of the Abstract Model using Hypertext Transfer Protocol (HTTP) headers is presented here. This implementation is based on HTTP content negotiation and uses Link headers formulated in particular ways and a new HTTP header, Accept-Profile that is to be defined in an upcoming Internet-Draft [PROF-IETF].

Note: POST/PUT out of scope

POST & PUT methods are considered out-of-scope for this Functional Profile. It is not clear what functions of the proposed Abstract Model these HTTP methods would implement.

Link headers with rel="profile" may be specified in POST & PUT requests to communicate the conformance of a request message's content.

Although servers are free to implement negotiation as they see fit, if the User Agent sends an Accept-Profile header, they SHOULD consider representations not conforming to any of the listed profiles as non-interpretable by the client. This means that a representation that conforms to a listed profile, but has a low preference score on other dimensions, SHOULD be considered as more desired than a representation with a higher preference score on other dimensions but that does not conform to any listed profile. If no Accept-Profile header preference is given, the profile dimension SHOULD be ignored for negotiation purposes. Nevertheless, in all cases, the server's response SHOULD contain a Link header with rel="profile" listing the URIs of all profiles to which it knows the representation conforms.

The preferred way to retrieve a list of profiles the server supports for a specific resource is to issue a GET or HEAD request for that resource. In either case, a server implementing content negotiation by profile SHOULD return an HTTP Link header containing information about the default and any alternate representations of that resource including profiles they conform to. The default representation – the one that will be returned when no specific representation is requested – SHOULD be identified by rel="canonical", other representations by rel="alternate".

As an example, consider the resource http://example.org/resource/a available in the Media Types application/xml, text/html and text/turtle. The text/html representation has no profile, whereas the application/xml and text/turtle representations are both available in the profiles urn:example:profile:x and urn:example:profile:y.

Assuming that a request without an Accept-Profile header per default delivers content conforming to urn:example:profile:x, an HTTP request/response pair would look as per Example 8.

Example 8: Server returns a Link header to indicate available profiles

HEAD /resource/a HTTP/1.1
Accept: text/turtle
[more request headers]

---

HTTP/1.1 200 OK
Content-Type: text/turtle
# This Link header indicates which profile this response conforms to
Link: <urn:example:profile:x>; rel="profile"
# This Link header lists all available profiles
Link:
  <http://example.org/resource/a>;
          rel="canonical";
          type="text/turtle";
          format="urn:example:profile:x",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/turtle";
          format="urn:example:profile:y",
  <http://example.org/resource/a>;
          rel="alternate";
          type="application/xml";
          format="urn:example:profile:x",
  <http://example.org/resource/a>;
          rel="alternate";
          type="application/xml";
          format="urn:example:profile:y",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/html"
[more response headers]

In Example 8, for each of the different Media Type / Profile combinations, the URI of the resource remains unchanged and it is the Accept and Accept-Profile headers for Media Type and Profile respectively that alter the returned response.

A server MAY use Content-Location HTTP headers to indicate direct links to representations of the resource according to Media Type / Profile combinations and, if it does so, it may replace the unchanged URI in the Link header with those direct URIs, as per example .

Example 9: Server returns Link header with Content-Location URIs for some Profiles and Media Types

HEAD /resource/a HTTP/1.1
Accept: text/turtle
[more request headers]

---

HTTP/1.1 200 OK
Content-Type: text/turtle
Content-Location: http://example.org/resource/a.prof1.ttl
Link: <urn:example:profile:x>; rel="profile"
Link:
  <http://example.org/resource/a.prof1.ttl>;
          rel="canonical";
          type="text/turtle";
          format="urn:example:profile:x",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/turtle";
          format="urn:example:profile:y",
  <http://example.org/resource/a.prof1.xml>;
          rel="alternate";
          type="application/xml";
          format="urn:example:profile:x",
  <http://example.org/resource/a>;
          rel="alternate";
          type="application/xml";
          format="urn:example:profile:y",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/html"
[more response headers]

[In the Link header, Content-Location URIs are only used as context
URIs for resources conforming to profile urn:example:profile:x]

Functional profile implementations need to ensure that they, in addition to implementing the Abstract Model's functions, can deliver alternate representation information as per the Alternate Representations Data Model. In this HTTP Headers functional profile, the chosen mechanics for doing this are Links headers (from [RFC8288]), as described below.

An HTTP Link is (from [RFC8288]) "a typed connection between two resources and is comprised of":

A link context,
a link target,
a link relation type, and
optionally, target attributes.

The link context is the resource for which the Link header is being delivered. The relation type is given with a rel attribute key name, the link target is a URI and other optional target attributes may include profile, given with a profile attribute key name.

In Example 9, the first portion of the Link header returned for the request for the link context resource/a has these parts:

link target - <http://example.org/resource/a.prof1.ttl>
relation type - rel="canonical"
target attributes - type="text/turtle" & format="urn:example:profile:x"

Using these Link HTTP header parts, this HTTP Headers functional profile is able to communicate alternate data profiles for a resource as per the Alternate Profiles Data Model and Figure 3 below maps the header parts to the OWL ontology representation of the Data Model which is a concrete and formal realization of it. This mapping is presented as per the directive in the 6. Abstract Model that "implementers SHOULD demonstrate conformance of their Alternate Representations Data Model implementations by providing a published mapping between their environment-specific realization of the model and a concrete realization of the model given in this specification, such as its OWL ontology representation.

Alternate Representations Data Model Element	Link Header Element
`rdf:Resource`	the link context URI indicates an instance of rdf:Resource
`altp:Representation`	the link target URI indicates an instance altp:Representation
`dct:Standard`	a target attribute of `profile` indicates the URI of an instance of dct:Standard, if present
`dct:conformsTo`	the implicit relation between the link target URI and the target attribute `profile` URI
`altp:hasRepresentation`	the implicit relation between the link context URI and the link target URI where a relation type of `alternate` is given
`altp:hasDefaultRepresentation`	the implicit relation between the link context URI and the link target URI where a relation type of `canonical` is given

Figure 3 A mapping of the elements within an HTTP Link header communicating alternate representations' information to the elements within the Alternate Profiles Data Model as identified in its OWL ontology representation.

Example 10: HTTP Link header mapping to Alternate Profiles Data Model

# Link headers from previous example with one altered to show Blank Node v.
# absolute URIs for altp:Representation class instance
# (<http://example.org/resource/a>; → <http://example.org/resource/different>;)
Link:
  <http://example.org/resource/a>;
          rel="canonical";
          type="text/turtle";
          format="urn:example:profile:x",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/turtle";
          format="urn:example:profile:y",
  <http://example.org/resource/a>;
          rel="alternate";
          type="application/xml";
          format="urn:example:profile:x",
  <http://example.org/resource/different>;
          rel="alternate";
          type="application/xml";
          format="urn:example:profile:y",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/html"

# Link headers above represented in Alternate Profiles Data Model
# as an OWL ontology
<http://example.org/resource/a>
    altp:hasDefaultRepresentation [
        dct:format "text/turtle" ;
        dct:conformsTo <urn:example:profile:x> ;
    ] ;
    altp:hasRepresentation [
        dct:format "text/turtle" ;
        dct:conformsTo <urn:example:profile:y> ;
    ] ,
    [
        dct:format "application/xml" ;
        dct:conformsTo <urn:example:profile:x> ;
    ] ,
    <http://example.org/resource/different> ,
    [
        dct:format "text/html" ;
    ] 
.

<http://example.org/resource/different>
    dct:format "application/xml" ;
    dct:conformsTo <urn:example:profile:y> .

If an HTTP server wishes to allow a client to identify a profile via a token, in addition to the mandatory identification of profiles via via URI, the servers SHOULD indicate for every supported token to which profile URI it corresponds. When implementing the HTTP Headers functional profile of this specification, a server MUST include a Link header ([RFC8288]) for each profile URI/token pair in its response. Each Link header MUST use the Link Target "http://www.w3.org/ns/dx/prof/Profile" and MUST contain the following Target Attributes:

Target Attribute	Target Attribute value
`rel`	`"type"`
`token`	The token mapped to the profile URI in the `anchor` attribute
`anchor`	The profile URI of the profile mapped to the token in the `token` attribute

An example Link header used to communicate a token/URI mapping is given in Example 11.

Example 11: Using the Link attribute ''token'' to link a profile URI to a token

# The profile URI in the "anchor" element is linked to the token "igsn-r1"

# Further, the relation "type" is used to inform
# that the anchor resource is of type "dct:Standard"

Link: <http://www.w3.org/ns/dx/prof/Profile>;
  rel="type";
  token="igsn-r1";
  anchor=<http://schema.igsn.org/description/1.0>

Servers MAY add more attributes to a Link header alongside token/URI mappings, for example Alternate Representations data model content. Example 12 shows tokens a Link header with multiple attributes.

Example 12: HTTP headers with profile URI / token mappings using 'token' parameters

# The Profile with URI urn:example:profile:marc21-dnb is mapped to the token "dnb"
# and the Profile with URI http://example.org/profiles/marc21-loc is mapped to the token "loc"

HEAD /resource/a HTTP/1.1
Accept: text/turtle
[more request headers]

---

HTTP/1.1 200 OK
Content-Type: text/turtle
Content-Location: http://example.org/resource/a.profx.ttl
Link: <urn:example:profile:x>; rel="profile"
Link:
  <http://www.w3.org/ns/dx/prof/Profile>; rel="type"; token="dnb"; anchor=<urn:example:profile:marc21-dnb>,
  <http://www.w3.org/ns/dx/prof/Profile>; rel="type"; token="loc"; anchor=<http://example.org/profiles/marc21-loc>,
  <http://example.org/resource/a.profdnb.ttl>; rel="canonical"; type="text/turtle"; format="urn:example:profile:marc21-dnb",
  <http://example.org/resource/a.profloc.ttl>; rel="alternate"; type="text/turtle"; format="http://example.org/profiles/marc21-loc",
  <http://example.org/resource/a.profdnb.xml>; rel="alternate"; type="application/xml"; format="urn:example:profile:marc21-dnb",
  <http://example.org/resource/a.profloc.xml>; rel="alternate"; type="application/xml"; format="http://example.org/profiles/marc21-loc",
  <http://example.org/resource/a.html>; rel="alternate"; type="text/html"
[more response headers]

Getting a resource representation conforming to a specific profile is done by issuing an HTTP GET request against the resource and specifying the desired profile URI in an Accept-Profile header.

A server implementing content negotiation by profile MUST respond with an HTTP Response header containing a Link header with rel="profile" indicating the profile returned.

URIs, both in Requests and Responses, MUST be enclosed in angled brackets, '<' & '>'.

A range of acceptable profile URIs MAY be supplied, and if they are, they MUST be delimited by a comma or be in separate Accept-Profile headers.

Preferences MAY be indicated by by the Client using quality indicators (q-values) as an ordering mechanism separated from the URI by a semi-colon, ';'. An example of a URI (in this case a URN) with a q-value is <urn:example:profile:x>;q=1.0, where the URI is <urn:example:profile:x> and the q-value is q=1.0.

Example 13 shows a simple request for a resource, /resource/a, with a preference for representations according to profiles identified by the URIs (URNs, in this example) urn:example:profile:x & urn:example:profile:y with 'q' values indicating a higher preference for the first. A response is returned by the server which indicates conformance with urn:example:profile:x by inclusion of that identifier in the Link HTTP header with rel="profile".

Example 13: Requesting a resource representation conforming to a specific profile using HTTP headers

GET /resource/a HTTP/1.1
Accept: text/turtle;q=0.8, application/xml;q=0.5
Accept-Profile: <urn:example:profile:x>;q=1.0,<urn:example:profile:y>;q=0.6
[more request headers]

---

HTTP/1.1 200 OK
Content-Type: text/turtle
Link: <urn:example:profile:x>; rel="profile"
[more response headers]

Having performed content negotiation and returned a resource representation, it is RECOMMENDED that the server also include a Link header indicating the availability of alternate resources encoded in other Media Types and conforming to other profiles, as per 7.2.1 List Profiles.

While the HTTP Headers functional profile's approach to profile negotiation enables fully automated content negotiation by profile, the motivating use cases for this specification included human actionable negotiation. Also, as related in 5. Related Work, previous and existing systems already allow for human-actionable content negotiation by profile by a number of means.

To both allow for human-actionable content negotiation by profile and also to show how mechanics similar to existing systems might fulfill all aspects of this specification's Abstract Model, this section shows a Query String Argument (QSA) functional profile of the Abstract Model. This functional profile is functionally equivalent to the HTTP Hedaers functional profile in that all required functions of the Abstract Model are supported however it is not mutually exclusive of the HTTP, or any other, functional profile: an implementation of this specification may be conformant to multiple functional profiles of it to implement content negotiation by profile functionality in multiple environments or in different ways within the same environment.

Unlike the HTTP Headers functional profile which is also the subject of an independent IETF document [PROF-IETF], the QSA functional profile is fully specified here. Two forms of this QSA approach are presented: the first is the fixed keyword "QSA Functional Profile" and the second is the "QSA Alternate Keywords Functional Profile" according to which servers may implement any keywords they choose. These various functional profiles are all identified in 7.1 Functional Profiles of this specification.

Note

Conformance of a system to any one, or perhaps multiple, of these functional profiles may be demonstrated as per A.3 Demonstrating system conformance to Functional Profiles. Note that it is not required that a system, perhaps a server, indicate conformance to one or more of the functional profiles described in this specification since not all systems will do so. Systems may also show conformance to functional profiles in multiple ways, such as with annotated entries in a services catalogue.

A query string is a part of a URL which assigns values to specified parameters. QSAs are commonly used within web browsers by humans and in other client/server situations to deliver extra information to a server. Query string key/value pairs are separated from the scheme, authority and path of a URI by a question mark symbol, ?, and consist of key/value pairs connected by an equals symbol, =, and separated from each other key/value pair by an ampersand symbol, &, as per [RFC3986].

An example resource-requesting URI with content negotiation by profile implemented using QSA is shown in Example 14.

Example 14: Example resource-requesting URI with content negotiation by profile implemented using QSA

http://example.com/path/to/resource/a?_profile=prof-01

In Example 14, the profile requested for the resource representation is indicated by the token prof-01 which MUST be appended to the resource's URI as a Query String Argument. As per this specification's 6.3.1 List Profiles's allowance, a token is used here to identify the profile - prof-01 - but that token MUST be mappable to a URI within one particular client/server session and mechanics for that are described below.

Additional aspects of content negotiation MAY be included in such URIs by the use of additional QSA or by any other techniques (for example HTTP headers) but, if they are, they MUST NOT change the actions of the request for content negotiation by profile. To demonstrate an acceptable inclusion, if the client using the URI in Example 14 wished to indicate a preference for the content of the request to be serialised as RDF, according to the Turtle [TURTLE] specification, it could use the IANA Media Types list's token for Turtle which is text/turtle and formulate the URI as per Example 15 which is accordance with URI formulation requirements [RFC3986].

Example 15: Example QSA URI with content negotiation by profile and Media Type

http://example.com/path/to/resource/a?_profile=prof-01&_mediatype=text/turtle

Note: Maximum length of URLs

If Query String Arguments use URIs (or URLs) to convey important information, implementers should ensure that the total length of the total requesting URI within which the QSAs using URIs/URLs exist does not exceed length restrictions. [RFC7230]'s §3.1.1 recommends that senders and recipients support request lines of at least 8,000 octets. Some client and server implementations, however, cannot accept URLs longer than 2,000 characters, for example, the Sitemap protocol which has a length limit of 2,048 characters in a URL. Cf. this question on stackoverflow for a longer discussion of issues related to URL length.

This specification includes two different functional profiles of it for use by human clients using Query String Arguments that are differentiated by their requirements for QSA key naming. The two profiles are the "QSA Functional Profile" and "QSA Alternate Keywords Functional Profile" with the former being a profile of the latter. This is due to the former containing more stringent conformance rules ("narrower" rules) about how to achieve this specification's required functionality. These functional profiles are identified and defined in 7.1 Functional Profiles of this specification.

To conform to the "QSA Functional Profile", the QSA key _profile MUST be used to indicate a profile token or URI and the key _mediatype SHOULD be used to indicate a resource representation's Media Type.

When conforming to the profile "QSA Alternate Keywords Functional Profile", any key values acceptable within the specification of [RFC3986] MAY be used to indicate the desired profile. However, servers conforming to this functional profile additionally MUST present a mechanism to allow clients to discover what value is used, as detailed below in 7.3.4 QSA key discovery.

For conformance to the "QSA Functional Profile", the _profile QSA key SHOULD be supported by the server to allow a client to make a list profiles request. For this request, the reserved token all SHOULD be used, e.g. _profile=alt.

For conformance to the "QSA Alternate Keywords Functional Profile", other key/value pairs MAY be used, such as _view=alternates but then the implementing server MUST supply a means of discovering that key, as per 7.3.4 QSA key discovery.

The server's response to a list profiles request SHOULD be to present a list of all profiles that it supports representations of the resource for and optionally also supported Media Types for those representations.

The server SHOULD represent the alternate profiles information in the HTTP header of the response, as per the HTTP Headers functional profile (using a Link header) and it MAY also represent the information in the response body in place of the default profile representation of a resource. This body content allowance is to enable humans to read alternate profile-conformant representation options for a resource easily in a web browser without having to view lower-level HTTP information.

Where a server does provide alternate profiles information in an HTTP body, the server MAY allow clients to negotiate for particular Media Types of the response by using the same Media Type negotiation method used for the get resource by profile function below.

An example request for the alternate profile representations of a resource to be delivered as HTTP body content as well as HTTP header content in the JSON format could look like Example 16

Example 16: Requesting 'list profiles' by QSA with both HTTP header and body responses

GET /resource/a?_profile=alt&_mediatype=application/json HTTP/1.1

---

# The response shows that representations of the resource can be delivered according
# to two profiles identified by the tokens profile-x & profile-y
# and that profile-x-conformant representations are available in XML & JSON
# where as profile-y-conformant representations are only available in XML

# The content in the JSON body of the response is equivalent to that of the Link header
# and can easily be mapped to the Alternate Representations Data Model, just as the Link
# information is in Figure 3.

# Both the Link header and the JSON body include profile URI/token mappings

HTTP/1.1 200 OK
Content-Type: application/json
Link: <http://www.w3.org/ns/dx/connegp/profile/qsa>; rel="profile",
      <http://example.org/resource/a?_profile=profile-x&_mediatype=application/json>;
          rel="canonical";
          type="application/json";
          format="http://otherexample.org/profile/x",
      <http://example.org/resource/a?_profile=profile-x&_mediatype=text/xml>;
          rel="alternate";
          type="text/xml";
          format="http://otherexample.org/profile/x",
      <http://example.org/resource/a?_profile=profile-y&_mediatype=text/xml>;
          rel="alternate";
          type="text/xml";
          format="http://otherexample.org/profile/y"

{
    "resource": "http://example.org/resource/a",
    "profiles": [
        {
            "token": "profile-x",
            "uri": "http://otherexample.org/profile/x",
            "media_types": ["application/json", "text/xml"]
        },
        {
            "token": "profile-y",
            "uri": "http://otherexample.org/profile/y",
            "media_types": ["text/xml"]
        }
    ]
}

Implementations of this specification according to the QSA Functional Profiles MUST communicate their alternate representations information as per the Alternate Representations Data Model. They MAY do so using HTTP Link headers, as per the HTTP Headers functional profile, or they MAY use other approaches.

As noted in [RFC8288] (Web Linking)'s introduction, HTML and some other data models have "well-defined concepts of linking" so QSA implementers MAY implement the communication of Alternate Representations Data Model information via HTTP body content, perhaps in HTML or other data models/formats. This might assist human client users of QSA implementations by being visible either in a web browser or within a downloadable file.

An potential HTML expression of the Link header information in Example 10 is given in Example 17 below. Note that Example 16 (above) gives a potential JSON format expression of Link header information according to the Alternate Representations Data Model.

Example 17: HTML expression of previous example's Link header information

# Link headers from previous example with one altered to show Blank Node v.
# absolute URIs for altp:Representation class instance
# (<http://example.org/resource/a>; → <http://example.org/resource/different>;)
Link:
  <http://example.org/resource/a>;
          rel="canonical";
          type="text/turtle";
          format="urn:example:profile:x",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/turtle";
          format="urn:example:profile:y",
  <http://example.org/resource/a>;
          rel="alternate";
          type="application/xml";
          format="urn:example:profile:x",
  <http://example.org/resource/different>;
          rel="alternate";
          type="application/xml";
          format="urn:example:profile:y",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/html"

# Link headers above represented HTML, assuming the Alternate Profile's rdfs:Resource
# is known from the request that generated this response and not given in the HTML
# content
<h3>Alternate Representations</h3>
<table>
  <thead>
    <tr>
      <th>Link to Representation</th>
      <th>Profile</th>
      <th>Media Type</th>
      <th>Is Default?</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td><a href="?_profile=x">Profile X, RDF</a></td>
      <td><code>urn:example:profile:x</code></td>
      <td><a href="https://w3id.org/mediatype/text/turtle">RDF (turtle)</a></td>
      <td>yes</td>
    </tr>
    <tr>
      <td><a href="?_profile=y&_mediatype=text/turtle">Profile Y, RDF</a></td>
      <td><code>urn:example:profile:y</code></td>
      <td><a href="https://w3id.org/mediatype/text/turtle">RDF (turtle)</a></td>
      <td>-</td>
    </tr>
    <tr>
      <td><a href="?_profile=x&_mediatype=application/xml">Profile X, XML</a></td>
      <td><code>urn:example:profile:x</code></td>
      <td><a href="https://w3id.org/mediatype/application/xml">XML</a></td>
      <td>-</td>
    </tr>
    <tr>
      <td><a href="http://example.org/resource/different?_mediatype=application/xml">Profile Y, XML</a></td>
      <td><code>urn:example:profile:y</code></td>
      <td><a href="https://w3id.org/mediatype/application/xml">XML</a></td>
      <td>-</td>
    </tr>
    <tr>
      <td><a href="?_mediatype=text/html">No Profile, HTML</a></td>
      <td>-</td>
      <td><a href="https://w3id.org/mediatype/text/html">HTML</a></td>
      <td>-</td>
    </tr>
  </tbody>
</table>

Currently, the convention in HTTP content negotiation by Media Type uses tokens for Media Types, such as text/html or application/ld+json with the tokens registered at IANA's Media Types list and Content Negotiation by Profile system implementers SHOULD use tokens from that list for Media Type identifiers and follow HTTP content negotiation best practice for identifiers for other content negotiation dimensions (language etc.).

Note: URI use for Media Types

Several initiatives exist that have created URIs for Media Types based on IANA's tokens, such as conneg.info. These URIs may be used to indicate Media Types.

There is no proposal to create a central register of profiles, as this is thought by these authors to be unsustainable in the long term, given the likely numbers of profiles to be established and likely community- specific nature of profiles (individual communities will create profiles for their own needs that will not be widely relevant).

As per 6.2 Profile Identification, all profiles MUST be identified by URI since URIs are universally unique and therefore do not require registration to avoid identifier duplication. However, systems conforming to either of the QSA functional profiles of this specification, instead of using URIs to identify profiles during client/server interactions, MAY use un-registered and non-universally unique tokens to identify profiles but, if they do, they MUST provide a way for clients to discover profile token/URI mappings.

QSA servers wishing to make tokens for profile URIs available to clients SHOULD follow the instructions provided for the HTTP Headers functional profile in 7.2.1.2 Token mappings.

Resource URLs for which QSA-based profile negotiation is taking place SHOULD NOT themselves be QSA values of other resource URIs in any QSA-based system. Such mechanics may be used internally and are used by legacy systems for profile negotiation but are best hidden from to the client to make conformance to these QSA profiles more recognizable. Example 18 shows this.

Example 18: Resource URLs must not, themselves, be parameters of other URLs

For the representation of Resource X, according to Profile Y, in Media Type Z:

Rather than:
GET /single/endpoint \
            ?resource=http://example.org/resource/X \
            &_profile=Y \
            &_mediatype=Z HTTP/1.1

Use:
GET /resource/X?_profile=Y&_mediatype=Z HTTP/1.1

To be conformant with the "QSA Functional Profile" profile of this specification, a server MUST allow clients to request resources according to profiles they identify with a _profile query string. Since either tokens or URIs may be used to identify a profile, servers MUST accept either. Servers MAY accept both encoded and un-encoded URIs but MAY also only accept one or the other. URIs MUST be enclosed in angled brackets, '<' & '>'.

To be conformant with the "QSA Alternate Keywords Functional Profile" profile of this specification, a server MUST allow clients to request resources according to profiles they identify with a key of the server implementor's choosing but then the server MUST also supply a means of discovering that key, as per 7.3.4 QSA key discovery.

A QSA server implementing get resource by profile SHOULD allow a client to indicate a preference for representations of the resource according to any one of a number of profiles. Such a request MUST indicate profile preference in by inclusion of an ordered list of profile identifiers (URIs or tokens) within the value of the QSA key/value pair used to identify profiles. For example, a client preferring resource representations according to profile-z and then http://example.org/profile/y and finally profile-x, in that preference order, could make a request like this:

GET /resource/a?_profile=profile-z,<http://example.org/profile/y>,profile-x

Servers MUST indicate the profile actually returned by including a Link HTTP header with rel="profile" in the response and MAY also indicate the returned profile in other ways. Servers SHOULD support escaped URIs and MAY also support un-escaped URIs identifying profiles, or both.

A server implementing multiple Media Type formats for its resource representations SHOULD allow a client to specify a preference order for them in a similar way.

This function is only relevant for servers claiming conformance to the "QSA Alternate Keywords Functional Profile" profile of this specification.

Servers claiming conformance to the "QSA Alternate Keywords Functional Profile" MUST implement methods to allow clients to discover the QSA key used in place of the "QSA Functional Profile"'s _profile and also the equivalent of the _profile=alt that is required to be implemented by any key/value combination. This allows clients with little knowledge of the server to discover how to create list profiles and get resource by profile requests.

Servers SHOULD also allow clients to discover the QSA keys used to indicate Media Type and other content negotiation dimensions.

A server responding to any request for a resource for which "QSA Alternate Keywords Functional Profile" is supported SHOULD include HTTP headers that indicate alternate profiles and Media Types, as per the HTTP Functional Profile. They MAY instead, or in addition, provide HTTP body content indicating the same information. If they do, such information SHOULD be present in the default response to a URI request, i.e. in response to a request without any QSAs. A series of example requests is given in Example 19.

Example 19: Example requests and responses for QSA key discovery

# A client makes a request for Resource A not knowing if any Content
# Negotiation by Profile is supported. It supplies an Accept-Profile
# header just in case. For extra efficiency, the client could have
# made a HEAD request instead of a GET

GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>

# The server does not understand the HTTP Get Resource By Profile
# request (doesn't support the HTTP Headers Functional Profile) but is
# able to supply an HTTP Link header indicating alternate resource
# representations. It can be seen from the Link header that keys other
# than _profile & _mediatype are in use - view & format - thus this is
# QSA Alt, not a QSA Functional Profile-conformant system

# The resource representations available conform to profile-x & profile-y.
# The profile-x-conformant representation is available in HTML & Turtle,
# the profile-y-conformant representation is available only in XML

HTTP/1.1 200 OK
Link:
  <http://example.org/resource/a?view=profile-x&format=text/html>;
          rel="canonical";
          type="text/html";
          format="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-x&format=text/turtle>;
          rel="alternate";
          type="text/turtle";
          format="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-y&format=text/xml>;
          rel="alternate";
          type="application/xml";
          format="http://otherexample.org/profile/y"

# Note that here the server does not directly indicate the profile served
# (there is no Link header with rel="profile" present) but this can be inferred
# by the link header with rel="canonical"

While the Link header in Example 19 above communicates all the information that a list profiles request does, it is not visible directly in a web browser. Example 16 shows a requests/response pair that include equivalent Link header and HTTP body information listing profiles, the latter of which is visible in a browser but a client formulating this request is dependent on a it knowing that the QSA key/value pair _profile=alt is used to trigger this response as opposed to the server's default resource representation.

To communicate to a client what QSA key/value pair is used for list profiles when the "QSA Alternate Keywords Functional Profile" is conformed to, a server SHOULD, following the methods above for list profiles communication, indicate that a representation of the resource is available that conforms to the Alternate Profiles Data Model identified by the URI http://www.w3.org/ns/dx/conneg/altr. This is demonstrated in Example 20 which is an extension to Example 19 .

Example 20: Extension of previous example showing of Alternate Profiles Data Model-conformant responses

GET /resource/a HTTP/1.1
Accept-Profile: <http://example.org/profile/x>

--

HTTP/1.1 200 OK
Link:
  <http://example.org/resource/a?view=profile-x&format=text/html>;
          rel="canonical";
          type="application/html";
          format="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-x&format=text/turtle>;
          rel="alternate";
          type="text/turtle";
          format="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-y&format=text/xml>;
          rel="alternate";
          type="application/xml";
          format="http://otherexample.org/profile/y"
  <http://example.org/resource/a?view=altrep&format=application/ld+json>;
          rel="alternate";
          type="application/ld+json";
          format="http://www.w3.org/ns/dx/connegp/altr"

[default response content]

Example 20 shows that for resource /resource/a there is a representation of it that conforms to the specification/profile http://www.w3.org/ns/dx/connegp/altr which is the URI identifying the Alternate Profiles Data Model defined in 6.4 Alternate Representations Data Model.

The example also shows the QSA view=altrep can be used to formulate a request for a Alternate Profiles Data Model-conformant response. Dereferencing http://example.org/resource/a?view=altrep will therefore generate a response that also yields equivalent content to the Link header content in Example 20 rather than the default representation of /resource/a.

The requirements that need to be met for demonstrations of conformance to the Functional Profiles in this specification are given below, per Functional Profile.

Systems that test for or demonstrate conformance to this specification should do so with reference to the Requirements IDs given here. For example, when demonstrating conformance to the QSA Functional Profile, the requirement R.2.1.a with the requirement text A profile that a resource representation conforms to is indicated by token which MUST be appended to the resource's URI as a Query String Argument. must be met and a server's implementation of that requirement must be demonstrable.

R.1.1.a: From 7.2.1 List Profiles:
A server implementing content negotiation by profile SHOULD return an HTTP Link header containing information about the default and any alternate representations of that resource including profiles they conform to.
R.1.1.b: From 7.2.1 List Profiles:
The default representation – the one that will be returned when no specific representation is requested – SHOULD be identified by rel="canonical", other representations by rel="alternate"
R.1.2.a: From 7.2.2 Get Resource by Profile:
A server implementing content negotiation by profile MUST respond with an HTTP Response header containing a Link header with rel="profile" indicating the profile returned.
R.1.2.b: From 7.2.2 Get Resource by Profile:
URIs referenced in Accept-Profile headers MUST be enclosed in angled brackets, '<' & '>'.
R.1.2.c: From 7.2.2 Get Resource by Profile:
A range of acceptable profile URIs MAY be supplied, and if they are, they MUST be delimited by a comma or be in separate Accept-Profile headers.
R.1.2.d: From 7.2.2 Get Resource by Profile:
Preferences MAY be indicated by by the Client using quality indicators (q-values) as an ordering mechanism separated from the URI by a semi-colon, ';'. An example of a URI (in this case a URN) with a q-value is <urn:example:profile:x>;q=1.0, where the URI is <urn:example:profile:x> and the q-value is q=1.0.

R.2.1.a: From 7.3.1.1 QSA URI description:
A profile that a resource representation conforms to is indicated by token which MUST be appended to the resource's URI as a Query String Argument.
R.2.1.b: From 7.3.2.3 Resource URL:
Resource URLs for which QSA-based profile negotiation is taking place SHOULD NOT themselves be QSA values of other resource URIs in any QSA-based system.
R.2.1.c: From 7.3.1.1 QSA URI description:
[the] token MUST be mappable to a URI within one particular client/server session
R.2.1.d: From 7.3.1.1 QSA URI description:
Additional aspects of content negotiation MAY be included in such URIs by the use of additional QSA or by any other techniques (for example HTTP headers) but, if they are, they MUST NOT change the actions of the request for content negotiation by profile.
R.2.2.a: From 7.3.1.2 Key naming:
To conform to the "QSA Functional Profile", the QSA key _profile MUST be used to indicate a profile token
R.2.2.b: From 7.3.1.2 Key naming:
the key _mediatype SHOULD be used to indicate a resource representation's Media Type
R.2.2.c: From 7.3.2.2 Token mappings:
tokens registered at IANA's Media Types list SHOULD be used as tokens for Media Type identifiers
R.2.3.a: From 7.3.2 List Profiles:
the QSA key/value pair _profile=alt SHOULD be supported by the server to allow a client to make a list profiles request
R.2.3.b: From 7.3.2 List Profiles:
The server's response to a list profiles request SHOULD be to present a list of all profiles that it supports representations of the resource for and optionally also supported Media Types for those representations.
R.2.3.c: From 7.3.2 List Profiles:
The server SHOULD represent the alternate profiles information in the HTTP header of the response, as per the HTTP Headers functional profile (using a Link header)
R.2.3.d: From 7.3.2 List Profiles:
[the server] MAY also represent the information in the response body in place of the default profile representation of a resource
R.2.3.e: From 7.3.2 List Profiles:
Where a server does provide alternate profiles information in an HTTP body, the server MAY allow clients to negotiate for particular Media Types of the response by using the same Media Type negotiation method used for the get resource by profile function
R.2.4.a: From 7.3.2.1 QSA Alternate Representations Data Model Implementation:
Implementations of this specification according to the QSA Functional Profiles MUST communicate their alternate representations information as per the Alternate Representations Data Model
R.2.4.b: From 7.3.2.1 QSA Alternate Representations Data Model Implementation:
They MAY do so using HTTP Link headers, as per the HTTP Headers functional profile, or they MAY use other approaches.
R.2.4.c: From 7.3.2.1 QSA Alternate Representations Data Model Implementation:
They may do so via HTTP body content, perhaps in HTML or other data models/formats

R.3.1.a: From 7.3.1.1 QSA URI description:
profile requested for the resource representation is indicated by [a] token ... which MUST be appended to the resource's URI as a Query String Argument.
R.3.1.b: From 7.3.2.3 Resource URL:
Resource URLs for which QSA-based profile negotiation is taking place SHOULD NOT themselves be QSA values of other resource URIs in any QSA-based system.
R.3.1.c: From 7.3.1.1 QSA URI description:
[the] token MUST be mappable to a [profile] URI within one particular client/server session
R.3.1.d: From 7.3.1.1 QSA URI description:
Additional aspects of content negotiation MAY be included in such URIs by the use of additional QSA or by any other techniques (for example HTTP headers) but, if they are, they MUST NOT change the actions of the request for content negotiation by profile.
R.3.2.a: From 7.3.1.2 Key naming:
a QSA key MUST be used to indicate a profile token
R.3.2.b: From 7.3.4 QSA key discovery:
[the server] MUST implement methods to allow clients to discover the QSA key used in place of the "QSA Functional Profile"'s _profile
R.3.2.c: From 7.3.1.2 Key naming:
a QSA key SHOULD be used to indicate a resource representation's Media Type
R.3.2.d: From 7.3.4 QSA key discovery:
if a QSA key indicating a resource representation's Media Type is implemented, the server MUST implement methods to allow clients to discover the QSA key used in place of the "QSA Functional Profile"'s _mediatype
R.3.2.e: From 7.3.2.2 Token mappings:
tokens registered at IANA's Media Types list SHOULD be used as tokens for Media Type identifiers
R.3.3.a: From 7.3.2 List Profiles:
the QSA key/value pair x=y where x is the server's equivalent to _profile and y is the server's equivalent to alt SHOULD be supported by the server to allow a client to make a list profiles request
R.3.2.b: From 7.3.4 QSA key discovery:
The server MUST implement methods to allow clients to discover the QSA key/value pair used in place of the "QSA Functional Profile"'s _profile=alt
R.3.3.c: From 7.3.2 List Profiles:
The server's response to a list profiles request SHOULD be to present a list of all profiles that it supports representations of the resource for and optionally also supported Media Types for those representations.
R.3.3.d: From 7.3.2 List Profiles:
The server SHOULD represent the alternate profiles information in the HTTP header of the response, as per the HTTP Headers functional profile (using a Link header)
R.3.3.e: From 7.3.2 List Profiles:
[the server] MAY also represent the information in the response body in place of the default profile representation of a resource
R.3.3.f: From 7.3.2 List Profiles:
Where a server does provide alternate profiles information in an HTTP body, the server MAY allow clients to negotiate for particular Media Types of the response by using the same Media Type negotiation method used for the get resource by profile function
R.3.4.a: From 7.3.2.1 QSA Alternate Representations Data Model Implementation:
Implementations of this specification according to the QSA Functional Profiles MUST communicate their alternate representations information as per the Alternate Representations Data Model
R.3.4.b: From 7.3.2.1 QSA Alternate Representations Data Model Implementation:
They MAY do so using HTTP Link headers, as per the HTTP Headers functional profile, or they MAY use other approaches.
R.3.4.c: From 7.3.2.1 QSA Alternate Representations Data Model Implementation:
[They may do so] via HTTP body content, perhaps in HTML or other data models/formats

This specification contains a number of distinct functional profiles that are identified and described in words in 7.1 Functional Profiles of this specification. This appendix presents descriptions of these functional profiles, and the relations between them, according to the Profiles Vocabulary [DX-PROF].

The RDF (turtle syntax) code in Code Listing 1 defines Content Negotiation by Profile as a dct:Standard, the definition of which in [DX-PROF] matches the definition of specification in this document. Note that, since this document is describing behaviours, this specification is a functional specification. The 4 profiles of it are then, as per regular PROF modelling, termed prof:Profiles. These 4 functional profiles are presented in a hierarchy with the profiles either directly profiling the standard or, in the case of the QSA Functional Profile, profiling another profile that then profiles the standard. This is also shown graphically in Figure 4 below the code listing.

The code presented in Code Listing 1 is also available in the RDF file profiles.ttl.

The reason that the QSA Functional Profile profile is modelled as profiling the QSA Alternate Keywords Functional Profile profile is that the QSA Functional Profile profile is a more constrained 'narrower' specification of Content Negotiation by Profile than QSA Alternate Keywords Functional Profile and anything that is conformant with the QSA Functional Profile profile would necessarily by conformant with the QSA Alternate Keywords Functional Profile profile which thus meets the [DX-PROF] definition of what it means to be the profile of something.

CODE LISTING 1: Description of this specification and its profiles, as listed in 7.1 Functional Profiles of this specification, using the Profiles Vocabulary.

@prefix dct: <http://purl.org/dc/terms/> . @prefix prof: <http://www.w3.org/ns/dx/prof/> . @prefix role: <http://www.w3.org/ns/dx/prof/role/> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix skos: <http://www.w3.org/2004/02/skos/core#> . @prefix cnpr: <http://www.w3.org/ns/dx/connegp/profile/> . <https://www.w3.org/TR/dx-connegp/> a dct:Standard ; rdfs:label "Content Negotiation by Profile" ; rdfs:comment "W3C Recommendation (a standard) for Content Negotiation by Profile"@en . cnpr:http a prof:Profile ; prof:isProfileOf <https://www.w3.org/TR/dx-connegp/> ; rdfs:label "HTTP Headers Functional Profile" ; rdfs:comment "For conformance with the functional profile of Content Negotiation by Profile presented in § 7.1 Hypertext Transfer Protocol Headers."@en ; skos:scopeNote "To be used if a resource conforms to the HTTP Headers functional profile"@en . cnpr:qsa a prof:Profile ; prof:isProfileOf cnpr:qsa-alt ; rdfs:label "QSA Functional Profile"@en ; rdfs:comment "For conformance with the functional profile of Content Negotiation by Profile presented in § 7.2 URL Query String Arguments."@en ; skos:scopeNote "To be used if a resource conforms to the QSA Functional Profile using the Query String Arguments _profile and _mediatype as per the recommendations in § 7.2 URL Query String Arguments."@en . cnpr:qsa-alt a prof:Profile ; prof:isProfileOf <https://www.w3.org/TR/dx-connegp/> ; rdfs:label "QSA Alternate Keywords Functional Profile" ; rdfs:comment "For conformance with the functional profile of Content Negotiation by Profile presented in § 7.2 URL Query String Arguments."@en ; skos:scopeNote "To be used if a resource conforms to the QSA Functional Profile but uses alternate keywords for the Query String Arguments _profile and _mediatype, as allowed by the recommendations in § 7.2 URL Query String Arguments."@en . cnpr:rrd a prof:Profile ; prof:isProfileOf <https://www.w3.org/TR/dx-connegp/> ; rdfs:label "Resource Representation Description Profile"@en ; rdfs:comment "For conformance with Content Negotiation by Profile § 6.2.2 get resource by profile."@en ; skos:scopeNote "To be used if a resource representation is able to indicate which profile(s) it conforms to, in its appropriate functional profile, as per the abstract specification in § 6.2.2 get resource by profile."@en .

Figure 4 The specification and profiles of this Content Negotiation by Profile standard shown in a [[PROF] profiles hierarchy.

With the identification of functional profiles of this specification given in 7.1 Functional Profiles of this specification and their relations described using the Profiles Vocabulary [DX-PROF] in this appendix, it is possible for systems to show conformance to this specification or any functional profile of it using [DX-PROF] mechanisms. This is done using the [DCTERMS] predicate dct:conformsTo so that, for example, a system identified with the URI <http://example.org/system/a> claiming to conform to a specification or functional profile identified by URI <SPEC_OR_PROFILE_URI> would do so like this:

<http://example.com/system/a> dct:conformsTo <SPEC_OR_PROFILE_URI> .

The <SPEC_OR_PROFILE_URI> may be this specification's URI, https://www.w3.org/TR/dx-connegp/, but in the best case, would be one of the profile URIs listed in 7.1 Functional Profiles of this specification or another functional profile's URI, since it is much clearer what is being conformed to when functional profile URIs are cited as they are narrower in scope than the specification as a whole.

A system wishing to claim conformance to multiple conformance targets - the specification or functional profiles of it - may do so with multiple uses of dct:conformsTo.

The code in Code Listing 2 shows an imaginary Web Service documented using [VOCAB-DCAT-2] and borrowing parts from its examples, such as Example 49. Included is the predicate dct:conformsTo used as per [VOCAB-DCAT-2] & [DX-PROF]. Conformance here is claimed to the QSA Alternate Keywords Functional Profile profile which is indicated by the URI http://www.w3.org/ns/dx/connegp/profile/qsa-alt, identified as per 7.1 Functional Profiles of this specification.

CODE LISTING 2: An example Web Service claiming conformance to the QSA Alternate Keywords Functional Profile of this specification

<http://example.com/service/xx> a dcat:DataService ; dct:title "Web Service XX" ; dct:description "A dummy Web Service claiming conformance to a profile of the Content Negotiation by Profile specification also annotated with other DCAT-2 recommended properties."@en ; # URI for the QSA Alternate Keywords Functional Profile dct:conformsTo <http://www.w3.org/ns/dx/connegp/profile/qsa-alt> ; # it's a public service dct:accessRights <http://publications.europa.eu/resource/authority/access-right/PUBLIC> # where the service actually is, online dcat:endpointURL <http://example.com/service/v2/xx> ; # a human- and machine-readable documentation endpoint for the service using the # Swagger UI system dcat:endpointDescription <http://example.com/service/v2/xx/swagger> ;

6.4 Alternate Representations Data Model presents an abstract model, that is, one without implementation in any concrete modelling system. This appendix presents both an implementation of this model in OWL [OWL2-OVERVIEW] and extensions to the model suggested for use in particular scenarios.

A Web Ontology Language [OWL2-OVERVIEW] implementation of the data model in 6.4 Alternate Representations Data Model is given below in Code Listing 3. It is also available in the file altr.ttl.

CODE LISTING 3: Alternate Profiles Data Model as an OWL ontology

@prefix altr: <http://www.w3.org/ns/dx/connegp/altr#> . @prefix dct: <http://purl.org/dc/terms/> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> . @prefix sdo: <http://schema.org/> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix skos: <http://www.w3.org/2004/02/skos/core#> . <http://www.w3.org/ns/dx/connegp/altr> a owl:Ontology ; rdfs:label "Alternative Profiles Ontology" ; rdfs:comment """This ontology allows for the description of representations of Internet resources. Representations may conform to dct:Standard instances and may have the format of a particular dct:MediaType."""@en ; dct:created "2019-08-07"^^xsd:date ; dct:modified "2019-08-10"^^xsd:date ; dct:creator [ a sdo:Person ; sdo:affiliation [ sdo:name "SURROUND Australia Pty Ltd" ; sdo:url <https://surroundaustralia.com> ] ; sdo:email <mailto:[email protected]> ; sdo:identifier <http://orcid.org/0000-0002-8742-7730> ; sdo:name "Nicholas J. Car" ] . dct:conformsTo a owl:ObjectProperty ; rdfs:label "conforms to" ; rdfs:range dct:Standard ; skos:scopeNote "Use this property to indicate the data profile that the altr:Representation conforms to." . altr:hasRepresentation a owl:ObjectProperty ; rdfs:label "has representation" ; skos:definition "Indicates a Representation of a Resource."@en ; rdfs:domain rdf:Resource ; rdfs:range altr:Representation ; skos:scopeNote "Use this property to indicate the HTTP-delivered representation of a resource." . altr:hasDefaultRepresentation a owl:ObjectProperty ; rdfs:label "has default representation" ; skos:definition "Indicates the default Representation of a Resource."@en ; rdfs:subPropertyOf altr:hasRepresentation ; skos:scopeNote "Use this property to indicate the default HTTP-delivered representation of a resource that is obtained when no further instructions are given to a server to obtain a resource's representation other than the identification (URI) of the resource" . rdf:Resource a owl:Class ; rdfs:label "Resource" ; skos:definition "The class resource, everything."@en ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty altr:hasRepresentation ; owl:allValuesFrom altr:Representation ] ; dct:source "http://www.w3.org/2000/01/rdf-schema#Resource" ; skos:scopeNote "In the context of this mode, rdf:Resource instances are used to identify Internet resources, that is items identified by a URI." . altr:Representation a owl:Class ; rdfs:label "Representation" ; skos:definition "An abstraction of the current or desired state of a thing in HTTP communications."@en ; rdfs:subClassOf [ a owl:Restriction ; owl:onProperty dct:conformsTo ; owl:allValuesFrom dct:Standard ] ; dct:source <https://httpwg.org/specs/rfc7230.html> ; rdfs:isDefinedBy <http://www.w3.org/ns/dx/connegp/altr> ; skos:scopeNote "Use this class to indicate instances of representations of resources" . dct:Standard a owl:Class ; rdfs:label "Standard" ; skos:definition "A basis for comparison; a reference point against which other things can be evaluated."@en ; dct:source "http://purl.org/dc/terms/Standard" ; skos:scopeNote "In the context of this mode, use this class to indicate instances of information models that representations of resources can conform to." .

The Alternate Profiles Data Model may be extended to include additional information of use in content negotiation by profile situations. One obviously useful extension is the inclusion of information about other dimensions of content negotiation, particularly Media Type. Code Listing 3 includes RDF definitions of Dublin Core Term's [DCTERMS] dct:format property and dct:MediaType class for Media Type indications that could be added to the Data Model, as represented in OWL in Code Listing 4. Example 22 gives an example of this extended model's use following on from the content in Example 23.

CODE LISTING 4: Suggested extension to this specification's Alternate Profiles Data Model in OWL to cater for Media Type representations

@prefix ex: <http://example.org/altr-ext#> . @prefix dct: <http://purl.org/dc/terms/> . @prefix owl: <http://www.w3.org/2002/07/owl#> . @prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> . @prefix skos: <http://www.w3.org/2004/02/skos/core#> . @prefix xsd: <http://www.w3.org/2001/XMLSchema#> . dct:format a owl:ObjectProperty ; rdfs:label "format" ; skos:definition "The file format, physical medium, or dimensions of the resource."@en ; dct:source dct:format ; rdfs:range dct:MediaType ; skos:scopeNote "Use this property to indicate an IANA Media Type of a resource's representation " . ex:isProfilesDefault a owl:DataTypeProperty ; rdfs:label "is profile's default" ; skos:definition "Indicates the default Representation for Resource for the specified Standard."@en ; rdfs:range xsd:boolean ; skos:scopeNote "Use this property to indicate which of more than one resource representations that conforms to a profile is the default for get resource by profile requests." . dct:MediaType a owl:Class ; rdfs:label "Media Type" ; skos:definition "A file format or physical medium."@en ; dct:source "http://purl.org/dc/terms/MediaType" ; skos:scopeNote "In the context of this mode, use this class to indicate the IANA Media Type of a resource's representation." .

Example 22: Extended implementation of the Alternative Profiles data model in RDF (turtle) showing Media Type information

@prefix altr: <http://www.w3.org/ns/dx/connegp/altr#> .
@prefix dct: <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 xsd: <http://www.w3.org/2001/XMLSchema#> .

# This Resource A has 5 Representations, the 3rd of which is the default.
# Some of the Representations conform to the same Standard but are formatted
# according to different Media Types. Some Representations contain no Media
# Type information.
<http://example.org/resource/a>
    a rdf:Resource ;
    rdfs:label "Resources A" ;
    altr:hasRepresentation :rep-1 , :rep-2 , :rep-3 , :rep-4 , :rep-5 ;
    altr:hasDefaultRepresentation :rep-3 .

:rep-1
    a altr:Representation ;
    dct:conformsTo <http://otherexample.org/profile/x> ;
    dct:format "application/xml" .

:rep-2
    a altr:Representation ;
    dct:conformsTo <http://otherexample.org/profile/y> .

# This representation is the default for the set of representations
# that conform to <http://otherexample.org/profile/z>
:rep-3
    a altr:Representation ;
    dct:conformsTo <http://otherexample.org/profile/z> .
    dct:format "text/html" ;
    ex:isProfilesDefault "true" .

:rep-4
    a altr:Representation ;
    dct:conformsTo <http://otherexample.org/profile/z> ;
    dct:format "text/turtle" .

:rep-5
    a altr:Representation ;
    dct:conformsTo <http://otherexample.org/profile/z> ;
    dct:format "application/ld+json" .

An example instance of RDF data created conforming to the OWL implementation of the Alternative Profiles Data Model Example 23 followed by the same content shown in multiple formats in Example 24.

Example 23: Implementation of the Alternative Profiles Data Model in RDF (turtle)

@prefix altr: <http://www.w3.org/ns/dx/connegp/altr#> .
@prefix dct: <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#> .

# This Resource A has 3 Representations, the 3rd of which is the default
<http://example.org/resource/a>
    a rdf:Resource ;
    rdfs:label "Resources A" ;
    altr:hasRepresentation :rep-1 , :rep-2 , :rep-3 ;
    altr:hasDefaultRepresentation :rep-3 .

# Each Representation and the Standard each conforms to, X, Y & Z
:rep-1
    a altr:Representation ;
    dct:conformsTo <http://otherexample.org/profile/x> .

:rep-2
    a altr:Representation ;
    dct:conformsTo <http://otherexample.org/profile/y> .

:rep-3
    a altr:Representation ;
    dct:conformsTo <http://otherexample.org/profile/z> .

Example 24: Multiple format implementation of the previous example's content

# The content of the previous example expressed as in an HTTP Link header
# as per the HTTP Application Profile of this Specification with the
# default Representation indicated by the use of rel="canonical". Note the
# Representations are seen, one per Link result comma-separated, identified
# only by the combination of the Resource URI, the URI of the Standard to
# which they conform and the rel attribute - they do not have individual
# identifiers
Link:
  <http://example.org/resource/a>;
          rel="alternate";
          format="http://otherexample.org/profile/x",
  <http://example.org/resource/a>;
          rel="alternate";
          format="http://otherexample.org/profile/y",
  <http://example.org/resource/a>;
          rel="canonical";
          format="http://otherexample.org/profile/z"

---

# The content of the previous example expressed as in table form
# such as could potentially be expressed in the HTML body of an HTTP
# response. The Resource URIs include Query String Arguments that,
# when specified, allow the individual Representations to be returned,
# as per the QSA Application Profile below.
---------------------------------------------------------------------------------------
| Shortened Resource URI                | URI of profile conformed to       | Default |
---------------------------------------------------------------------------------------
| http://.../resource/a?_profile=prof-x | http://otherexample.org/profile/x |         |
| http://.../resource/a?_profile=prof-y | http://otherexample.org/profile/y |         |
| http://.../resource/a?_profile=prof-z | http://otherexample.org/profile/z | Yes     |
---------------------------------------------------------------------------------------

A DCAT [VOCAB-DCAT-2] dcat:Dataset may be accessible via a dcat:DataService, and that service may support one or more functional profiles of this specification. In this case, support should be declared by the service's reference to relevant functional profiles using the predicate dct:conformsTo, as illustrated in Code Listing 5.

Note that DCAT 2 provides no canonical means to specify if a data service allows individual data items in the dataset it provides access to, to be accessed by identifier, so this example relates to the dataset distributed as a whole. The use of dct:conformsTo would nevertheless apply to data services which declare a mechanism to access individual items. This mechanism may be identified via the dcat:endpointDescription.

Issue 1146

CODE LISTING 5: Describing a DCAT Data Service supporting Content Negotiation by Profile

@prefix ex: <http://example.org#> . @prefix dcat: <http://www.w3.org/ns/dcat#> . @prefix dct: <http://purl.org/dc/terms/> . @prefix prof: <http://www.w3.org/ns/dx/prof/> . # A Dataset has a Distribution :aDataset dcat:distribution :aDatasetDistribution . # A data profile that the Distribution conforms to ex:someDataProfile a prof:Profile ; # profile details . # A Distribution that can be accessed by a DataService that support Content # Negotiation by Profile. The Distribution's content conforms to the Profile above :aDatasetDistribution a dcat:Distribution ; dct:conformsTo ex:someDataProfile ; dcat:accessService ex:connegDataAccessService . # The Service used to access the Dataset's Distribution. The Service itself conforms # to two functional profiles of Content Negotiation by Profile ex:connegDataAccessService a dcat:DataService ; dct:conformsTo <http://www.w3.org/ns/dx/connegp/profile/http> , <http://www.w3.org/ns/dx/connegp/profile/qsa> ; # Declare that the Dataset may be invoked by URI, its id, using Content # Negotiation by Profile dcat:endPointURL :aDataset .

Content Negotiation by Profile

Abstract

Status of This Document

Overview of DXWG documents on profiles

1. Introduction

2. Conformance

3. Definitions

4. Motivation

5. Related Work

5.1 Existing standards for transporting profile information in HTTP headers

5.1.1 Using Accept/Content Type together with the profile parameter

5.1.2 Using a Link header with rel="profile" (RFC 6906)

5.1.3 Using the Prefer/Preference-Applied header fields (RFC 7240)

5.2 Archival Resource Key (ARK)

5.3 Linked Data APIs

5.4 OAI-PMH

5.5 Catalogue Service for the Web (CSW)

6. Abstract Model

6.1 Content Negotiation Background

6.2 Profile Identification

6.3 Requests and Responses

6.3.1 List Profiles

6.3.2 Get Resource by Profile

6.4 Alternate Representations Data Model

6.5 Order of Precedence for Implementation Profiles

7. Functional Profiles

7.1 Functional Profiles of this specification

7.2 Hypertext Transfer Protocol Headers

7.2.1 List Profiles

7.2.1.1 HTTP Alternate Representations Data Model Implementation

7.2.1.2 Token mappings

7.2.2 Get Resource by Profile

7.3 URL Query String Arguments

7.3.1 QSA Functional Profile description

7.3.1.1 QSA URI description

7.3.1.2 Key naming

7.3.2 List Profiles

7.3.2.1 QSA Alternate Representations Data Model Implementation

7.3.2.2 Token mappings

7.3.2.3 Resource URL

7.3.3 Get Resource by Profile

7.3.4 QSA key discovery

8. Link Attributes

8.1 Token

9. Test Suites

10. Implementations

11. Acknowledgements

12. Changes

12.1 Changes since previous draft

12.2 Features at Risk

13. Security and Privacy

A. Appendices

A.1 Itemized Requirements

A.1.1 HTTP Headers Functional Profile

A.1.2 Query String Arguments Functional Profile

A.1.3 Query String Arguments Alternate Keywords Functional Profile

A.2 Profiles Vocabulary descriptions of this specification's Functional Profiles

A.3 Demonstrating system conformance to Functional Profiles

A.4 Alternate Representations Data Model - Details

A.4.1 Implementations

A.4.2 Extensions

A.4.3 Examples of model use

A.5 Describing DCAT Distributions support of Content Negotiation by Profile

B. References

B.1 Normative references

B.2 Informative references