Re: Profiles in Linked Data

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.Svensson@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
>

Received on Thursday, 7 May 2015 10:03:58 UTC