Contents

Using RFC 6906 Profiles to specify a profile independently of the media type

Introduction

This use case is not about representing profiles, but rather about using them. Precisely, this use case does not depend on the representation of the profile, but on the profile having a URI for identification. In order to keep up with best practices, that URI SHOULD dereference to a representation, possibly using content negotiation to deliver human- and machine-readable interpretations.

There are cases, when it is necessary to deliver information about the same entity in several formats. As long as the formats can be mapped to media types – e. g. X(HTML), PDF, RDF/XML or Turtle – this can be handled through Content Negotiation on the http Accept-Header; in that case the Client specifies in the request a list of Content-Types (a.k.a. Mime-Types) that it can handle and the server answers with contents in one of the requested formats or with http Status Code 406 (Not acceptable) if it doesn’t support either of the media types. Sometimes the client wants not require only a particular media type, but also needs the data according to a particular application profile.

Proposed solution

In addition to the content type in the Accept-header, the client can specify a profile using the Link-header. RFC 6906 specifies profiles as a possibility "to include additional [i. e. more than the accept header can convey] information about the nature of the resource. This would allow a client understanding this additional information to react in a way specific to that specialization of the resource, where the specialization can be about constraints, conventions, extensions, or any other aspects that do not alter the basic media type semantics." Particularly the possibility to send information on conventions and extensions is relevant for this use case. Thus the proposed solution is to let the client use the Link-header to specify a profile and tell the server if it wants standard RDF or if it requests the data to adhere to a specific application profile.

Implementation

In addition to the Accept-Header, the http request contains a Link-Header specifying the requested profile: 

Accept: application/rdf+xml
Link: <http://example.com/profiles/foo>; rel="profile"

If the server cannot deliver content in the specified profile, it can use one of two possibilities:

  1. Return http 406 (Not Acceptable)
  2. Return the data in a default profile

Other possibility: specify the profile in the Accept-Header

Theoretically, the profile can be part of the Accept-Header: 

Accept: application/rdf+xml;profile=<http://d-nb.info/standards/profile/DINI-KIM>

The use of profiles in the accept header depends on the media type. In the IANA Media Type Registry only two media types relevant to linked data are designed to use profiles:

  1. XHTML (application/xhtml+xml) RFC 3236
  2. JSON-LD (application/ld+json) IANA-Registry

The following do not mention the use of profile

  1. RDF/XML (application/rdf+xml) RFC 3870
  2. Turtle (text/turtle) IANA-Registry
  3. html (text/html) IANA-Registry

Thus the link-header seems to be the only possibility.