Eran Hammer-Lahav makes his case

4 views
Skip to first unread message

Elias Bizannes

unread,
Jun 10, 2008, 3:38:11 AM6/10/08
to DataPortability.General
Eran Hammer-Lahav several weeks ago issued a critical blog post of the
DataPortability Project's efforts [1].

Subsequent to that blog post, we engaged in an 80 minute discussion
after I reached out to him - like I have with others, but Eran is the
only person to back his words. That was followed by several e-mail
exchanges going back and forth, clarifying our opinions. The outcome
of that exchange are Eran's core criticism.

So I am presenting below two of the key points that Eran makes - and
open it up to the community, to give feedback on his perspective. Eran
has agreed to debate this if challenged, and it represents his
constructive efforts as an individual, to help the DataPortability
Project evolve into an organisation that adds value to the industry.

-----------------
1) Technical blueprints/best practices
Erans view: DataPortability should not be advocating a single solution
for technical implementations. The Project should discontinue any
indirect involvement in the technical area, join existing conversation
within the communities already working on each of these standards, and
leave it up to the market to decide which standard or solution is
'recommended'. Instead, the Project should focus on creating "how-to"
guides that will make use of multiple open standards. It will be a way
for developers to read and implement, with the focus of DP
participants to identify potential solutions, as well as areas where
solutions are needed.

2) Positioning and mandate
Eran's view: DataPortability should consider itself a special interest
group. DP needs to first build a case for its cause - something that
is far from being a done deal. DP needs to identify those it seeks to
influence and ask them to define what their needs are to support DP's
objectives, not tell them what they need.

---------------
I have countered Eran's views, but I will add my perspective
separately once others join in. If there is anyone else in the broader
community that wishes to propose change for the DataPortability
Project - you can either post it as a thread on this mailing list or
contact me on my e-mail and I will be happy to listen to your concerns
to see if we can resolve them somehow.

Regards,
Elias

[1] http://www.hueniverse.com/hueniverse/2008/05/the-big-pink-el.html

David Novakovic

unread,
Jun 10, 2008, 5:11:00 AM6/10/08
to DataPortability.General
> 1) Technical blueprints/best practices
> Erans view: DataPortability should not be advocating a single solution
> for technical implementations. The Project should discontinue any
> indirect involvement in the technical area, join existing conversation
> within the communities already working on each of these standards, and
> leave it up to the market to decide which standard or solution is
> 'recommended'. Instead, the Project should focus on creating "how-to"
> guides that will make use of multiple open standards. It will be a way
> for developers to read and implement, with the focus of DP
> participants to identify potential solutions, as well as areas where
> solutions are needed.

Companies will do what they want.... but it'd still be good to have a
single reference stack for people use.

Perhaps we could have "DP Compliant" and "DP Reference Compliant" so
vendors can use an approved stack, or use the reference stack?

Just a thought.

>
> 2) Positioning and mandate
> Eran's view: DataPortability should consider itself a special interest
> group. DP needs to first build a case for its cause - something that
> is far from being a done deal. DP needs to identify those it seeks to
> influence and ask them to define what their needs are to support DP's
> objectives, not tell them what they need.

While I agree with this, most of the things that people will talk
about are generally accepted standards anyway, like RSS.

Many companies aren't quite sure how XRDS works or what it is for
example, yet upon understanding how it helps the DP process they are
often excited by the prospects. I definitely agree with the sentiment
here though.

David

Jacob Chapel

unread,
Jun 10, 2008, 6:36:39 AM6/10/08
to DataPortability.General
> 1) Technical blueprints/best practices
> Erans view: DataPortability should not be advocating a single solution
> for technical implementations. The Project should discontinue any
> indirect involvement in the technical area, join existing conversation
> within the communities already working on each of these standards, and
> leave it up to the market to decide which standard or solution is
> 'recommended'. Instead, the Project should focus on creating "how-to"
> guides that will make use of multiple open standards. It will be a way
> for developers to read and implement, with the focus of DP
> participants to identify potential solutions, as well as areas where
> solutions are needed.

