> I had always looked at their request for my Gmail password and quickly > moved on - the idea that I might reveal my Gmail password to any other > organisation is absurd. Thank you for prodding me to read further down > the page.
> It does seem as if this might work. No time to fight with it now, but > FaceBook tells me that I have some kind of problem to do with field > names.
> The field name mapping problem has also caused difficulties with my > attempts to sync my address file with Outlook and the application on > my "smart phone". I have never yet found an address book application > that has the field names I want or will allow me to add the ones I > need. Or has different rules regarding field length or character set > used. Any attempts to allow transfer of data between applications must > deal with these issues. For example, US addresses have a very set > format and require very few fields. UK addresses can be up to 6 (yes > that is six) lines long and so most US based contacts software can't > cope.
> Lysander
> On Sep 25, 2:48 am, Julian Bond <julian_b...@voidstar.com> wrote:
> > >I join my vote in favour of CSV import/export. I keep all my data in > > >an Excel file (easily allows insertion of extra columns - eg who did I > > >send holiday cards to in 2006) and would dearly love to import a > > >selected section of it into FaceBook. Gmail does not hold my address > > >book.
> > This is pretty common since it's the only easy way to get data out of > > Outlook and into the YASN. Note also that LinkedIn has CSV export.
> > I don't use Gmail for mail. but I've taken the decision to use GMail as > > my Contact Aggregator. I load everything I can into that. It then makes > > it easy to find the same people on a new YASN because they almost all > > now support GMail import.
Another perspective.. What's the motivation for importing and exporting stuff? Why couldn't all services just use an existing social network and decorate it with their own stuff? The source would of course be OpenID+XFN&FoaF. The services wouldn't need to track changes in the social network as there would be only a single, distributed source for it; the services would fetch the graph on the fly and cache appropriately. Not a big deal. Naturally, all the services (the social network*s*) would stay up-to-date and I didn't need to invite my friends to all the different networks separately. And when I logged into a new service, it would already know my social surroundings. I can't imagine a better user experience.
Please, quit making redundant copies of the same stuff. :)
Janne Savukoski <ster...@gmail.com> Fri, 28 Sep 2007 14:55:15
>Another perspective.. What's the motivation for importing and >exporting stuff? Why couldn't all services just use an existing social >network and decorate it with their own stuff? The source would of >course be OpenID+XFN&FoaF. The services wouldn't need to track changes >in the social network as there would be only a single, distributed >source for it; the services would fetch the graph on the fly and cache >appropriately. Not a big deal. Naturally, all the services (the social >network*s*) would stay up-to-date and I didn't need to invite my >friends to all the different networks separately. And when I logged >into a new service, it would already know my social surroundings. I >can't imagine a better user experience.
>Please, quit making redundant copies of the same stuff. :)
A fine sentiment. As a social network developer, I'm stuck with the need to hold local copies or a local cache of quite substantial account records. These records contain both common data about the user and data that is unique to my system. There are lots and lots of functions that simply would not be possible without having the data in a local database.
So now rather than querying a common store on the fly, I have to think about synchronising my local store with some common store. Which is where we came in with Brad's white paper.
So where do you think this common source would be and who would run it? There's a number of options here. - Google (or similar) scrape all the XFN, FOAF and whatever machine readable data on the web into one huge store with an API. Yes, please. - Plaxo (or similar) encourage people to lodge their data and network with them. They then provide an API. This is already starting. If there's a real need then services like this will appear. - Wordpress (or similar) build modules that allow people to create and maintain their own store with a common standard that everyone else can work to. At this point see OpenID AX, oAuth, SNAP and any other people here building standards.
-- 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 *** Just Say No To DRM ***
> Janne Savukoski <ster...@gmail.com> Fri, 28 Sep 2007 14:55:15
> >Another perspective.. What's the motivation for importing and > >exporting stuff? Why couldn't all services just use an existing social > >network and decorate it with their own stuff? The source would of > >course be OpenID+XFN&FoaF. The services wouldn't need to track changes > >in the social network as there would be only a single, distributed > >source for it; the services would fetch the graph on the fly and cache > >appropriately. Not a big deal. Naturally, all the services (the social > >network*s*) would stay up-to-date and I didn't need to invite my > >friends to all the different networks separately. And when I logged > >into a new service, it would already know my social surroundings. I > >can't imagine a better user experience.
> >Please, quit making redundant copies of the same stuff. :)
> A fine sentiment. As a social network developer, I'm stuck with the need > to hold local copies or a local cache of quite substantial account > records. These records contain both common data about the user and data > that is unique to my system. There are lots and lots of functions that > simply would not be possible without having the data in a local > database.
> So now rather than querying a common store on the fly, I have to think > about synchronising my local store with some common store. Which is > where we came in with Brad's white paper.
> So where do you think this common source would be and who would run it? > There's a number of options here. > - Google (or similar) scrape all the XFN, FOAF and whatever machine > readable data on the web into one huge store with an API. Yes, please. > - Plaxo (or similar) encourage people to lodge their data and network > with them. They then provide an API. This is already starting. If > there's a real need then services like this will appear. > - Wordpress (or similar) build modules that allow people to create and > maintain their own store with a common standard that everyone else can > work to. At this point see OpenID AX, oAuth, SNAP and any other people > here building standards.
It goes a little time consuming to describe this further, but I'll give some pointers.
The social network should be distributed, just like OpenID. (It's pretty fundamental for Internet-based systems that there are no single sources.) For example, I could have links to different parts of my social network at my openid-url http://janne.savukoski.name/. (Although, there's no need to have this kind of a 'starting point', either; there are also several services that let you compose that list very easily.) That resource (at the url) should then contain links to all my other openid/xfn-supported accounts as 'xfn:me'-links. (Something like "<a href='http://jsav.livejournal.com/' rel='me' />".) Each of those services (livejournal there) would then publish their part of my social network as further xfn-links (friend, contact) pointing to the openid-urls of my friends and such. Very simple, and robust. Much overlap, but everyone would still retain full control over their own network.
The publishing part here is of course already being implemented (apparently that's what the original thread was about, 'Six Apart is Opening the Social Graph'), but there's probably no service yet that can use this distributed social graph as their primary network information source.
> So now rather than querying a common store on the fly, I have to think > about synchronising my local store with some common store.
I'd suggest you to try design a system that would "loosely bind" your decorations over the "common network" (as opposed to a common service) so that your own system would then reflect changes in the cloud; if a connection is removed somewhere else in the cloud, so would your system remove data related to that connection. The less all this would require effort from the user, the better.
Btw., one potentially important component of this could be a semantic web search engine, which you could query about the relationships. Such a service would save the trouble for each service constantly traversing the semantic networks. http://pingthesemanticweb.com/ was introduced as such, but currently it seems to be reduced to something much less.
|
