Filters through a personal datastore lens

Returning to the theme of personal datastores ...

Services like The Filter consist of several parts:

• A social networking component. Who knows whom? Everybody and their dog has this now, which is unfortunate, since each then has its own slightly different copy.
• A database of things you've done through the service. Music services, for example, have a record of what you've bought and perhaps of what you play. Your email service, whether it's web-based or not, has a record of whom you've emailed and who's in your address book. Unlike the case of social networks, different kinds of services have different kinds of associated data, but for a particular kind of data, each service still has its own slightly different copy.
  
• An engine that pulls the rest of the data together and tries to give you something of value from it. This is the secret sauce. Different music services will have different ways of recommending music (and different music collections to draw from).

One of the core tenets of personal datastores, as I understand the concept, is that data about you should be centered around you and you should control it. In the current "data fiefdom" model, every service has its own record of whom you know and what you've done. That's of value to them, of course, so they treat it as their data, but this means that, leaving aside the obvious privacy concerns, each service has a different, incomplete view of your world. Such an incomplete view is less valuable to the service provider than a complete one would be.

On the other hand, it's about you, so why shouldn't you control it? If you control data about your history and connections, you benefit because you control access to it and because all your data is in one place. In such a world, if you subscribe to a service that wants to know about your listening habits, you give it permission to see your music choices -- and nothing else. Then when you listen to a song using whatever means you like, the recommendation service knows about it. You don't have to use their web site or do things their way. If you switch services, you don't have to somehow move your history from the old service to the new one.

Whether the service providers would go for such a scheme remains to be seen. On the one hand, it lets them give better service, because they have better information and can get to it easily and uniformly. On the other hand, it eliminates a form of "vendor lock-in". If you can easily switch from their service to someone else's, maybe you will. This is a problem for established players, but a good thing for upstarts.

If you buy the premise that data about connections and history should move from the services to the person using the service (or more likely a datastore provider acting on that person's behalf), then all that's left is the engine. How would this work?

• I launch a new service promising to recommend, say, lawn care products based on the music you listen to. Hey, stranger things have happened.
• If you want to subscribe, you give me access to your music database (or, if you don't want me to know about your secret obsession for accordion music, you give me access to a sanitized view of it). This access would typically include a feed of updates, so that if you bought a new song I would know about it. My engine crunches that data and gives you recommendations.
  
• You might also choose to give me access to your "casual acquaintances" data. In that case, if an acquaintance also joins and also grants the necessary permissions, my engine will know about it and (perhaps) make better recommendations to both of you.

Technically, this seems pretty nice. Each party deals with what it's most equipped to deal with. You maintain your personal data, I run my engine. There's only one copy of the personal data. You can give out or withhold permission as you see fit.

As I've said before, with more or less cynicism, it's not clear how or whether we get to such a world from here, but it does seem like a pretty sensible world.