From the beginning, DP.org has made it known that they are not pushing
one set of standards as the only option. How can you tell DP.org to
stop researching what they think are the best solutions to the
problems we face when that is ultimately what any new standard or
technology group is trying to do themselves? Although DP.org isn't
creating new technology, the value of researching existing
technologies to come up with best case solutions is going to be there.
Regardless of what DP.org recommends that companies and developers
use, they will find their own solutions if they disagree. I find that
DP.org is in a unique position to find holes in existing solutions as
well as bring new ideas to the table that otherwise might have taken
longer due to narrow minded views.


> 2) Positioning and mandate
> Eran's view: DataPortability should consider itself a special interest
> group. DP needs to first build a case for its cause - something that
> is far from being a done deal.  DP needs to identify those it seeks to
> influence and ask them to define what their needs are to support DP's
> objectives, not tell them what they need.

Where does it say that DP.org has to do anything that it's not already
doing? I don't understand where people feel the need to put DP.org in
some off the grid area that says you can't be around unless you prove
yourself. Your first request states that DP.org should let the market
pick the best solutions, why can't you let the market choose to follow
DP.org or not?

The fact is that all those companies came to DP.org, all these people
came to DP.org, I came to DP.org. I don't see where DP.org needs to go
out and prove itself when it has never claimed to force anyone or
anything into anything they weren't going to do in the first place. I
know the concept of data portability and everything surrounding it is
a heated topic, but once you get past all the chest thumping and down
to the roots of the matter, we all want the same thing and I think
DP.org is the way to get it done. If you don't agree, then join DP.org
and fix it, or go do your own thing. (Speaking more in general to
anyone.) If DP.org disappeared today, you could not say that they
didn't do anything worthwhile for the cause of data portability. They
have pushed the issue of data portability to the forefront of
everyone's mind, and now it is one of the biggest issues facing the
internet today. Can you say that 7-8 months ago?

Phil Wolff

unread,
Jun 10, 2008, 9:03:03 AM6/10/08
to dataportabi...@googlegroups.com
> 1) Technical blueprints/best practices

> Erans view: DataPortability should not be advocating a single solution for technical implementations.

I agree with this Eran on this. I've heard people speaking on behalf
of dp.org say there is one way, only one way, one combination of
protocols, and that it is dp.org's charter/mandate to define this.

This despite the wisdom that
- there are many paths to solve a problem,
- no one solution meets all use cases,
- there are always more smart people outside of an organization than inside,
- that change is fast at the technical implementation level, slower at
the architectural level, and much slower when you get to first
principles and core beliefs.

I'd like to see dp.org shift its design capabilities higher up the
layers of abstraction, higher than individual protocols. For example,
don't endorse the xfn/rel=me protocol but examine identity
consolidation alone and in a broader dp context.

> The Project should discontinue any indirect involvement in the technical area,

I disagree with Eran here.

There is much to be learned from hands-on experimentation and many
people in the tech community learn and teach and communicate through
code and design. I think there is room for dp.org to operate a
sandbox, a labs.dp.org if you will, for learning the strengths and
limitations and practical know how associated with making dp work in
the field.

> join existing conversation within the communities already working on each of these standards,

I think dp.org members can add value to those communities when dp.org
has a clearer definition of what dp really means in functional and
policy terms. Meanwhile, there's a lot of to learn by swimming in
other pools of knowledge and bringing back language, prior art, and
useful/failed concepts to our dp commons.

> and leave it up to the market to decide which standard or solution is 'recommended'.

Agreed, to a degree. We've already seen some orgs claim "we're doing
data portability" when they're not. Although at some point dp.org
could add value by praising behavior that's consistent with dp.org
values and our vision of dp.

> Instead, the Project should focus on creating "how-to" guides that will make use of multiple open standards. It will be a way for developers to read and implement, with the focus of DP participants to identify potential solutions, as well as areas where solutions are needed.

I agree that effective technical, managerial and consumer education,
one-stop-learning, should be part of dp.org's future.

> 2) Positioning and mandate

> Eran's view: DataPortability should consider itself a special interest group. DP needs to first build a case for its cause - something that is far from being a done deal.

+1.

It will help when dp.org is both clear and explicit about the vision
of a future with rich, pervasive, mature data portability. We've
barely started, although I think this may be low hanging fruit.

> DP needs to identify those it seeks to influence and ask them to define what their needs are to support DP's objectives, not tell them what they need.

+1.

