Content Negotiation by Profile

W3C Working Draft

This version:
https://www.w3.org/TR/2019/WD-dx-prof-conneg-20191126/
Latest published version:
https://www.w3.org/TR/dx-prof-conneg/
Latest editor's draft:
https://w3c.github.io/dxwg/connegp/
Test suite:
https://github.com/w3c/prof-conneg-testing
Implementation report:
https://w3c.github.io/dxwg/connegp-implementation-report/
Previous version:
https://www.w3.org/TR/2019/WD-dx-prof-conneg-20190430/
Latest Recommendation:
https://www.w3.org/TR/2019/WD-dx-prof-conneg-20190430/
Editors:
Lars G. Svensson (Invited Expert and before at Deutsche Nationalbibliothek)
Rob Atkinson (Metalinkage, Open Geospatial Consortium)
(SURROUND Australia Pty Ltd and before at CSIRO)
Participate:
GitHub w3c/dxwg
File a bug
Commit history
Pull requests
Contributors:
Ruben Verborgh

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.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

This document was published by the Dataset Exchange Working Group as a Working Draft. This document is intended to become a W3C Recommendation.

GitHub Issues are preferred for discussion of this specification. Alternatively, you can send comments to our mailing list. Please send them to public-dxwg-comments@w3.org (archives).

Please see the Working Group's implementation report.

Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2019 W3C Process Document.

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 documents are:

1. Introduction

This section is non-normative.

Content delivered by dereferencing Internet identifiers can be the subject of negotiation in different ways. When using the HTTP protocol [RFC7230], 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.

While this specification only describes HTTP methods for content negotiation by profile via the HTTP Header and URL QSA Functional Profiles, it is expected that implementers will want to implement functionally equivalent profiles for other environments, some of which may be not yet realized future environments.

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.

2. Conformance

As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.

The key words MAY, MUST, MUST NOT, RECOMMENDED, SHOULD, and SHOULD NOT in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

For the purpose of compliance, the normative sections of this document are § 3. Definitions, § 6. Abstract Model, § 7. Functional Profiles and § 9. Test Suites. Appendices are non-normative.

Note

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.

3. 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. [RFC7230]
server
A program that accepts connections in order to service HTTP requests by sending HTTP responses. [RFC7230]
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. [RFC7230]

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. [RFC7230]
response
A message sent over the Internet, from a server to a client answering a request for information about a resource. [RFC7230]
token
A short name identifying something. In the context of this document, tokens are sometimes used to identify profiles.

4. Motivation

This section is non-normative.

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

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.

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

6.1 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§ 3. Definitions.

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

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

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

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=all 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 Content-Profile
# header.
HTTP/1.1 200 OK
Content-Type: application/json
Content-Profile: <http://www.w3.org/ns/dx/conneg/profile/qsa>
# 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";
          profile="http://otherexample.org/profile/x",
  <http://example.org/resource/a?_profile=profile-x&_mediatype=text/xml>;
          rel="alternate";
          type="text/xml";
          profile="http://otherexample.org/profile/x",
  <http://example.org/resource/a?_profile=profile-y&_mediatype=text/xml>;
          rel="alternate";
          type="text/xml";
          profile="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>

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

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 Content-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
Content-Profile: http://example.org/profile/x

[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
Content-Profile: http://example.org/profile/x

---

# 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 Content-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]
Content-Profile: http://example.org/profile/x, \
                 http://example.org/profile/y, \
                 http://example.org/profile/z
[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:

Content-Profile: <https://joinup.ec.europa.eu/release/geodcat-ap-v10>, <https://joinup.ec.europa.eu/release/statdcat-ap/101>

6.4 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 Figure 1.

Alternate Profiles data model
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.3 Alternate Representations Data Model - Details. Examples of suggested use are also given in that appendix.

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

Issue 505: Specify the realisation order of precedence for conflicting profile negotiation situations profile-negotiation

It is clearly specified that QSA has precedence over HTTP if both are supported, however there is no proposed mechanism for specifying the relative precedence of other URL based implementations. Can this be left to implementations to specify or must the situation be handled in this specification?

7. Functional Profiles

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

Issue 1022: Differentiating Functional & Data Profiling in Conneg profile-negotiation

Is the use of term "Functional Profile" confusing when the document describes options for functionality related to Data Profiles ?

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:

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

7.2 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 two new HTTP headers, Accept-Profile and Content-Profile that are 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.

Content-Profile headers 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 Content-Profile header listing the URIs of all profiles to which it knows the representation conforms.

7.2.1 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 – will 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.

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 .

7.2.1.1 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 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" & profile="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.

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

7.2.2 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. URIs MUST be enclosed in angled brackets, '<' & '>'. It is possible to specify a range of acceptable profile URIs and, when using multiple URIs, they MUST be delimited by a comma or be in separate Accept-Profile headers. Preferences may be indicated by 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 Content-Profile HTTP header.

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
Content-Profile: <urn:example:profile:x>
[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.

7.3 URL Query String Arguments

7.3.1 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 § 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.2 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.
7.3.1.1 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 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.
7.3.1.2 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 § 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.

7.3.2 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 all SHOULD be used, e.g. _profile=all.

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=all&_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
Content-Profile: <http://www.w3.org/ns/dx/conneg/profile/qsa>
Link:
  <http://example.org/resource/a?_profile=profile-x&_mediatype=application/json>;
          rel="canonical"; type="application/json";
          profile="http://otherexample.org/profile/x",
  <http://example.org/resource/a?_profile=profile-x&_mediatype=text/xml>;
          rel="alternate";
          type="text/xml";
          profile="http://otherexample.org/profile/x",
  <http://example.org/resource/a?_profile=profile-y&_mediatype=text/xml>;
          rel="alternate";
          type="text/xml";
          profile="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"]
        }
    ]
}
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. 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";
          profile="urn:example:profile:x",
  <http://example.org/resource/a>;
          rel="alternate";
          type="text/turtle";
          profile="urn:example:profile:y",
  <http://example.org/resource/a>;
          rel="alternate";
          type="application/xml";
          profile="urn:example:profile:x",
  <http://example.org/resource/different>;
          rel="alternate";
          type="application/xml";
          profile="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>
