[rdfweb-dev] FOAF link in request headers

[Graham Klyne]

Danny Ayers wrote:
> 1. use "FOAF: http://example.org/foaf.rdf"
> - pursue IETF/IANA registration for it (see RFC 3864 and:
> http://www.iana.org/assignments/message-headers/message-header-index.html

Hmmm... I'm uneasy about being so specific to FOAF.  Why not a pointer 
to any RDF (e.g. CC/PP)?  I'll revisit this below.

A provisional registration should be very easy.  A permanent 
registration would require some consensus.  I think option (4) might be 
easier to swing, but has some added complexity.

> 2. use "X-FOAF: http://example.org/foaf.rdf"
> - I've not found confirmation, but people seem to think it's ok
> without registration

See RFC2616, sects 4.5, 5.3, 6.2, 7.1.   The header registration spec 
leaves the X- convention as a protocol-specific issue, and AFAICT 
there's no such convention defined for HTTP (there is for email).

> 3. use (something like) "Profile: http://example.org/foaf.rdf"
> - it's not tied to a particular data type, might be more appropriate
> and actually stand a chance of successful registration

Hmmm, is this/can this be well enougfh defined to be interoperable?

If we can assume the retrieval mechanism will return MIME type 
information, and allow content negotiation (e.g. as HTTP provides) then 
maybe this is enough, and has the benefit of simplicity and flexibility. 
  But is it safe to assume an HTTP-like retrieval protocol here?

> 4. use "Link: <http://example.org/foaf.rdf>; rel="foaf"
> - suggested by Mark Nottingham (editor/author of some of the related
> specs) - it was in RFC 2068, (but isn't in 2616), so should be
> acceptable standards-wise, has the advantage of mapping 1:1 with HTML
> link tag. Christopher Schmidt recognised the Link: construct, posted
> some further references to #swig:
> http://www.ilrt.bris.ac.uk/discovery/chatlogs/swig/2005-05-18#T12-53-38

This seems like the most flexible general solution, though I wonder if 
we really need to create another namespace for the rel= parameter. 
Other options might be:
(a) a MIME type parameter, indicating the (expected) MIME content type 
of the referenced document.
(a) a URI, indicating the expected content of the referenced document. 
(There have been proposals to embed MIME content-types into URI space, 
so this could subsume option (a).)

> More notes, and even a little code (!) around:
> http://dannyayers.com/archives/2005/08/28/foaf-uri-in-http-headers-easy/
> http://www.ontogon.com/movabletype/
> http://dannyayers.com/archives/2005/08/27/foaf-cookies-a-silver-bullet-for-web-marketing/
> 
> Graham Klyne's behind the registry docs (along with mnot), as one
> would expect he's done some RDF noodling with it:
> http://www.ninebynine.org/IETF/Messaging/HdrRegistry/Intro.html

Also... part of my motivation was to provide a basis for using email 
header fields as RDF properties, in conjunction with rfc3553.txt.  (cf. 
http://www.ninebynine.org/IETF/Messaging/draft-klyne-message-xml-00.txt) 
   My interest was creating RDSF metadata from email message stores -- 
at the time, I was working for the company that developed MIMEsweeper. 
I haven't yet got around to do the remaining pieces, as I've moved on.

#g

-- 
Graham Klyne
For email:
http://www.ninebynine.org/#Contact