There's a kind of respect you offer when you listen to others. Dialog
and discourse instead of selling and broadcasting. I think some of us
have embraced this approach but it is always difficult to keep your
center and listen with an open mind.

Eran, thanks for the critique and opinion.
Elias, thanks for the respectful followup.

Phil Wolff
managing editor, Skype Journal
http://SkypeJournal.com
pwo...@skypejournal.com
skype:evanwolf
+1-510-444-8234 San Francisco
+1-646-461-6123 New York
+44 020 8816 8780 London
+852 8175 8107 Hong Kong
http://www.linkedin.com/in/philwolff
http://www.facebook.com/profile.php?id=724232370

Daniel Parker

unread,
Jun 10, 2008, 10:01:16 AM6/10/08
to DataPortability.General
I have a few things to input, as a developer working toward data
portability in my applications. Also, I've read the responses so far
and I see some of the same thoughts in various forms. I have a pretty
clear picture of what I'd like the DataPortability Project to be, that
would do an extremely high amount of good to developers and standards
designers alike. That picture is...

+ A Measuring Rod for Standards: Developers who don't want to or have
a difficult time analyzing a standard, like OpenID or OAuth to
determine its level of security or its concern for privacy would
benefit greatly from a central place like DataPortability where the
ones who dig into those things have rated, outlined, reviewed, and
discussed (note the increasing verbosity) each standard's levels of
security, privacy, etc and their vulnerabilities. Levels/Ratings of
things like decentralization, user control, and more could be reviewed
and analyzed for the world to see. This would help developers to know
the characteristics of standards when they're choosing them; and it
would likely be a great help to train them on what to look for and
help bring up the next generation of standards designers to know what
they're dealing with and the many different types of vulnerabilities.

+ A Guide to DP Standards: Developers like me would love to have a
place that would help me make decisions as to which standard to use
when. For many specific use cases, there will be one or two standards
that rise above the rest. Being able to see a short description for
each standard and how it can be used would be hugely helpful to
determining what will work best for my website/application.

(I wouldn't mind if DataPortability also defined an ethically
acceptable characteristics of good privacy, but I know there's a
larger underlying problem with attempting to have a large diverse
group of people try to define ethics.)

+ A Place for Discussion: *About the characteristics of standards.*
This would include pointing out vulnerabilities, strengths,
weaknesses, concerns about privacy, perhaps (with a little hesitancy)
suggestions. This would also include, as the nature of our work will
define the place each standard has in the web of standards, finding
and pointing out areas of missing standards. Places in the graph/web
of standards where there is a need for a new standard. And a small
group of interested people can start their own group after discussing
and defining the needs and use-cases for their new standard.

- - - - - - - - - - -

Thus, in this picture, the work of designing (and recommending)
standards is left untouched, but is fostered and cared for as new and
growing standards are well-loved, written about, critiqued, inspected,
and sometimes put on their own pedestal (as in, their ratings in
critical areas/characteristics show off their own greatness). As the
group contains many people who design standards, it would be a perfect
place for people to recommend new standards to come about. But the
MAIN WORK in the group would go toward exposing standards with the aim
of classifying and describing them, to increase awareness of what they
are and how they should be used: Let people create standards as they
choose, and DataPortability will put it under a microscope and explain
to the world what it is, where it's useful, where it fails, and
(perhaps, it'd be a big stretch) how to use it.

- - - - - - - - - - -

"To Consult, Design, Educate and Advocate Interoperable Data
Portability to Users, Developers and Vendors."
That is actually a HUGE goal. One of the biggest I've seen, perhaps
even bigger than "To organize the world's data." Design? That's way
too big already. Educate? That's a big one by itself. Advocate? That's
a rather special-interest group, wouldn't you say? It really doesn't
need to be inter-connected with the rest of the group's efforts, only
benefit from them. I'd say we definitely do need a re-write.

~Daniel
> managing editor, Skype Journalhttp://SkypeJournal.com

John Breslin

unread,
Jun 10, 2008, 1:07:58 PM6/10/08
to dataportabi...@googlegroups.com

>> Erans view: DataPortability should not be advocating a single
solution for technical implementations.

> I agree with this Eran on this. I've heard people speaking on behalf
of dp.org say there is one way, only one way, one combination of
protocols, and that it is dp.org's charter/mandate to define this.

> This despite the wisdom that - there are many paths to solve a

problem, - no one solution meets all use cases, [...]


> I'd like to see dp.org shift its design capabilities higher up the
layers of abstraction, higher than individual protocols. For example,
don't endorse the xfn/rel=me protocol but examine identity consolidation
alone and in a broader dp context.

Phil - I really like your point above. Not only should one solution not
be advocated for a particular data portability problem, one solution
can't fit all requirements (due to preferred vendor technologies and
existing deployments, but also user requirements and platforms).

