Use case for LDP Next

All,

I realise that we are far from having a decision on whether there will be a LDP Next or not, but having looked at the proposed charter and the technical issues listed in the scope section [1] I think my use case and the derived requirement could fit nicely.

Would this be in scope of LDP Next?

Thanks for your consideration,

Lars

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. "Weaving services and people on the World Wide Web" [2] for which the DNB serves metadata in the DINI-KIM profile [3] and in the BIBFRAME profile [4]). 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 [2] 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.

Requirement:

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.

Possible solutions:

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" [5].)
There are several potential solutions to this. One is to extend the use of profile as specified in RFC 6906 [6] 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://www.w3.org/2012/ldp/wiki/LDPNext2015_Charter#scope

[2] http://d-nb.info/992999022

[3] http://d-nb.info/992999022/about/lds 
[4] http://d-nb.info/992999022/about/bibframe  
[5] https://blogs.oracle.com/bblfish/entry/crystalizing_rdf

[6] http://tools.ietf.org/html/rfc6906



*** Lesen. Hören. Wissen. Deutsche Nationalbibliothek *** 
-- 
Dr. Lars G. Svensson
Deutsche Nationalbibliothek
Informationsinfrastruktur und Bestanderhaltung
Adickesallee 1
D-60322 Frankfurt am Main
Telefon: +49-69-1525-1752
Telefax: +49-69-1525-1799
mailto:l.svensson@dnb.de 
http://www.dnb.de

Received on Saturday, 11 July 2015 11:55:13 UTC