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.

Overview of DXWG documents on profiles

This document is one from set of documents on profiles, edited by the W3C Dataset Exchange Working Group (DXWG) and the Internet Engineering Taskforce (IETF). The DXWG documents are:

The following document, maintained under the auspicies of the IETF, establishes the technical foundations for this document but is not within the scope of the DXWG:

Introduction

Content delivered by dereferencing Internet identifiers can be the subject of negotiation in different ways. When using the HTTP protocol [[RFC9110]], a client may set one or more request headers:

However, clients have not had a defined way to negotiate for content based on its adherence to an information model: a standard, a specification or a profile. This document describes how such functionality can be delivered.

When online information about a resource adheres to one or more profiles, methods described here allow clients to request lists of those profiles and request content according to one or more of the profiles in order of preference.

For example, a catalog may offer choices of representations of a dataset's description that conform to different information models, perhaps [[VOID]], [[VOCAB-DATA-CUBE]] and [[VOCAB-DCAT]]. Furthermore, the [[VOCAB-DCAT]] representation might conform to the [[DCAT-AP]] profile, the [[GeoDCAT-AP]] profile and perhaps also an organisation-specific profile "MyOrgDCATProfile". These narrower profiles further constrain various elements of the dataset's description beyond the more general specification of which they are a profile. A request for information about possible representations of this dataset's description may ask for the list of available profiles that are available for the dataset, or may ask specifically for a representation conforming to one specific profile, for example [[GeoDCAT-AP]]. When no profile or an unsupported profile is requested, a server returns default content conforming to the default profile supported by the server.

When selecting a content negotiation mechanism, an Internet client may use the HTTP protocol, but it may also use other methods for providing instructions to a server. One potential mechanism is URL Query String Arguments (QSAs). QSAs are useful for humans and machines for situations where negotiation via HTTP is not practical, such as when manually entering requests into web browsers. This specification provides an abstract model of content negotiation by profile and presents guidance on the use of two specific methods that conform to the abstract model, HTTP and QSA.

The HTTP Header and URL QSA methods are defined as Functional Profiles of the Abstract Model. While this specification only describes these two Functional Profiles, it is expected that implementers will want to implement Functional Profiles of the Abstract Model for other environments, including environments that may be realized in the future.

Implementers will need to ensure that any Functional Profile they define implements the Abstract Model's functions and can deliver alternate representation information as per the Alternate Representations Data Model.

Describing how resource representations conform to profiles and how profiles and specifications relate to one + another is not part of this specification. Some aspects of those questions are addressed by the Profiles Vocabulary [[?DX-PROF]], also produced by the DXWG.

For the purpose of compliance, the normative sections of this document are , , and . Appendices are non-normative.

Specifications and Profiles to which the content of resource representations may conform will embody their own notions of conformance, which are out of scope for this specification.

Definitions

specification

A basis for comparison; a reference point against which other things can be evaluated.

Source: DCMI Metadata Terms [[DCTERMS]]'s definition for a Standard.

data specification

A specification, with human- and/or machine-processable representations, that defines the content and structure of data used in a given context.

Source: deliberations of the DXWG.

functional specification

A specification, with human- and/or machine-processable representations, that defines the behaviour of an application in a given context.

Source: deliberations of the DXWG.

profile

A specification that constrains, extends, combines, or provides guidance or explanation about the usage of other specifications.

If the specification profiled is a specialized type of specification, for example a data or a functional specification, the profile will be of the same sort - a data or functional profile.

This Content Negotiation by Profile specification concerns negotiation for data profiles, and specifies functional profiles for different ways of achieving this. In this document, most occurrences of the term "profile" refer to "data profile".

data profile

A data specification that constrains, extends, combines, or provides guidance or explanation about the usage of other data specifications.

This definition includes what are sometimes called "application profiles", "metadata profiles" or "metadata application profiles".

Source: deliberations of the DXWG.

functional profile

A functional specification that constrains, extends, combines, or provides guidance or explanation about the usage of other functional specifications.

Source: deliberations of the DXWG.

client
A program that establishes a connection to a server for the purpose of sending one or more HTTP requests. [[RFC9110]]
server
A program that accepts connections in order to service HTTP requests by sending HTTP responses. [[RFC9110]]
resource
The entity that is identified by a URI. Familiar examples include an electronic document, an image, a source of information with a consistent purpose. [[RFC3986]]
representation

