Re: URI Schemes & Headers Dependencies

Nathan wrote:
> All,
> 
> A couple of questions (2)...
> 
> 
> 1: URI Scheme Issue(?)
> 
> The model of Web Access Control with FOAF+SSL will often lead to us 
> CRUDing resources via HTTPS, and often to retrieve them too.
> 
> Linked Data is currently, and predominantly served via http scheme URIs, 
> not https.
> 
> Often the model of exposing resources via HTTP but updating via HTTPS 
> will appeal / seem logical.
> 
> However, if we GET http://a and then PUT/DELETE to https://a - these are 
>  (afaict) two completely different resources, which surely means that we 
> will need to stick to pure https scheme uri's for all resources which 
> could be subject to web access control via foaf+ssl - ?
> 
> 
> 2: RESTful Linked Data / HATEOAS / Header dependencies.
> 
> Currently, there seems to be a tendency to expose lot's of additional 
> information for each resource via http headers, Link alternative, edit, 
> MS-Author-via and so forth - for a long time I haven't considered the 
> implications of this, until today.
> 
> I would ask then, why are we placing this Header dependency in to our 
> linked data - and moreover, why are we not putting this vital 
> information *in* our rdf documents? [please read on before responding]
> 
> Of primary concern are:
> - rel alternative
> - rel edit
>   (sub, describing the edit/delete methods, SPARQL-Update / GET|PUT etc)
> - rel acl
> - rel memento

after further thought:

rel acl must remain a header (how do you acl an image)
rel memento likewise
rel alternative likewise w/ caveat that it can also be in rdf/rdfa since 
it isn't control data.

re: rel edit; perhaps best to forget until SPARQL 1.1 Uniform HTTP 
Protocol for Managing RDF Graphs [1] is finished. With consideration of [2]

[1] http://www.w3.org/TR/sparql11-http-rdf-update/
[2] http://roy.gbiv.com/untangled/2008/rest-apis-must-be-hypertext-driven

Best,

Nathan

> A simple context for your consideration is in syndicated & cached 
> content; if some rdf is stored in a replicated or personal data store, 
> and I SPARQL describe it, surely all of this information is currently 
> missing, but extremely useful (if not vital) to have?
> 
> I'm not saying we should remove it from HTTP headers, but surely this 
> should be the "nice to have" where it is vital in the RDF & optional in 
> the headers.
> 
> 
> If these have been covered previously, please do link to the resolutions 
> - if not then I believe it would be in all of our best interests to 
> resolve and come to agreements sooner rather than later :)
> 
> Best & hope this mail finds you all well,
> 
> Nathan
> 
> 
>

Received on Thursday, 13 May 2010 08:44:15 UTC