Raw

Catching up with the blogosphere, I got some amusement from the grumbling about Google Reader's new "Share" subscription behaviour - if you say you want to share something, it's visible to all your contacts, rather than people you've nominated as friends. Google have given a diplomatic response, taking into consideration the folks that have been using "Share" for setting up other private functionality.

As they say in the A-list, Scoble nails it. What's needed in this kind of situation is Granular Privacy Controls.

This general issue appears to be surfacing quite a bit - opening up the social graph is great, but granularity of descriptions is needed. Ok, on one front RDF already has this covered, in that the type of relationship can be stated with whatever precision is required (start with FOAF, then there's the Relationship vocab, then there's whatever else you might want to make up yourself). But I don't think the privacy/access angle is yet covered very well in RDF or for that matter any of the other approaches to Web data.

At one extreme there's explicitly open data, e.g. the Open Linking Data cloud. Wide open. An example at the other extreme is Mozilla Weave, which allows sharing of browser data - but it seems to pass around encrypted blobs. Ok, as a stopgap on this the granular access control of CouchDB could be used (see CouchDB and Mozilla Weave - thanks for pointer Joe ).

I say as a stopgap because there's a big difference here in the kind of data that would be exposed, and the kind of data that could be exposed. The kind of data managed in the browser for Weave is obviously very Webby, but the JSON passed around by CouchDB (and all the other JSON tools I've seen) doesn't respect the link in a Web fashion. No matter how RESTful the API is, there's no global way of telling that a link is a link, or how the linked resources are related. It's not linked data.

If, say, browser data was exposed on the Web following linked data principles, you'd probably want to set up the access control, using something like Digest auth. But right now, as far as I know, this would likely mean having to manually set up .htaccess or somesuch. It's very much like using a text editor for HTML, not really suitable for everyone. I'm sure there are CMSs that could help, but I have doubts about the level of granularity and convenience.

The problem isn't isolated to this case. If I sat down and went through all the 'blocks' of data I could potentially expose as linked data right now (including social networking site exports), I bet it would run into hundreds of resource. Where I'd like to be, to maximise the network effect, is having all my data available in this form - probably well into the thousands. Need tools.

So... it seems like there's a pincer movement possible on all this. On the one hand, I reckon a role-based access control vocabulary would help considerably. I'm not sure what there is around [ notes to self - reread Danny Weitzner's material, & did EricP do some stuff on this ages ago?], but something loosely along the lines of Unix permissions, but set up so it would fit nicely alongside SIOC. Whether this would be used in concert with named graphs or reification doesn't really matter, let the application developer decide.

Then there's the potential for encouraging a convention in JSON for links and link relations - and that's all, forget resource typing etc for now. While RDF/JSON is very nice to have for RDF folks, making existing systems more Web-friendly would cover a much greater developer demographic. The best way of encouraging such a convention would be to build a tool that uses it - maybe a simple JSON-to-linkyHTML/RDF bridge might be a start ( wonder if Fred's looked at anything like this?).

(I need to remind myself of how the access control is set up on the Talis Platform - I've feeling we're more than half-way to what I'm suggesting).

I dunno, if a little more work was done to fix the Granular Privacy Control set of issues, I suspect it'd be a big help in fast-forwarding developments around provenance tracking. Check Jeni Tennison's post about RDF and Uncertainty in the context of genealogical data for some of the questions down the road. (I'm sure there are some solutions buried in the source of cwm, but am not sure how they might be brought out to much broader applicability).

@en