An abstraction of the current or desired state of a thing in HTTP communications. [[RFC9110]]

In this specification, representations are of resources.

metadata
Information that is supplied about a resource. [[RFC3986]]
request
A message sent over the Internet, from a client to a server, for a information about a resource. [[RFC9110]]
response
A message sent over the Internet, from a server to a client answering a request for information about a resource. [[RFC9110]]
token
A short name identifying something. In the context of this document, tokens are sometimes used to identify profiles.

Namespaces

A full set of namespaces and prefixes used in this specification is given in the table below.

PrefixNamespace
altrhttp://www.w3.org/ns/dx/connegp/altr#
dcathttp://www.w3.org/ns/dcat#
dctermshttp://purl.org/dc/terms/
exhttp://example.com/
owlhttp://www.w3.org/2002/07/owl#
profhttp://www.w3.org/ns/dx/prof/
rdfshttp://www.w3.org/2000/01/rdf-schema#
sdohttps://schema.org/
skoshttp://www.w3.org/2004/02/skos/core#
xsdhttp://www.w3.org/2001/XMLSchema#

Motivation

In many cases, there are several ways to describe a resource within the scope of a single Media Type. For instance, XML documents, while conforming to the application/xml Media Type, may adhere to one of several DTDs or XML Schemas. RDF documents, with a choice of Media Type serializations such as text/turtle, application/rdf+xml and others, have a large number of vocabularies (classes and properties) available to use for their content's information model. When a client initiates a request for an Internet resource, such as an HTTP GET to retrieve a resource's representation, the client and server must have a standardized way to exchange information on how the transmitted resource will be structured according to DTDs, XML Schema, vocabularies or other standards, specifications or profiles. When using non-HTTP content negotiation, methods such as URIs with Query String Arguments have been previously implemented, such as the OAI-PMH [[OAI-PMH]] and OGC's CSW [[CSW]] protocols.

This document describes an abstract, functions-based, specification for content negotiation by profile and gives both an HTTP Headers functional profile and two Query String Argument-based functional profiles for the specification's implementation in different environments. The query string approaches provide both a "fall back" (a second, non-HTTP implementation of the abstract specification), as required by the Dataset Exchange Working Group's Charter (Section 2.3) and also demonstrates functional profiles of the abstract specification that potential functional profile implementers may take as guidance for their implementations.

Other query string or REST-based functional profiles of this abstract specification are considered possible but are not specified here. In general, existing APIs that support the listing of alternative profiles for resource representations and the retrieval of resource representations to profiles may also support and demonstrate conformance to this specification by implementing its required functionality, as the functional profiles in this document do.

Related Work

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.

Abstract Model

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.

Content Negotiation Background

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

Profile Identification

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.

Requests and Responses

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:

  1. list profiles
    a client requests the list of URIs of data profiles for which a server is able to deliver conformant resource representations
  2. 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:

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

List Profiles

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.

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. 

# 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";
          formats="http://otherexample.org/profile/x",
  <http://example.org/resource/a?_profile=profile-x&_mediatype=application/xml>;
          rel="alternate";
          type="application/xml";
          formats="http://otherexample.org/profile/x",
  <http://example.org/resource/a?_profile=profile-y&_mediatype=application/xml>;
          rel="alternate";
          type="application/xml";
          formats="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=application/xml">X, in XML</a></li>
      <li><a href="?_profile=profile-y&_mediatype=application/xml">Y, in XML</a></li>
    </ul>
  </body>
</html>

Get Resource by Profile

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

As specified in [[RFC9110]], If the HEAD method is used in a request that specifies preferences in the profile, media type, or other negotiation dimension, then the response should be the same as for a GET method, including headers and status code, except that the body MUST be empty. It is important to note that headers, for which the value is determined only while generating the response content, MAY be omitted.

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

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 .

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 and an example with a redirect is shown in . shows an HTTP Headers Functional Profile message pair indicating a narrower profile response than the requested 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]
        
# 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]
        
# 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"

Alternate Representations Data Model

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 .