Let's say I'm a Semantic Web guy (it's true!) - I know there will
possibly be some cases for which RDF may not be the most suitable method
for providing data portability in particular scenarios. Take a social
media contribution [SMC] portability scenario (your blog entries,
bookmarks, etc.) and imagine that RDF was the current recommended
solution for the problem of getting your contributions from one service
to another - if you already have access to an API that allows you to
query for your SMCs in XML or JSON, well, it's probably not necessary to
have a mirror of the RDF there or alternatively there may not be RDF
libraries / parsers available... There has to be some flexibility...
You can show that RDF worked for problems X and Y, and that some
metadata contained in JSON fields as well as embedded within text
strings works for other use cases.

Actually, I think that Phil's abstraction idea is a great one. Rather
than saying, here's a bunch of standards and de-facto representation
methods, you could break it down into problem areas (let's face it, most
of the structured representation formats we have like RSS, FOAF,
microformats are not standards written by standards bodies, and those
that are just now gaining adherents like APML and *cough* SIOC may still
seem to be the best bet for representing certain types of data to be
ported even if they are not endorsed by [m]any big players just yet).
So the portability challenges could be listed on the main page rather
than the technologies, quick linking to more info:

* Portability challenge -> Formats, Use Cases

* Social network portability -> Links to the page where you have formats
like FOAF and hCard / XFN are at the top, with other suggestions added
afterwards, followed by actual implementations of moving social network
data from A to B describing what formats / protocols / languages were
used...
* Social media contribution portability -> Links to Atom, RSS, XMPP,
SIOC, etc. with some use cases showing how it was done...
* Business document portability -> List standards, detail use cases
(maybe the standards listed could be auto-generated from those specified
in the use cases, reflecting actual deployment)...
* Attention / interest portability, etc. -> APML, FOAF, etc.

The above list reflects another item of interest or perhaps even mild
concern. Talking to Chris Saad about this, I realised that the vision
for DataPortability was not just for the group to address ways of
getting your profile, friends and content from one social website to
another. Rather, users should be able to port any data they have / own
/ created across systems / sites / applications - not just social
website stuff. I am not sure is everyone aware of this, but so far the
focus has certainly been very much on social websites... Just checking!

John.
--

Chris Saad

unread,
Jun 10, 2008, 2:19:30 PM6/10/08
to DataPortability.General
Actually John,

I don't mean to contradict you - but DataPortability is firmly in the
camp of user-centric data interop - users moving their personal data
- not moving whole communities from app to app.

That is certainly more in the SIOC camp :)

Chris

John Breslin

unread,
Jun 10, 2008, 4:32:55 PM6/10/08
to dataportabi...@googlegroups.com
Hi Chris - okay, good stuff - when I said "users should be able to port
any data they have / own / created across systems / sites / applications
- not just social website stuff." - I was just saying that it could be
your Google Alerts, your favourite book topics, your SharePoint work
documents, etc. - not just social website stuff...

Cheers for the clarification!

John.
--

Phil Wolff

unread,
Jun 10, 2008, 9:39:26 PM6/10/08
to dataportabi...@googlegroups.com
On Tue, Jun 10, 2008 at 11:19 AM, Chris Saad <chris...@gmail.com> wrote:
> I don't mean to contradict you - but DataPortability is firmly in the
> camp of user-centric data interop - users moving their personal data
> - not moving whole communities from app to app.
>
> That is certainly more in the SIOC camp :)

Chris, why wouldn't the principles of an individual user's rights to
their data not apply to those same people when part of a group?
Shouldn't the Oakland Raiders fan club on facebook be able to set up
well-sync'd spaces on their NFL.com site and their meetup.com group
and upcoming.yahoo.com group?

