Antoine,
On Tuesday, June 02, 2015 5:22 PM, Antoine Isaac wrote:
> Thanks for the offer! It would be great.
>
> the idea would be to register your story and requirement in our database at
> http://lelystad.informatik.uni-mannheim.de/rdf-validation/
> So that it eventually appears as an official DC requirement.
> For this we need a requirement in the database, a use case that requires it, and
> a case study that motives the use case.
>
> [1] is currently described by [2] as a "case study", but I believe it's not really
> one ([1] looks rather like a requirement with a candidate solution). The real
> business case is probably the one at
> http://wiki.dublincore.org/index.php/KIM-recommendations
>
> I see that the KIM-recommendations is already in our database as a case study
> so we're good:
> http://lelystad.informatik.uni-mannheim.de/rdf-validation/?q=CS-5-DINI-AG-
> KIM-RDF-REPRESENTATION-OF-BIBLIOGRAPHIC-DATA
Fine!
> What we'd need now is a generic description of the use case. Something like:
> [
> Title: Accessing data about a resource according to a specific profile
> Description:
> For a same resource (URI), various RDF descriptions are available,
> corresponding to different application profiles.
> A Linked Data consuming service accesses these different descriptions using the
> same URI for the resource, by specifying which profiles he wants to get the
> data according to.
> For example ....
> ]
OK, here's a try for the use case:
[[
Title: Accessing information about an entity according to a specific profile
Description:
In RDF, entities identified by a URI can be described in several different ways using different application profiles. One example is a bibliographic unit (e.g. "KIM-DINI-Technology-Watch-Report" [1] for which the DNB serves metadata in the DINI-KIM profile [2] and in the BIBFRAME profile [3]). A client harvesting data for a bibliographic database that exchanges data in BIBFRAME needs a way to specify that it wants the bibliographic information for [1] in the BIBFRAME profile, whereas another service specialising on data collection within the German speaking part of the world might prefer the DINI-KIM profile.
[1] http://d-nb.info/985906677
[2] http://d-nb.info/985906677/about/lds
[3] http://d-nb.info/985906677/about/bibframe
]]
> And then a requirement, like:
> [
> Title: Serving different data profiles depending on client request
> Description:
> Linked Data content negotiation recipes are updated/extended so that for a
> same resource URI, it is possible to serve different descriptions depending on
> the application profiles a client is interested in (as specified by an URI).
> Possible solutions are described at
> http://wiki.dublincore.org/index.php/RFC-6906-Profiles
> ]
[[
Title: Describing application profiles
Description: Application profiles need to have unique identifiers so that they can be referenced by different applications. These identifiers SHOULD be URIs that dereference to a machine-readable description of the profile.
]]
[[
Title: Serving different data profiles depending on client request
Description: Clients and servers need a way to negotiate which profile to use for a specific URI. This negotiation is orthogonal to content-type negotiation and language negotiation. (Note on terminology: The term "profile" in this requirement is used in the sense of "application profile". This is similar (equivalent?) to what the W3C data shape WG call a "shape". Another term used by Henry Story is "crystallisation" [1].)
There are several potential solutions to this. One is to extend the use of profile as specified in RFC 6906 [2] where "a profile can be described as additional semantics that can be used to process a resource representation, such as constraints, conventions, extensions, or any other aspects that do not alter the basic media type semantics. A profile MUST NOT change the semantics of the resource representation when processed without profile knowledge, so that clients both with and without knowledge of a profiled resource can safely use the same representation." The http Accept-header allows the client to add a profile specification to the media type, thus allowing the use of q-values. Since only JSON-LD and XHTML allow the specification of a profile together with the media type this possibility probably does not satisfy the requirement.
Another possibility is to use the http Link-header to specify the requested profile. The client would set a Link-header referencing the preferred profile. If the server can serve the requested profile it answers with a 200 response code and sets the Link header pointing to the same profile that the client requested. If the server cannot serve the requested profile, it can either answer with 406 (Not acceptable) or with 200 OK linking to the profile used. The Link-header does not allow the use of q-values. An example:
Client request:
GET /some/resource HTTP/1.1
Accept: application/rdf+xml
Link: <http://example.com/profiles/complicated>; rel="profile"
Server responses:
1) Server can serve the requested profile
HTTP/1.1 200 OK
Content-type: application/rdf+xml
Link: <http://example.com/profiles/complicated>; rel="profile"
2) Server cannot serve the requested profile and blocks the request
HTTP/1.1 406 Not acceptable
Content-type: application/xhtml+xml
<h1>406 Not acceptable</h1>
<p>This server cannot supply the profile http://example.com/profiles/complicated. Try with http://example.com/profiles/medium or http://example.com/profiles/simple instead.</p>
3) Server cannot serve the requested profile and returns another instead:
HTTP/1.1 200 OK
Content-type: application/rdf+xml
Link: <http://example.com/profiles/simple>; rel="profile"
A third possibility is to introduce a new http header: Accept-profile (or Accept-shape). This new header has the same semantics as Accept and can be used with q-values etc. The profile name can be either a value from a controlled vocabulary (probably an IANA registry) or a URI. An example:
Client request:
GET /some/resource HTTP/1.1
Accept: application/rdf+xml
Accept-profile: complicated # complicated is registered in IANA as http://example.com/profiles#complicated
Server responses:
1) Server can serve the requested profile
HTTP/1.1 200 OK
Content-type: application/rdf+xml
Profile: complicated
2) Server cannot serve the requested profile and blocks the request
HTTP/1.1 406 Not acceptable
Content-type: application/xhtml+xml
<h1>406 Not acceptable</h1>
<p>This server cannot supply the profile http://example.com/profiles/complicated. Try with http://example.com/profiles/medium or http://example.com/profiles/simple instead.</p>
3) Server cannot serve the requested profile and returns another instead:
HTTP/1.1 200 OK
Content-type: application/rdf+xml
Profile: simple # simple is registered in IANA as http://example.com/profiles#simple
[1] https://blogs.oracle.com/bblfish/entry/crystalizing_rdf
[2] http://tools.ietf.org/html/rfc6906
]]
Would that work?
Best,
Lars
> On 5/26/15 11:12 AM, Svensson, Lars wrote:
> > Antoine
> >
> >> Thanks for the answer!
> >>
> >> June 18 would be alright.
> >
> > OK, then I'll try to put something together until that call.
> >
> >> As far as I can tell the group doesn't have an official input on your question.
> >> Truth is, there was no champion for making that issue explicit - or it was
> >> forgotten in the maelstrom of new requirements that came after and/or
> >> merged with them.
> >
> > At least it was documented... [1] , but yes, there is no hint that we actually
> _did_ something of that user story [2]. I definitely confess that I haven't been
> very active in the group and also have not really looked after my use case.
> >
> >> This is indeed quite ironic, given the original context for the group's
> creation.
> >> But if you submit some description of the case, we'd be certainly happy to
> >> oblige add it to our lists!
> >
> > I'd be happy to oblige. What exactly do I need to do?
> >
> > [1] http://wiki.dublincore.org/index.php/RFC-6906-Profiles
> > [2] http://wiki.dublincore.org/index.php?title=RDF-Application-
> Profiles#Use_Cases_and_Requirements
> >
> > Cheers,
> >
> > Lars
> >
> >> On 5/22/15 10:31 AM, Svensson, Lars wrote:
> >>> Hi Antoine,
> >>>
> >>>> In the past two weeks there's been a discussion about Linked Data Profiles
> >> on
> >>>> the W3C public linked open data list:
> >>>> https://lists.w3.org/Archives/Public/public-lod/2015May/thread.html
> >> ("Profiles
> >>>> in Linked Data")
> >>>>
> >>>> It looks relevant, and it's a very long thread!
> >>>
> >>> Yes I started that thread with the goal of finding consensus on how clients
> and
> >> servers can negotiate profiles (or shapes or whatever-we-prefer-to-call-
> them).
> >> The use case I have is the provision of bibliographic data in several
> "profiles", e.
> >> g. BIBFRAME, RDA/FRBR, etc. There hasn't been a clear answer yet...
> >>>
> >>>> Lars, you have started it, would it be possible for you to report on it in one
> of
> >>>> the coming bi-weekly calls of the RDF AP group?
> >>>
> >>> I could present/report on June 18 if that is a suitable date. June 4 is a public
> >> holiday in this part of Germany so I shall not be able to attend that meeting.
> >>>
> >>>> At the call today, we were quite curious to hear whether you think there's
> >>>> something we should do!
> >>>
> >>> If I remember correctly, Kai kicked off this working group after my
> >> presentation at SWIB in 2013 where I mentioned the need for profile
> >> negotiation, so perhaps I should ask the wg members if you have any input!
> >>>
> >>> Best,
> >>>
> >>> Lars
> >>>
> >>>
> >
> >