Alternate Profiles data model
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 () is limited to text within the constraints of the HTTP specification's headers structure in [[RFC9110]] 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 . Suggestions for concrete implementations of, and extensions to, this data model for use in expected situations are given in . Examples of suggested use are also given in that appendix.

Order of Precedence for Implementation Profiles

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.

Functional Profiles

Functional Profiles of this specification

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.

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.

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 . The namespace prefix for them is:

URI Name Description Usage Note
cnpr:http HTTP Headers Functional Profile For conformance with the functional profile presented in . 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 . 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 .
cnpr:qsa-alt QSA Alternate Keywords Functional Profile For conformance with the functional profile presented in . 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 .
cnpr:rrd Resource Representation Description For conformance with . 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 .
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 .

Hypertext Transfer Protocol Headers

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

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.

List Profiles

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 .

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

HTTP Alternate Representations Data Model Implementation

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 , 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" & formats="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 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 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.

Token mappings

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 . 

# 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 "dcterms: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. shows tokens a Link header with multiple attributes. 

# 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"; formats="urn:example:profile:marc21-dnb",
  <http://example.org/resource/a.profloc.ttl>; rel="alternate"; type="text/turtle"; formats="http://example.org/profiles/marc21-loc",
  <http://example.org/resource/a.profdnb.xml>; rel="alternate"; type="application/xml"; formats="urn:example:profile:marc21-dnb",
  <http://example.org/resource/a.profloc.xml>; rel="alternate"; type="application/xml"; formats="http://example.org/profiles/marc21-loc",
  <http://example.org/resource/a.html>; rel="alternate"; type="text/html"
[more response headers]

Get Resource by Profile

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.

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

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 .

URL Query String Arguments

QSA Functional Profile description

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

Conformance of a system to any one, or perhaps multiple, of these functional profiles may be demonstrated as per . 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.
QSA URI description

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 . 

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

In , 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 '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 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 which is accordance with URI formulation requirements [[RFC3986]]. 

http://example.com/path/to/resource/a?_profile=prof-01&_mediatype=text/turtle
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. [[RFC9110]]'s §4.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.
Key naming

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 .

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 .

List Profiles

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

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 

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";
          formats="http://otherexample.org/profile/x",
      <http://example.org/resource/a?_profile=profile-x&_mediatype=application/xml>;
          rel="alternate";
          type="application/xml";
          formats="http://otherexample.org/profile/x",
      <http://example.org/resource/a?_profile=profile-y&_mediatype=application/xml>;
          rel="alternate";
          type="application/xml";
          formats="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", "application/xml"]
        },
        {
            "token": "profile-y",
            "uri": "http://otherexample.org/profile/y",
            "media_types": ["application/xml"]
        }
    ]
}

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. 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 is given in below. Note that (above) gives a potential JSON format expression of Link header information according to the Alternate Representations 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";
          formats="urn:example:profile:x",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/turtle";
          formats="urn:example:profile:y",
  <http://example.org/resource/a>;
          rel="alternate";
          type="application/xml";
          formats="urn:example:profile:x",
  <http://example.org/resource/different>;
          rel="alternate";
          type="application/xml";
          formats="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>
Token mappings

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

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

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

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

Get Resource by Profile

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 .

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.

QSA key discovery

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 . 

# 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";
          formats="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-x&format=text/turtle>;
          rel="alternate";
          type="text/turtle";
          formats="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-y&format=application/xml>;
          rel="alternate";
          type="application/xml";
          formats="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 above communicates all the information that a list profiles request does, it is not visible directly in a web browser. 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 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 which is an extension to . 

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";
          formats="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-x&format=text/turtle>;
          rel="alternate";
          type="text/turtle";
          formats="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-y&format=application/xml>;
          rel="alternate";
          type="application/xml";
          formats="http://otherexample.org/profile/y"
  <http://example.org/resource/a?view=altrep&format=application/ld+json>;
          rel="alternate";
          type="application/ld+json";
          formats="http://www.w3.org/ns/dx/connegp/altr"

[default response content]

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 .

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 rather than the default representation of /resource/a.

Test Suites

Software to be used to assess conformance of systems to this specification is managed in the online code repository: https://github.com/w3c/conneg-prof-testing.

Implementations

Implementations of the functional profiles given in this document and their conformance test results are given in the Content Negotiation by Profile Implementation Report. That report also contains a description of, and gives access to the code for, conformance testing tools.

