On 5/7/15 5:08 AM, Svensson, Lars wrote:
Kingsley,>To flesh out what you are seeking here, could you also include expected >(or suggested) HTTP server responses to requests that include this >"profile" relation?Sure. Only headers resulting from the profile negotiation are included...> >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"Response (request successful) HTTP/1.1 200 OK Content-Type: application/rdf+xml Vary: Accept, Link Link:<http://example.org/dcat-profile>; rel=profile Response (no such profile, client should pick one from the list) HTTP/1.1 406 Not acceptable Content-Type: application/rdf+xml (Body containing information about acceptable profiles) Response (no such profile, so server delivers a default profile) HTTP/1.1 200 OK Content-Type: application/rdf+xml Vary: Accept, Link Link:<http://example.org/premis-profile>; rel=profile> >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>Response (request successful) HTTP/1.1 200 OK Content-Type: application/rdf+xml Vary: Accept, Accept-Profile Profile:<http://example.org/dcat-profile> Response (no such profile, client should pick one from the list) HTTP/1.1 406 Not acceptable Content-Type: application/rdf+xml (Body containing information about acceptable profiles) Response (no such profile, so server delivers a default profile) HTTP/1.1 200 OK Content-Type: application/rdf+xml Vary: Accept, Accept-Profile Profile:<http://example.org/premis-profile>> >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>Response (request successful) HTTP/1.1 200 OK Content-Type: application/rdf+xml Vary: Accept TCN: choice Alternates: {"resource.premis.rdf" {profilehttp://example.org/premis-profile}} Response (no such profile, client should pick one from the list) HTTP/1.1 406 Not acceptable Content-Type: application/rdf+xml TCN: list Alternates: {"resource.premis.rdf" {profilehttp://example.org/premis-profile}} (Body containing information about acceptable profiles) In this case the server cannot deliver a default profile since the algorithms suggested in RFC 2295 has no way to transport which profile was used... Hope this helps, Lars
Lars,What behavior characteristics are being signaled by the "profile" relation embedded in HTTP response metadata? Here's what I suspect you are implying:
Request: GET /resource/Linked_data HTTP 1.1 Accept: text/turtle Link: <http://www.w3.org/DesignIssues/LinkedData#this>; rel="profile" Response HTTP/1.1 200 OK Content-Type: text/turtle Vary: Accept, Link Link:<http://www.w3.org/DesignIssues/LinkedData#this>; rel=profile Implies: The document content retrieved is in RDF-Turtle form, and by way of "profile" relation a user agent should assume that it adheres to the principles outlined by the concept identified by<http://www.w3.org/DesignIssues/LinkedData#this> . Bearing in mind: <http://www.w3.org/DesignIssues/LinkedData#this> is schema:about of<http://www.w3.org/DesignIssues/LinkedData> . OR (in purer Turtle): <http://www.w3.org/DesignIssues/LinkedData> schema:about<http://www.w3.org/DesignIssues/LinkedData#this> .
I am walking through this piecemeal, because I've circled this wagon a few times in other quarters (typically in forums such as LDP [most recent occurrence]) [1]. CON: Basically, if what I've outlined is accurate, we've ended up adding a signal (via HTTP request and response metadata) to indicate what's implicit re., AWWW (Architecture of the World Wide Web) i.e., that HTTP URIs are Name that resolve to descriptions of what they denote (i.e., an HTTP URI has a denotation and connotation duality that enables them function as Terms). PRO: Anyway, countering myself [as I type], I've also realized that when the Content-Type is one of those associated with the RDF Language, we could look to this "profile" relation as a mechanism for a user agent to signal that the RDF Language based content requested has to conform to the principles associated with the concept identified by<http://www.w3.org/DesignIssues/LinkedData#this>. And likewise, a server can return content also using "profile" to indicate that said RDF content is in RDF-Turtle form, and conforms to the principles associated with the concept identified by<http://www.w3.org/DesignIssues/LinkedData#this>. Ultimately<http://www.w3.org/DesignIssues/LinkedData#this> has a better chance of resolving to RDF content than any IANA doc. That said, we do have HTML5+Microdata at are disposal re., IANA docs :) Links: [1] http://lists.w3.org/Archives/Public/public-ldp-wg/2014Jan/0081.html -- LDP Thread from 2014 about RDF and "profile" relation. -- Regards, Kingsley Idehen Founder & CEO OpenLink Software Company Web: http://www.openlinksw.com Personal Weblog 1: http://kidehen.blogspot.com Personal Weblog 2: http://www.openlinksw.com/blog/~kidehen Twitter Profile: https://twitter.com/kidehen Google+ Profile: https://plus.google.com/+KingsleyIdehen/about LinkedIn Profile: http://www.linkedin.com/in/kidehen Personal WebID: http://kingsley.idehen.net/dataspace/person/kidehen#this
smime.p7s
Description: S/MIME Cryptographic Signature
