Words matter.
In the last few years, we in the VRM community have been using term “personal data store” as cornerstone concept. We all understood we were talking about the same thing: a VRM approach for allowing people to use share personal information with third- (and fourth-) party service providers on their own terms.
Yet as our community grows, it has become clear that the Personal Data Store is but one aspect of a complete system, one we might as well call the Personal Data Architecture. As developers get more traction with their technology and the marketplace, it gets more and more useful to delineate the elements of the architecture more rigorously.
To do that, Doc Searls, Craig Burton, Iain Henderson, Kaliya Hamlin, and I set some time aside after the VRM+CRM 2010 Workshop. Like the ongoing VRM conversation, it was a rolling evolution of a dialog. It started with just Craig & Iain with the rest of us showing up and participating throughout the afternoon. The core agreement is the terms I present here. I’ll post a following up with some new ideas in a few days.
These are the key definitions underlying the Personal Data Architecture at the core of VRM and all of our work:
Personal data store – a service where data is actually stored, with the ability to provision access to that data by permissioned applications; may be distributed and/or replicated across multiple physical stores.
Personal data exchange – a service where an individual manages personal data store permissions.
Personal data API – the interface a permissioned application uses for accessing personal data stores and personal data exchanges.
Personal data application – a service permissioned by an individual to access their personal data store for particular use of specific information. Also an “app”.
Service – an instance of software running on a machine.
Individual – a living human being.
Bonus Term: (which wasn’t the topic of this particular meeting, but syncs up with the work Iain and I are doing over at the Kantara Initiative’s Information Sharing Work Group.)
Information Sharing agreement – an agreement between the discloser and the recipient governing the permissioned use of specific personal information.
This language will continue to evolve, I’m sure. For now, this is a good snapshot for those of us building systems for sharing information between users and applications and for using that shared information.
So, hopefully, the next time you hear PDS, you’ll know what it is…
Pingback: » Do we have to “trade off” privacy? ProjectVRM
Pingback: VRM builds closer links with CRM | Creative Agency Secrets
In your definitions the PDS is the place where the data is located (stored). But I think there is a need for a personal dashboard that allows you to see and to some extent manage external stores of data about you.
Paul,
There is definitely a need to see and manage stores of data under our control. If by personal dashboard you mean a browser that seamlessly lets us view, edit, and permission our various personal data stores, I agree. I especially find it frustrating that the data we give up via Facebook and Twitter doesn’t have a simple interface for that kind of management. I Shared What?!? at http://isharedwhat.com was an effort to illustrate the kind of transparency that is currently missing when you use Facebook as a PDS.
If you mean yet another website I have to use… that I think might not be as useful.
Part of why the web works its decentralization. I don’t see personal data stores re-centralizing it, even though many PDS ventures *are* focused on creating a new personal data silo.
I think the natural place for controlling your data is *within* the workflow of the web, in the individual’s context. Which, to me, says it’s in the browser, or at least seamlessly connected to the browser.
Which connects back to Doc Searl’s work on the R-Button. We don’t need another website as much as we need a new affordance for web-based interactions that rely on individual-provided data.
Pingback: Your Data and Its Value to You | Internet Theory