Re: Profiles in Linked Data

As you wrote, media type is orthogonal to profiles. To retrieve
RDF/XML, you would use content negotiation (Accept header).

You would need to run the Graphity processor that would match URI
templates and execute SPARQL queries from the sitemap ontology.

Sure, instead of query strings you could use Accept-Profile/Profile or
similar headers to advertise profiles and their preference. It's just
that the uptake for new custom HTTP headers will be slow, so there's
not much practical advantage.

On the other hand, it seems like you want different descriptions of a
resource -- so it seems to me that these should in fact be different
resources? That could be split into
http://example.org/some/resource/dcat and
http://example.org/some/resource/premis, for example.

On Thu, May 7, 2015 at 12:56 PM, Svensson, Lars <L.Svensson@dnb.de> wrote:
> 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 11:05:36 UTC