Hi Kingsley,
In https://lists.w3.org/Archives/Public/public-lod/2015Feb/0116.html
You said, re Annalist:
My enhancement requests would be that you consider supporting of at
least one of the following, in regards to storage I/O:
1. LDP
2. WebDAV
3. SPARQL Graph Protocol
4. SPARQL 1.1 Insert, Update, Delete.
As for Access Controls on the target storage destinations, don't worry
about that in the RDF editor itself, leave that to the storage provider
[1] that supports any combination of the protocols above.
Thanks for you comments and feedback - I've taken note of them.
My original (and current) plan is to provide HTTP access (GET/PUT/POST/etc) with
a little bit of WebDAV to handle "directory" content enumeration., which I think
is consistent with your suggestion (cf. [1]). The other options you mention are
not ruled out.
You say I shouldn't worry too much about access control, but leave that to the
back-end store. If by this you mean *just* access control, then that makes
sense to me.
A challenge I face is to understand what authentication tokens are widely
supported by existing HTTP stores. Annalist itself uses OpenID Connect (ala
Google+, etc) is its main authentication mechanism, so I cannot assume that I
have access to original user credentials to construct arbitrary security tokens.
I had been thinking that something based on OAuth2 might be appropriate (I
looked at UMA [2], had some problems with it as a total solution, but I might be
able to use some of its elements). I took a look at the link you provided, but
there seem to be a lot of moving parts and couldn't really figure out what you
were describing there.
Thanks!
#g
--
[1] https://github.com/gklyne/annalist/issues/32
[2] http://en.wikipedia.org/wiki/User-Managed_Access,
http://kantarainitiative.org/confluence/display/uma/Home
