- From: Svensson, Lars <L.Svensson@dnb.de>
- Date: Thu, 7 May 2015 09:08:33 +0000
- To: Kingsley Idehen <kidehen@openlinksw.com>, "public-lod@w3.org" <public-lod@w3.org>
Kingsley,
> 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?
Sure. Only headers resulting from the profile negotiation are included...
> > 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"
Response (request successful)
HTTP/1.1 200 OK
Content-Type: application/rdf+xml
Vary: Accept, Link
Link: <http://example.org/dcat-profile>; rel=profile
Response (no such profile, client should pick one from the list)
HTTP/1.1 406 Not acceptable
Content-Type: application/rdf+xml
(Body containing information about acceptable profiles)
Response (no such profile, so server delivers a default profile)
HTTP/1.1 200 OK
Content-Type: application/rdf+xml
Vary: Accept, Link
Link: <http://example.org/premis-profile>; rel=profile
> > 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>
Response (request successful)
HTTP/1.1 200 OK
Content-Type: application/rdf+xml
Vary: Accept, Accept-Profile
Profile: <http://example.org/dcat-profile>
Response (no such profile, client should pick one from the list)
HTTP/1.1 406 Not acceptable
Content-Type: application/rdf+xml
(Body containing information about acceptable profiles)
Response (no such profile, so server delivers a default profile)
HTTP/1.1 200 OK
Content-Type: application/rdf+xml
Vary: Accept, Accept-Profile
Profile: <http://example.org/premis-profile>
> > 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>
Response (request successful)
HTTP/1.1 200 OK
Content-Type: application/rdf+xml
Vary: Accept
TCN: choice
Alternates: {"resource.premis.rdf" {profile http://example.org/premis-profile}}
Response (no such profile, client should pick one from the list)
HTTP/1.1 406 Not acceptable
Content-Type: application/rdf+xml
TCN: list
Alternates: {"resource.premis.rdf" {profile http://example.org/premis-profile}}
(Body containing information about acceptable profiles)
In this case the server cannot deliver a default profile since the algorithms suggested in RFC 2295 has no way to transport which profile was used...
Hope this helps,
Lars
Received on Thursday, 7 May 2015 09:09:04 UTC