- From: Phil Archer <phila@w3.org>
- Date: Wed, 6 May 2015 20:20:55 -0000
- To: "Kingsley Idehen" <kidehen@openlinksw.com>
- Cc: public-lod@w3.org
Hi Lars, This looks 100% in scope for the data shapes WG, no? It looks like a really good use case to me anyway. http://www.w3.org/2014/data-shapes/ Phil > 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 > > > -- Sent from my phone. Please excuse typos.
Received on Wednesday, 6 May 2015 20:21:05 UTC