7.3.2.2 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.).

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.

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

7.3.3 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 § 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 Content-Profile HTTP header 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.

7.3.4 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=all 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 profile 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";
          profile="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-x&format=text/turtle>;
          rel="canonical";
          type="text/turtle";
          profile="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-y&format=text/xml>;
          rel="alternate";
          type="text/xml";
          profile="http://otherexample.org/profile/y"

# Note that here the server does not directly indicate the profile served
# (there is no Content-Profile header 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=all 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="text/html";
          profile="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-x&format=text/turtle>;
          rel="canonical";
          type="text/turtle";
          profile="http://otherexample.org/profile/x",
  <http://example.org/resource/a?view=profile-y&format=text/xml>;
          rel="alternate";
          type="text/xml";
          profile="http://otherexample.org/profile/y"
  <http://example.org/resource/a?view=altrep&format=application/ld+json>;
          rel="alternate";
          type="application/ld+json";
          profile="http://www.w3.org/ns/dx/conneg/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/conneg/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.

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

10. Implementations

This section is non-normative.

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.

11. Acknowledgements

This section is non-normative.

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.

12. Changes

This section is non-normative.

12.1 Changes since previous draft

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

12.2 Features at Risk

The following features in this version are considered AT RISK:

13. Security and Privacy

This section is non-normative.

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.

A. Appendices

