Profiles in Linked Data

All,

I am looking for a way to specify a profile when requesting a (linked data) resource. A profile in this case is orthogonal to the mime-type and is intended to specify e. g. the use of a specific RDF vocabulary to describe the data (I ask a repository for a list of datasets, specify that I want the data in turtle and also that I want the data dictionary described with DCAT and not with PREMIS). This is adding a new dimension to the traditional content-negotiation (mime-type, language, etc.).

I have not found a best practice for doing this but the following possibilities have crossed my mind:

1) Using the Link-Header to specify a profile
This uses "profile" as specified in RFC 6906 [1]

Request:
GET /some/resource HTTP 1.1
Accept: application/rdf+xml
Link: <http://example.org/dcat-profile>; rel="profile"

The server would then either return the data in the requested profile, answer with 406 (not acceptable), or return the data in a default profile (and set the Link-header to tell the client what profile the server used...)


2) Register new http headers Accept-Profile and Profile

Request:
GET /some/resource HTTP 1.1
Accept: application/rdf+xml
Accept-Profile: <http://example.org/dcat-profile>

The server would then either return the data in the requested profile, answer with 406 (not acceptable), or return the data in a default profile. If the answer is a 200 OK, the server needs to set the Profile header to let the client know which profile was used. This is consistent with the use of the Accept header.

3) Use the Accept-Features and Features headers
RFC 2295 ยง6 [2] defines so-called features as a further dimension of content negotiation.

Request:
GET /some/resource HTTP 1.1
Accept: application/rdf+xml
Accept-Features: profile=<http://example.org/dcat-profile>

The server would then either return the data in the requested profile/feature, answer with 406 (not acceptable), or return the data in a default profile/feature. If the answer is a 200 OK, the server needs to set the Feature header to let the client know which profile was used. This is consistent with the use of the Accept header.

Discussion
The problem I have with the Accept-Features/Features header is that I feel that the provision of a specific (application) profile is not the same as a feature of the requested resource, at least not if I look at the examples they provide in RFC 2295 which includes "tables", "fonts", "screenwidth" and "colordepth", but perhaps I'm overly picky.

The registration of Accept-Profile/Profile headers is appealing since their semantics can be clearly defined and that their naming show the similarities to other Accept-* headers. OTOH the process of getting those headers registered with IETF can be fairly heavy.

Lastly, the use of RFC 6906 profiles has the advantage that no extra work has to be done, the Link header is in place and so is the profile relation type.

Any feedback would be greatly appreciated.

[1] http://tools.ietf.org/html/rfc6906

[2] http://tools.ietf.org/html/rfc2295#section-6


Best,

Lars

Received on Wednesday, 6 May 2015 15:04:54 UTC