Acknowledgements

The editors gratefully acknowledge the contributions made to this document by all members of the Dataset Exchange Working Group, especially Annette Greiner and Antoine Isaac.

The editors would also like to thank the following non-Working Group people for supplying comments which were used to improve this document: Erik Wilde, Gregg Kellogg & Irene Polikoff.

Special thanks must be given to Kam Hay Fung for his most extensive comments and suggestions which found and fixed issues for us.

Finally, the editors thank the chairs of the Dataset Exchange Working Group: Peter Winstanley & Karen Coyle.

Changes

Changes since previous draft

The changes since this specification's 2nd Public Working Draft, 30 April 2019, are:

Features at Risk

The following features in this version are considered AT RISK:

Security and Privacy

The use of HTTP to negotiate and transport implies that all privacy and security issues that are relevant for that protocol are also relevant for profile negotiation. E. g., information such as user agent, accept-headers, IP address etc. can potentially be used as identifying information, and particularly, the IP address adds information about geolocation and institutional membership. Further, offering a list of acceptable profiles at the beginning of a negotiation process can reveal information about the user's interests that could be used to add such information to a user profile.

For a more complete view of those issues, cf. the Privacy and Security Questionnaire for this deliverable.

Appendices

Itemized Requirements

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.

HTTP Headers Functional Profile

R.1.1.a
From :
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 :
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 :
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 :
URIs referenced in Accept-Profile headers MUST be enclosed in angled brackets, '<' & '>'.
R.1.2.c
From :
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 :
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.

Query String Arguments Functional Profile

