RE: Profiles in Linked Data

Martynas,

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

I'm afraid I don't quite understand how this is supposed to work. When a client calls http://example.org/some/resource, how does it tell the server it wants RDF/XML in the dcat-profile? And how does the server tell the client that it only supports premis?

Best,

Lars
> 
> 
> 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:57:01 UTC