A.1 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 § 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/conneg/profile/> . <https://www.w3.org/TR/dx-prof-conneg/> 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-prof-conneg/> ; 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-prof-conneg/> ; 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-prof-conneg/> ; 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 .
Profiles hierarchy of this specification
Figure 4 The specification and profiles of this Content Negotiation by Profile standard shown in a [[PROF] profiles hierarchy.

A.2 Demonstrating system conformance to Functional Profiles

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-prof-conneg/, 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/conneg/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/conneg/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> ;

A.3 Alternate Representations Data Model - Details

§ 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.3.1 Implementations

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/conneg/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/conneg/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:nicholas.car@surroundaustralia.com> ; 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/conneg/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." .

A.3.2 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 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/conneg/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" .

A.3.3 Examples of model use

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/conneg/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";
          profile="http://otherexample.org/profile/x",
  <http://example.org/resource/a>;
          rel="alternate";
          profile="http://otherexample.org/profile/y",
  <http://example.org/resource/a>;
          rel="canonical";
          profile="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.4 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 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: Provide a means to declare conneg-by-ap is supported by URI identified items within a dcat:Dataset. dcat-primerdcat:DataService

dcat:endpointDescription

"The endpoint description gives specific details of the actual endpoint instances, while dct:conformsTo is used to indicate the general standard or specification that the endpoints implement."

the range is rdfs:Resource

It would appear to be useful to be able to canonically declare that conneg-by-ap is available on a distribution or each item in a dataset or both.

Declaring additional canonical functional profiles with these specific semantics may be valuable.

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/conneg/profile/http> , <http://www.w3.org/ns/dx/conneg/profile/qsa> ; # Declare that the Dataset may be invoked by URI, its id, using Content # Negotiation by Profile dcat:endPointURL :aDataset .

B. References

B.1 Normative references

[DCTERMS]
DCMI Metadata Terms. DCMI Usage Board. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dcmi-terms/
[OWL2-OVERVIEW]
OWL 2 Web Ontology Language Document Overview (Second Edition). W3C OWL Working Group. W3C. 11 December 2012. W3C Recommendation. URL: https://www.w3.org/TR/owl2-overview/
[PROF-IETF]
Indicating and Negotiating Profiles in HTTP. L. Svensson; R. Verborgh. 2019-07-11. IETF Internet Draft. URL: https://profilenegotiation.github.io/I-D-Profile-Negotiation/I-D-Profile-Negotiation
[RFC2119]
Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119
[RFC3986]
Uniform Resource Identifier (URI): Generic Syntax. T. Berners-Lee; R. Fielding; L. Masinter. IETF. January 2005. Internet Standard. URL: https://tools.ietf.org/html/rfc3986
[RFC7230]
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7230.html
[RFC8174]
Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://tools.ietf.org/html/rfc8174
[RFC8288]
Web Linking. M. Nottingham. IETF. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
[VOCAB-DCAT-2]
Data Catalog Vocabulary (DCAT) - Version 2. Riccardo Albertoni; David Browning; Simon Cox; Alejandra Gonzalez Beltran; Andrea Perego; Peter Winstanley. W3C. 28 May 2019. W3C Working Draft. URL: https://www.w3.org/TR/vocab-dcat-2/

B.2 Informative references

[ARK]
The ARK Identifier Scheme. 2008-05-22. Internet-Draft. URL: https://tools.ietf.org/id/draft-kunze-ark-15.txt
[CSW]
Catalogue Services 3.0 - General Model. Douglas Nebert; Uwe Voges; Lorenzo Bigagli. OGC. 10 June 2016. URL: http://www.opengeospatial.org/standards/cat
[DC11]
Dublin Core Metadata Element Set, Version 1.1. DCMI. 14 June 2012. DCMI Recommendation. URL: http://dublincore.org/documents/dces/
[DCAT-AP]
DCAT Application Profile for data portals in Europe. Version 1.2.1. European Commission. 28 May 2019. URL: https://joinup.ec.europa.eu/solution/dcat-application-profile-data-portals-europe
[DX-PROF]
The Profiles Vocabulary. Nicholas Car. W3C. 2 April 2019. W3C Working Draft. URL: https://www.w3.org/TR/dx-prof/
[GeoDCAT-AP]
GeoDCAT-AP: A geospatial extension for the DCAT application profile for data portals in Europe. Version 1.0.1. European Commission. 2 August 2016. URL: https://joinup.ec.europa.eu/solution/geodcat-application-profile-data-portals-europe
[ISO-19115]
Geographic information -- Metadata. ISO/TC 211. ISO. 2003. International Standard. URL: https://www.iso.org/standard/26020.html
[OAI-PMH]
The Open Archives Initiative Protocol for Metadata Harvesting. Carl Lagoze; Herbert Van de Sompel; Michael Nelson; Simeon Warner. OAI. 8 January 2015. URL: http://www.openarchives.org/OAI/openarchivesprotocol.html
[PROF-GUIDANCE]
Profile Guidance. 2019-04-24. W3C Editor's Draft. URL: https://w3c.github.io/dxwg/profiles/
[RFC6906]
The 'profile' Link Relation Type. E. Wilde. IETF. March 2013. Informational. URL: https://tools.ietf.org/html/rfc6906
[RFC7231]
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content. R. Fielding, Ed.; J. Reschke, Ed.. IETF. June 2014. Proposed Standard. URL: https://httpwg.org/specs/rfc7231.html
[RFC7240]
Prefer Header for HTTP. J. Snell. IETF. June 2014. Proposed Standard. URL: https://tools.ietf.org/html/rfc7240
[STATDCAT-AP]
StatDCAT-AP – DCAT Application Profile for description of statistical datasets. Version 1.0.1. European Commission. 28 May 2019. URL: https://joinup.ec.europa.eu/solution/statdcat-application-profile-data-portals-europe
[TURTLE]
RDF 1.1 Turtle. Eric Prud'hommeaux; Gavin Carothers. W3C. 25 February 2014. W3C Recommendation. URL: https://www.w3.org/TR/turtle/
[VOCAB-DATA-CUBE]
The RDF Data Cube Vocabulary. Richard Cyganiak; Dave Reynolds. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-data-cube/
[VOCAB-DCAT]
Data Catalog Vocabulary (DCAT). Fadi Maali; John Erickson. W3C. 16 January 2014. W3C Recommendation. URL: https://www.w3.org/TR/vocab-dcat/
[VOID]
Describing Linked Datasets with the VoID Vocabulary. Keith Alexander; Richard Cyganiak; Michael Hausenblas; Jun Zhao. W3C. 3 March 2011. W3C Note. URL: https://www.w3.org/TR/void/
[WFS]
Web Feature Service 2.0 Interface Standard. Panagiotis (Peter) A. Vretanos. OGC. 10 July 2014. OGC Interface Standard. URL: http://www.opengeospatial.org/standards/wfs
[WMS]
Web Map Service Implementation Specification. Jeff de la Beaujardiere. OGC. 15 March 2006. OpenGIS Implementation Standard. URL: http://www.opengeospatial.org/standards/wms