Lars, you could define a "default" profile using Graphity. It would be an OWL class with annotations, e.g.:
<#SomeResource> a owl:Classs ; gp:uriTemplate "/some/resource" ; gp:query <#ConstructDCAT> . <#ConstructDCAT> a sp:Construct ; sp:text "CONSTRUCT ... " . # uses DCAT You could implement a little extra logic to override the gp:query value using a ?query= parameter and specifcy e.g. <#ConstructPREMIS> instead. See more here: https://github.com/Graphity/graphity-processor/wiki/Templates No new HTTP headers are necessary. Martynas graphityhq.com On Wed, May 6, 2015 at 5:04 PM, Svensson, Lars <l.svens...@dnb.de> 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 >
