In this very special episode of the DataPortability: In-Motion Podcast, Trent’s brother R. Mark Adams joins the data portability discussion. He is a genetic engineer who earned his Ph.D. in cell biology and was a pioneer in the field of bioinformatics. He is currently a Senior Associate at Booz Allen Hamilton and runs their bioinformatics group. Of specific interest related to data portability is his work for the open CaBIG (Cancer Biomedical Informatics Grid) project, a National Cancer Institute initiative to link cancer researchers and their data.
Up until now, we have focused primarily on the use cases around existing social networking websites. There is, however, a wealth of knowledge and experience to be tapped within other fields. Mark has worked for over 15 years designing and building large-scale informatics systems. Further, his extensive experience within the standards and open source communities place him in a unique position to provide valuable insight into issues being explored by the DataPortability Project.
During the conversation, Mark offered up some cautionary comments regarding the process of defining standards:
There’s a tendency on the part of industry, broadly, to try to skip to a technology stack as a means of adopting standards quickly.
One has to be careful in how one creates standards. This is why I say trying to divorce standards as cleanly as possible from their underlying technology implementations is important to do. The reason being it allows you to determine standards that can be widely adopted and used without the complexity or the risk of lock-in.
Rounding out the discussion was a call to action on both sides. Mark is reaching out to the DataPortability Project to become more involved in the bioinformatics field, and suggests we solicit participation from within their ranks.
Flowing out of the news, Phil chats briefly about his discussions with folks about how data portability will impact advertising. Similar to VRM, as we learned in our previous discussion with Joe Andrieu, it seems clear that businesses and consumers will benefit from standardized portable data.
Working toward making data more portable, Phil also talks about the DataPortability “Do It Yourself” projects he and David Recordon bandied about at a recent meetup in San Francisco. While it’s still getting off the ground, he’s working to formalize a number of small projects that can easily be implemented.
Our feature discussion is with Eran Hammer-Lahav about the XRDS-Simple specification he recently authored. He leads us through the history from his time working on the oAuth specification, and how the simplification of XRDS is complementary to other easily-implemented discovery techniques.
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.
