Re: Profiles in Linked Data

On 5/6/15 11:04 AM, Svensson, Lars wrote:
> 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

Lars,

To flesh out what you are seeking here, could you also include expected 
(or suggested) HTTP server responses to requests that include this 
"profile" relation?

-- 
Regards,

Kingsley Idehen 
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog 1: http://kidehen.blogspot.com
Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen
Twitter Profile: https://twitter.com/kidehen
Google+ Profile: https://plus.google.com/+KingsleyIdehen/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen
Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this