It’s the morning of day one of the first Project VRM Workshop. Doc Searls gave a quick intro, while Joe Andrieu outlined some VRM projects already in progress. Much to talk about, and so far Kaliya (aka IdentityWoman) has helpled orchestrate a tightly packed couple days. Looking forward to diving in.
Some Project VRM initiatives and tie-ins in progress:
Personal RFP - Ability to place a formalized request into the marketplace so that it can be fulfilled by vendors.
Personal Datastore - Data storage (local or distal) under control of the user as the basis for their personal information.
Personal Address Manager - A mechanism for managing address changes between users and their vendors.
Paychoice - A new business model where readers, listeners and viewers can quickly and easily pay for the media they consume.
RelButton - A representation of the VRM relationship available and the entry point for interaction.
rCard - A representation for connecting your Personal DataStore with a trusted partner via an “umbilical cord” allowing for two-way communication.
More to come as the sessions are finalized as interesting items pop up.
UPDATE:Check out the summary of Twitter comments via the #VRM08 query on Summaryize.com for snippets coming out of the workshop.
I recently I had a chance to chat withJoe Andrieu about his work chairing the standards committee for the VRM Project. During that discussion, we talked a lot about where VRM is in their development process as an organization, and it was interesting to see the similarity to where we are with the DataPortability Project.
Following along that conversation, Joe recently posted about VRM where he mentioned DataPortability:
As an example, the Dataportability movement has framed the problem in terms of Data and Portability. This brings to mind exporting and importing “my” data from vendor to vendor. That’s a start toward liberating users from vendor silos. However, I think the real win is in user-centric services, where the location of the “data” is essentially irrelevant–even as it is hosted under the control of the user–and all user-authorized vendors can access the data through approved services.
This, in my mind, is fallout of a misnomer buried in the phrase “data portability”, and by extension in the name of the group. I’ve attended (in person or virtually) a lot of DataPortability Project events, and this discussion comes up a lot. It basically goes something like this:
Alice: “I think the DataPortability Project is too focused on download and upload of my data.”
Bob: “Yeah, sometimes I don’t want to move my data around, I just want my accounts to access my data from each other.”
David: “If that’s true… then we need to do a better job articulating this connection to the community.”
… and that’s just about where the conversation ends each time. Apparently, we’re still not doing a good job explaining ourselves.
In short, there’s no expectation that the frameworks, standards, etc. being evaluated will require “physical movement” of data between systems. We fully assume that the data need only be accessible across systems.
Basically, I think the term “Data Portability” simply caught on (along with the mistaken understandings) as it flows better than “Data Accessibility”. So we just need to work that much harder to spread the word.
