Re: Profiles in Linked Data

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