> 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
> 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.
--
Cheers for the clarification!
John.
--
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.
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