Data Portability Secret Sauce
Josh Patterson
http://factoryjoe.com/blog/2007/11/26/data-portability-and-thinking-ahead-to-2008/#comments
this morning and he made some very interesting points about how there
is a very strong need for symmetric-ness in maintaining one's identity
on the web, in terms of it being citizen centric. I whole-heartedly
agree, and he also linked to Doc Searls blog entry on "writing our own
rules" http://blogs.law.harvard.edu/doc/2007/11/25/time-to-write-our-own-rules/
about how we need to gain more control over our data. Both of these
articles are very good reads on what needs to be done in terms of
results.
So now, I want to ask --- whats missing on a technical level? We've
kicked around prototype ideas such as WRFS - http://cowbell.floe.tv/WRFS_11_20_2007.html
, but to truely make the citizen in control of their data without
inundating them with a million configuration panels, making the
solution a turnkey operation, all while making sure its not a security
nightmare --- where are we breaking? where are we doing the "right
thing"? The drivers for change are picking up steam, and the stage is
set, but it has to be executed just right and without a large mistep
that would provide a PR disaster (ie, "oh look, a major data breach,
your data is not ever safe there! it never will be! come back to the
silo! only in the silo can you be safe! fud! fud! fud!" )
I think in the end, to pull off a citizen's web/graph of truly open
data, those 3 things (and others) have to be addressed, and when
someone pulls that off, then that will be data portability's "Secret
Sauce".
Chris Messina
demonstrating what the flows would actually be, rather than starting
with technology (in fact, technology should never come first).
We talk about portable friend lists, and we've seen some of that on Dopplr.
We talk about portable profile data and we see that on
GetSatisfaction.com and Lifestrea.ms.
We talk about a personal/portable social graph but we haven'
demonstrated what, in actuality, that looks like, writ large.
I think Dopplr and STFN are good test beds and they "get it", but I
think we're a ways from 1) providing an economic justification for
moving in this direction except for extremely early adopters and 2)
haven't provided a user experience that's salient, sensible or easier
than today's siloed approach.
If we start with solving real world problems first, the technology
will practically produce itself.
Chris
--
Chris Messina
Citizen-Participant &
Open Source Advocate-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412.225.1051
IM: factoryjoe
This email is: [ ] bloggable [X] ask first [ ] private
Josh Patterson
I agree completely with the part about solving real problems. With our
video editor and Saad's multiple other properties, we are solving
problems (at least problems interesting to us), but at the same time
as implementors and designers we have to lay out groundwork and
blueprints to solve these "real problems". My post is not so much
aimed at a general audience, but moreso at this private group and the
implementation challenges we face in solving these problems. For
instance, the other day Chris Saad and I were discussing ways in which
to allow users to control their data not only in terms of who could
use it, but for how long, and how it could be used. We know this is a
abstract piece of technology, but at the same time, one day soon it
will be solving real problems in some form, but until its ready to see
the light of day, it has to get hammered out in the lab. I dont think
anyone is really interested in throwing anymore acronyms onto the
pile; I think the real focus that Chris Saad and I have discussed is
implementing the stack abstraction in a set of beta applications that
are focused at solely solving a few key problems, and then seeing what
users think, and letting the market function decide if we've hit a
sweet spot in terms of value. floe.tv will always be focused on being
a media mixer, and we (so far) are only focused on using the WRFS
stack as a backing technology to solve the "real problems" and needs
that our users tell us about, which is why the very first section in
the document states our user feedback scenario where they directly
requested data portability. I led off with that because providing a
solution to that real problem is our driving focus. When we finally
execute the user experience we have drawn up, I think it will be a
salient, sensible and much easier user experience than today's siloed
approach. In the end, we are solving real world problems, but at the
same time we have to have a discourse about how best to make them
secure, scalable, and smart.
Josh
On Nov 26, 2:06 pm, "Chris Messina" <chris.mess...@gmail.com> wrote:
> Actually, it needs to start with solving real problems and
> demonstrating what the flows would actually be, rather than starting
> with technology (in fact, technology should never come first).
>
> We talk about portable friend lists, and we've seen some of that on Dopplr.
>
> We talk about portable profile data and we see that on
> GetSatisfaction.com and Lifestrea.ms.
>
> We talk about a personal/portable social graph but we haven'
> demonstrated what, in actuality, that looks like, writ large.
>
> I think Dopplr and STFN are good test beds and they "get it", but I
> think we're a ways from 1) providing an economic justification for
> moving in this direction except for extremely early adopters and 2)
> haven't provided a user experience that's salient, sensible or easier
> than today's siloed approach.
>
> If we start with solving real world problems first, the technology
> will practically produce itself.
>
> Chris
>
> > is a very strong need for symmetric-ness in maintaining one's identity
> > on the web, in terms of it being citizen centric. I whole-heartedly
> > agree, and he also linked to Doc Searls blog entry on "writing our own
> > rules"http://blogs.law.harvard.edu/doc/2007/11/25/time-to-write-our-own-rules/
> > about how we need to gain more control over our data. Both of these
> > articles are very good reads on what needs to be done in terms of
> > results.
>
> > So now, I want to ask --- whats missing on a technical level? We've
Chris Messina
"but at the same time we have to have a discourse about how best to
make them secure, scalable, and smart."
I'd rather see this group focus on documenting existing pain points
and prescribing antidotes that could alleviate that pain for issues
found in the wild... And perhaps that's the route we're already on.
I suppose the simplest way to make some progress here is to have a
clear mission statement for dataportability.org. What we have there
now is a bit too grandiose and unfocused; I might suggest something
like:
"leveraging existing open and non-proprietary protocols, formats and
standards in support of ..."
Well, that's where things start to go fuzzy. I'd like to say "user
choice" or "better user experience" but again those things are far too
abstract. In support of "data portability" doesn't make much sense,
since it doesn't, by itself, lead to improving anything.
So, I think to put it to a point again, how does this "stack" make
things better again? Can we point to real world examples where having
"data portability" has lead to improved choice or customer experience?
Chris
Chris Saad
have another crack it in that thread - anyone else want to contribute
there?
Cheers,
Chris
On Nov 27, 6:54 am, "Chris Messina" <chris.mess...@gmail.com> wrote:
> I was with you up until your last sentence. ;)
>
> "but at the same time we have to have a discourse about how best to
> make them secure, scalable, and smart."
>
> I'd rather see this group focus on documenting existing pain points
> and prescribing antidotes that could alleviate that pain for issues
> found in the wild... And perhaps that's the route we're already on.
>
> I suppose the simplest way to make some progress here is to have a
> clear mission statement for dataportability.org. What we have there
> now is a bit too grandiose and unfocused; I might suggest something
> like:
>
> "leveraging existing open and non-proprietary protocols, formats and
> standards in support of ..."
>
> Well, that's where things start to go fuzzy. I'd like to say "user
> choice" or "better user experience" but again those things are far too
> abstract. In support of "data portability" doesn't make much sense,
> since it doesn't, by itself, lead to improving anything.
>
> So, I think to put it to a point again, how does this "stack" make
> things better again? Can we point to real world examples where having
> "data portability" has lead to improved choice or customer experience?
>
> Chris
>