R.2.1.a
From :
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 :
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 :
[the] token MUST be mappable to a URI within one particular client/server session
R.2.1.d
From :
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 :
To conform to the "QSA Functional Profile", the QSA key _profile MUST be used to indicate a profile token
R.2.2.b
From :
the key _mediatype SHOULD be used to indicate a resource representation's Media Type
R.2.2.c
From :
tokens registered at IANA's Media Types list SHOULD be used as tokens for Media Type identifiers
R.2.3.a
From :
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 :
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 :
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 :
[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 :
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 :
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 :
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 :
They may do so via HTTP body content, perhaps in HTML or other data models/formats

Query String Arguments Alternate Keywords Functional Profile

R.3.1.a
From :
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 :
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 :
[the] token MUST be mappable to a [profile] URI within one particular client/server session
R.3.1.d
From :
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 :
a QSA key MUST be used to indicate a profile token
R.3.2.b
From :
[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 :
a QSA key SHOULD be used to indicate a resource representation's Media Type
R.3.2.d
From :
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 :
tokens registered at IANA's Media Types list SHOULD be used as tokens for Media Type identifiers
R.3.3.a
From :
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 :
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 :
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 :
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 :
[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 :
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 :
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 :
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 :
[They may do so] via HTTP body content, perhaps in HTML or other data models/formats

Profiles Vocabulary descriptions of this specification's Functional Profiles

This specification contains a number of distinct functional profiles that are identified and described in words in . 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 dcterms: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 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 , using the Profiles Vocabulary.
PREFIX dcterms: <http://purl.org/dc/terms/> PREFIX prof: <http://www.w3.org/ns/dx/prof/> 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 dcterms: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.2 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.3 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.3 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.3 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.3 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.3.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.3.2 get resource by profile."@en .
Profiles hierarchy of this specification
The specification and profiles of this Content Negotiation by Profile standard shown in a [[PROF] profiles hierarchy.

Demonstrating system conformance to Functional Profiles

With the identification of functional profiles of this specification given in 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 dcterms: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> dcterms: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 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 dcterms: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 dcterms: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 .

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 ; dcterms:title "Web Service XX" ; dcterms: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 dcterms:conformsTo <http://www.w3.org/ns/dx/connegp/profile/qsa-alt> ; # it's a public service dcterms: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> ;

Alternate Representations Data Model - Details

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.

Implementations

A Web Ontology Language [[OWL2-OVERVIEW]] implementation of the data model in 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 dcterms: <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: <https://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 prof:Profile instances and may have the format of a particular dcterms:MediaType."""@en ; dcterms:created "2019-08-07"^^xsd:date ; dcterms:modified "2024-02-07"^^xsd:date ; dcterms:creator [ a sdo:Person ; sdo:affiliation <https://kurrawong.ai> ; sdo:email <mailto:nick@kurrawong.ai> ; sdo:identifier <http://orcid.org/0000-0002-8742-7730> ; sdo:name "Nicholas J. Car" ; ] ; . <https://kurrawong.ai> a sdo:Organization ; sdo:name "KurrawongAI" ; sdo:url "https://kurrawong.ai"^^xsd:anyURI ; . dcterms:conformsTo a owl:ObjectProperty ; rdfs:label "conforms to" ; dcterms:source dcterms:conformsTo ; skos:scopeNote "Use this property to indicate a dcterms:Standard that a altr:Representation conforms to." ; . altr:hasRepresentation a owl:ObjectProperty ; rdfs:label "has representation" ; skos:definition "Indicates a Representation of a Resource."@en ; rdfs:domain rdfs:Resource ; rdfs:range altr:Representation ; skos:scopeNote "Use this property to indicate a 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:domain altr:Representation ; 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" ; . rdfs:Resource a owl:Class ; rdfs:label "Resource" ; skos:definition "The class resource, everything."@en ; dcterms:source "http://www.w3.org/2000/01/rdf-schema#Resource" ; skos:scopeNote "In the context of the Alternative Profiles Ontology, rdfs: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 ; dcterms: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" ; . dcterms:Standard a owl:Class ; rdfs:label "Standard" ; skos:definition "A basis for comparison; a reference point against which other things can be evaluated."@en ; dcterms:source "http://purl.org/dc/terms/Standard" ; skos:scopeNote "In the context of the Alternative Profiles Ontology, use this class to indicate instances of information models that representations of resources can conform to." ; .

Extensions

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 4 includes RDF definitions of Dublin Core Term's [[DCTERMS]] dcterms:format property and dcterms:MediaType class for Media Type indications that could be added to the Data Model, as represented in OWL in Code Listing 4. gives an example of this extended model's use following on from the content in .

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/> PREFIX dcterms: <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#> dcterms:format a owl:ObjectProperty ; rdfs:label "format" ; skos:definition "The file format, physical medium, or dimensions of the resource."@en ; dcterms:source dcterms:format ; rdfs:range dcterms:MediaType ; skos:scopeNote "Use this property to indicate an IANA Media Type of a resource's representation " . ex:defaultFormat a owl:DataTypeProperty ; rdfs:label "default format" ; skos:definition "Indicates the default Representation of a Resource for the specified Standard."@en ; rdfs:domain 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." . dcterms:MediaType a owl:Class ; rdfs:label "Media Type" ; skos:definition "A file format or physical medium."@en ; dcterms: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." . 
PREFIX altr: <http://www.w3.org/ns/dx/connegp/altr#>
PREFIX dcterms: <http://purl.org/dc/terms/>
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 rdfs: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 ;
    dcterms:conformsTo <http://otherexample.org/profile/x> ;
    dcterms:format "application/xml" .

:rep-2
    a altr:Representation ;
    dcterms: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 ;
    dcterms:conformsTo <http://otherexample.org/profile/z> .
    dcterms:format "text/html" ;
    ex:isProfilesDefault "true" .

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

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

Examples of model use

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

PREFIX altr: <http://www.w3.org/ns/dx/connegp/altr#>
PREFIX dcterms: <http://purl.org/dc/terms/>
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 rdfs: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 ;
    dcterms:conformsTo <http://otherexample.org/profile/x> .

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

:rep-3
    a altr:Representation ;
    dcterms:conformsTo <http://otherexample.org/profile/z> .
      
# 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";
          formats="http://otherexample.org/profile/x",
  <http://example.org/resource/a>;
          rel="alternate";
          formats="http://otherexample.org/profile/y",
  <http://example.org/resource/a>;
          rel="canonical";
          formats="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     |
---------------------------------------------------------------------------------------

Describing DCAT Distributions support of Content Negotiation by Profile

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 dcterms: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 dcterms:conformsTo would nevertheless apply to data services which declare a mechanism to access individual items. This mechanism may be identified via the dcat:endpointDescription.

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 dcterms: <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 ; dcterms: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 ; dcterms: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 .