[foaf-protocols] rdf vocab for HTTP requests,

Michael Hausenblas michael.hausenblas at deri.org
Mon Dec 7 09:39:01 CET 2009


Peter,

> Is there are a RDF vocabulary for describing specific HTTP requests (including
> headers)?

Regarding the syntax/structure of HTTP, yes, see Kingsley's link and
regarding the semantics, well, sort of - we're working towards one, see [1].

Cheers,
      Michael

[1] http://www.w3.org/2001/tag/awwsw/http-semantics-report.html

-- 
Dr. Michael Hausenblas
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html



> From: Peter Williams <pwilliams at rapattoni.com>
> Date: Sun, 6 Dec 2009 12:27:25 -0800
> To: "foaf-protocols at lists.foaf-project.org"
> <foaf-protocols at lists.foaf-project.org>
> Subject: [foaf-protocols] rdf vocab for HTTP requests,
> 
> Is there are a RDF vocabulary for describing specific HTTP requests (including
> headers)?
> 
> Just as one can describe any XML file lexically as a graph, is there a
> description for an HTTP request?
> 
> I want my SAML signed artifact response message to convey to the foaf_ssl RP
> (the artifact resolver service's client) RP HOW-TO talk in detail to a foaf
> card repository using HTTP. Rather than convey the webid in 1 attribute AND a
> hash value of the foaf card in another, I'd rather convey an RDF graph as a
> complex attribute - one that describes how-to "correctly" deference the foaf
> card using a conditional HTTP GET request. If the vocab were able to describe
> the HTTP request fully, it can express the conditional GET, stating the
> __required__ ETag value of the foaf card.
> 
> If I can do this, (as Henry implied once) we'd no longer obligate foaf+ssl
> sites' CGIs to check the integrity of foaf card - as the HTTP layer will do it
> for us. There would be however the assurance that the ETag of the card copy
> seen by the asserting party is the same as the ETag used by the relying party.
> Though the integrity of HTTP caching would still be a function of ETag and
> IETF cache replication techniques, saml+foaf+ssl would stay consistent with
> the web architecture.
> 
> 
> 
> _______________________________________________
> foaf-protocols mailing list
> foaf-protocols at lists.foaf-project.org
> http://lists.foaf-project.org/mailman/listinfo/foaf-protocols



More information about the foaf-protocols mailing list