Seems to me this should be within the larger dp.org scope, consistent
with our purpose.

Christian Scholz / Tao Takashi (SL)

unread,
Jun 11, 2008, 8:44:20 AM6/11/08
to dataportabi...@googlegroups.com
So here's my take :)

On Tue, Jun 10, 2008 at 9:38 AM, Elias Bizannes
<elias.b...@gmail.com> wrote:
>
> Eran Hammer-Lahav several weeks ago issued a critical blog post of the
> DataPortability Project's efforts [1].

> -----------------


> 1) Technical blueprints/best practices
> Erans view: DataPortability should not be advocating a single solution
> for technical implementations. The Project should discontinue any
> indirect involvement in the technical area, join existing conversation
> within the communities already working on each of these standards, and
> leave it up to the market to decide which standard or solution is
> 'recommended'. Instead, the Project should focus on creating "how-to"
> guides that will make use of multiple open standards. It will be a way
> for developers to read and implement, with the focus of DP
> participants to identify potential solutions, as well as areas where
> solutions are needed.

As I stated before I think it is hard anyway to come up with a
solution which fits everybody and define this as a standard. Business
(as has been said) are doing what they want anyway and probably use
DP.org mainly for PR reasons (which we should clarify then though). I
still would like DP.org to be some sort of place for discussion for
such technologies and see what evolves from that. Doing that inside
existing communities can be sometimes a bit complicated as I
personally at least encountered many dogmatic people there who say
"our standard or no standard" (not that harsh but going into that
direction). Furthermore I think that not everybody thinking about DP
right now is involved in these groups and getting involved in 10
groups is harder than in 1 group. I don't want to say though that we
should be involved in those groups as this help to solve the problem.

As for the market I think there is no other way as to let it decide
anyway. And of course there cannot be one solution which solves all
data portability problems of the world which brings us to point 2:

> 2) Positioning and mandate
> Eran's view: DataPortability should consider itself a special interest
> group. DP needs to first build a case for its cause - something that
> is far from being a done deal. DP needs to identify those it seeks to
> influence and ask them to define what their needs are to support DP's
> objectives, not tell them what they need.

I also think (if that's meant here) that we first need to define the
problem or rather problems more in detail. I still think that many
people involved all have a slightly different view what we want to
accomplish (e.g. regarding what level of privacy/controls to ensure).
And right now we are even just looking at the social networking field.
This already can be quite broad.
I personally think we should start with defining use cases in more
detail, then think about policies for them and define what people
should actually be able to control (I just did a session on that at
the IdentityCamp in Bremen last weekend, need to write it down
though). Based on that we can think of technologies or at least about
a high level architecture which might fit it (e.g. I don't think it
can be too decentralized as this gives us all sorts of syncing
problems).

What we have been good at though (I think) is to raise awareness of
the issue. Otherwise even all these negative discussions wouldn't have
happend. We should of course keep doing that and also explain to
businesses and users why this is good for them (at the IdentityCamp in
every session about DP we first had a discussion whether users need
this or not, might be a german thing though ;-) ).

In general we somehow need to get more discussions going though
(doesn't matter if on dp.org or somewhere else IMHO) because right now
the group discussing things is rather small. I would like to know what
the issues for businesses are, what obstacles they encountered when
trying to implement it etc. This maybe do not need to be the big ones
like yahoo et al. but also the smaller ones. At the IdentityCamp we
e.g. had some smaller ones describing their problems with OpenID
delegation, something like that.

So my idea would be:

1. Get the structure right and advertise where is what discussed,
advertsie this also inside the standards communities
2. Define the problem we want to solve (this actually could eventually
split the project into working groups working on different problems)
3. Define policies around these problems
4. Think about technology, get as many people as possible to discuss
and implement things. Maybe some good solution will come up after a
while (that's actually happening already anyway).

So much from me.

cheers,

Christian

--
Christian Scholz
Tao Takashi (Second Life name)
taota...@gmail.com
Blog/Podcast: http://mrtopf.de/blog
Planet: http://worldofsl.com

Company: http://comlounge.net
Tech Video Blog: http://comlounge.tv
IRC: MrTopf/Tao_T

Reply all
Reply to author
Forward
0 new messages