My Dataportability.org video
marc canter
http://www.youtube.com/watch?v=h9VVnrR58eE
I hope you enjoy it.
http://marc.blogs.it = blog
http://broadbandmechanics.com = company site
http://peopleaggregator.net = demo site
http://update.peopleaggregator.org = source code
http://wiki.peopleaggregator.org = dev wiki
Henry Story
> http://www.youtube.com/watch?v=h9VVnrR58eE
>
> I hope you enjoy it.
I like it, but again I don't think it is achievable via only data
portability. You can't move a whole network of information from one
system to another. Because as William Blake said so well [1]
To see a world in a grain of sand,
And a heaven in a wild flower,
Hold infinity in the palm of your hand,
And eternity in an hour.
The problem is that everything is linked to everything else. So if
you want to move the whole graph from one place to another, you may
end up moving all the data on that site. Since we are all related by 6
degrees of separation, moving my friends and their friends and their
friends would require moving all the data on one service to another.
Go a little further and you'd end up having to move all the
information on the internet. So we have a reductio ad absurdum. The
conclusion is impossible, so the antecedents are not compatible.
I can imagine someone arguing that the solution is simply to reduce
the ambition. We only want some small part of the data to be ported.
If we limit ourselves won't that do? Yes, but it won't give you what
you want. If you go to a new service and create an account there, and
then move over a graph of your friends, the information about your
friends that you have moved over to the new system will not be up to
date, unless your friends move over too. But your friends can't be
maintaining an account for you because you want your data to be
portable. Just think of it. If 10 of my friends move their data, then
I could end up with 10 accounts to maintain. Again we are led to an
absurd situation.
So no: the only solution is linked data. URLs to identify people, so
that I can move my data to a new service and still point to the URLs
of all my friends. If I move, no need for anyone else to move.
Henry
Julian Bond
>So no: the only solution is linked data. URLs to identify people, so
>that I can move my data to a new service and still point to the URLs
>of all my friends. If I move, no need for anyone else to move.
reductio ad absurdum
I have no problem imagining going to a site, signing up, and then saying
(hopefully automatically) my lists of friends is over there, read it,
find people who are already members here and make them friends. Because
this is what we already do with the very common "import my contacts from
gmail" function that almost every social site now does. The current
process is horrible, inaccurate, insecure and demands too much manual
intervention. But these are all relatively small problems that we can
fix.
There are some big wins to be had in DP without demanding that every
site completely re-architects and re-codes around a "better" way of
doing things.
--
Julian Bond E&MSN: julian_bond at voidstar.com M: +44 (0)77 5907 2173
Webmaster: http://www.ecademy.com/ T: +44 (0)192 0412 433
Personal WebLog: http://www.voidstar.com/ skype:julian.bond?chat
Un-Balanced Load
Henry Story
http://blogs.sun.com/bblfish/entry/proof_data_portability_requires_linked
Julian, there is very little infrastructure needed to publish a foaf
file.
And one does not even need every site to do so. Those that do will be
a lot nicer to work with though.
Henry
Daniel Lewis
I am glad to know that I am not the only one that has recently blogged
about this, I recently made this post:
http://vanirsystems.com/danielsblog/2008/02/14/my-view-of-dataportability/
I completely agree, a valid URI is one of the most perfect ways to
identify a person. A person being an object, and an object typically
has an ID to refer to, of which would be an OID in an Object Oriented
DataBase or a URI on a web system.
Using a URI one would be able to say "hey I am this person with URI
http://x.y.z/user/JoeBlogs" and thats where (for example) their
profile, contact and friends info resides.... and the most important
thing here though as that the information at that URI should be the
reference for information and not the source of information to copy/
paste. This is true data portability based on interlinked data.
Daniel
--
Daniel Lewis
* Technology Evangelist for OpenLink Software ( http://www.openlinksw.com/
)
* Personal Blog: http://vanirsystems.com/danielsblog/
On Feb 15, 8:35 pm, Henry Story <henry.st...@gmail.com> wrote:
> I just rewrote my argument a little more clearly I hope up here:http://blogs.sun.com/bblfish/entry/proof_data_portability_requires_li...
> Julian, there is very little infrastructure needed to publish a foaf
> file.
> And one does not even need every site to do so. Those that do will be
> a lot nicer to work with though.
>
> Henry
>
> On 15 Feb 2008, at 19:59, Julian Bond wrote:
>
Tao Takashi
Henry,
I am glad to know that I am not the only one that has recently blogged
about this, I recently made this post:
http://vanirsystems.com/danielsblog/2008/02/14/my-view-of-dataportability/
I completely agree, a valid URI is one of the most perfect ways to
identify a person. A person being an object, and an object typically
has an ID to refer to, of which would be an OID in an Object Oriented
DataBase or a URI on a web system.
Using a URI one would be able to say "hey I am this person with URI
http://x.y.z/user/JoeBlogs" and thats where (for example) their
profile, contact and friends info resides.... and the most important
thing here though as that the information at that URI should be the
reference for information and not the source of information to copy/
paste. This is true data portability based on interlinked data.
But we also should make it possible to easily change this URL and provide ways
to also use email adresses mapped to that URL (like Brad and others suggested).
If the user has to enter that URL it should be as easy as possible for him or her to do.
I know we talk about FOAF or XFN documents here but you need to start at one point.
-- Christian
--
taota...@gmail.com
Blog: http://mrtopf.de
Planet: http://worldofsl.com
RL: Christian Scholz, mrt...@gmail.com
http://mrtopf.de
Company: http://comlounge.net
Tech Video Blog: http://comlounge.tv
IRC: MrTopf/Tao_T
Chris Saad
I think you set the bar pretty high now - I wonder if anyone can match
it!
Chris
On Feb 16, 2:28 am, "marc canter" <m...@broadbandmechanics.com> wrote:
> http://www.youtube.com/watch?v=h9VVnrR58eE
>
> I hope you enjoy it.
>
> http://marc.blogs.it= blog
>
> http://broadbandmechanics.com= company site
>
> http://peopleaggregator.net= demo site
>
> http://update.peopleaggregator.org= source code
>
>
> 925 746 0549
>
> 925-876-0475-c
Julian Bond
>Julian, there is very little infrastructure needed to publish a foaf
>file.
>And one does not even need every site to do so. Those that do will be
>a lot nicer to work with though.
Did I argue against sites publishing FOAF? I don't think so. If that's
the impression I gave it's horribly wrong because I'm hugely in favour
of sites producing FOAF.
What I am against is building a social network or site with SN features
where profile and social graph information is not stored locally but
assembled on the fly at run time from external sources. Because you'll
never get from here to there with existing sites. Because we're not yet
at the stage where site and net performance would support this. And
because there are some query routes that simply can't be done without
local aggregation.
>So no: the only solution is linked data. URLs to identify people, so
>that I can move my data to a new service and still point to the URLs of
>all my friends.
This would be a nice feature as a secondary profile page. We're
beginning to see sites build in a YASN-Roll pointing to profiles for
that person on other sites. There's another possibility here which is a
Contact-Roll page that's a local aggregation of all the FOAF for that
person. Perhaps that's what you're talking about. But there's a
difference between the contact list for people on that site and the sum
of the contact lists from other sites. And quite the implementation
problem.