Yesterday, I put up a draft of a new vocabulary I've started called voperm. It's based on a really simple premise: a simple, standard, cross-technological vocabulary to describe the sort of things you want to allow done with data - think by-laws for feeds and APIs. 
The sort of permissioning I'm thinking of is as follows: how often a site should ask for updates, what sort of resyndication is allowed, requirements for linking back or providing notification and so on. I publish an RSS feed for my blog, but simply making my content available in a machine-readable XML format does not mean I give people the right to use that as spam-blog fodder. But I don't mind if someone were to take my feed and run it through something like Yahoo! Pipes so they could filter out all my posts about stupid people and just get the tech stuff. Many people want to attach a set of policies to data they provide. 
I'm not the first to suggest this. The Web Services people have taken a stab at this, but they came at it with the Web Services frame which means the whole thing is pretty much irrelevant. The DataPortability people are also intending to do something about it, but they seem to have more important things on their mind like engaging in masturbation about leadership and standing quora committees and other such tedious wank. Can't be bothered with that. If anything like this is going to work, it needs to just be a bunch of smart people without administrative time-wasting. 
Here's how I plan to develop this: the vocabulary is up on GitHub. tommorris/voperm is the repository. Feel free to fork the repository and do whatever you like with it. If you think you can make it better, just try it. Then send me a pull request. If your idea is good, I'll pull it in and merge it. If you have an idea or issue with how it currently works, feel free to post your problems on the issue tracker. Or find me on IRC and tell me what the problem is. Or send me an e-mail. 
Basically, I'm using this to see if we can develop a simple vocabulary in the same way as some of the bleeding edge Ruby open source people develop code - without bureaucratic overhead. Because, frankly, that stuff sucks. In the Rena development so far, we haven't really had to use a mailing list. It's been really good. Just version control, IRC, bug tracker and a few private e-mails. (I'm not ruling out ever having a mailing list, but I'm holding off for now.) 
Anyway, how is voperm going to work? I'm hoping that we can develop it as an RDF vocabulary, but we can also find ways to make it fit with other technologies: obviously, RSS/Atom feeds are a good starting place for this, as well as ther XML format that people use to publish content. The RDF community are a good group to start this, as they have a pretty good idea of how to develop vocabularies. We need to design it in a way so that it works well for RDF data, but can also work for non-RDF data. This could be as simple as having a way that people can point to permissions profiles. 
I'm hoping that lots of non-RDF people can get involved - microformateers, XML-o-nauts, RESTers and everybody else. N3 syntax and OWL constructs are fairly easy to start using - just look at the existing code, perhaps if you are using TextMate, get the N3 bundle for syntax highlighting. 
I'd love to work on this at VoCamp, but I'm not on the list, alas. Might do a session at the next BarCamp, which will be BarCamp Brighton 3. 

