URI Schemes & Headers Dependencies

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

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 05:53:16 UTC