« links for 2007-08-16 | Main | REST design notes »

Buddycrap

Moar grafz plz

Brad Fitzpatrick gets with the program:

"There are an increasing number of new "social applications" as well as traditional application which either require the "social graph" or that could provide better value to users by utilizing information in the social graph. What I mean by "social graph" is a the global mapping of everybody and how they're related, as Wikipedia describes and I talk about in more detail later. Unfortunately, there doesn't exist a single social graph (or even multiple which interoperate) that's comprehensive and decentralized. Rather, there exists hundreds of disperse social graphs, most of dubious quality and many of them walled gardens."

Dare Obasanjo says its much harder than that. Because "as they chase the utopia that is a unified social graph" there will be 3 problems:

  • Some Parts of the Graph are Private
  • Inadvertent Information Disclosure caused by Linking Nodes Across Social Networks
  • All "Friends" aren't Created Equal

Yes , yes and yes. But, so what, you say? Is that a good enough reason to keep this data siloed? It's convenient to ignore that MSFT almost certainly have lab and production results that back these issues up.

Let's call the problem of lossy context as you move your contact details around "buddycrap". It's sounds better than "distributed groupware", which we'll see in a minute is another way of looking at this. Dealing with buddycrap fundamentally requires provenance - from where and in what context did this buddy come from?

Groupware Bad. Money Ok.

Saying things like "not all friends are created equal" leads you to want to introduce permissions control and visibility to online contacts - the "solution". It's a problem you see a lot in groupware - for example HR and your manager might be able to see things about you that your colleagues can't. It's tempting then to carry that logical form to online systems - my d00dz should be able to see things my dad can't. Dare's perceived issues are food and drink to enterprise IT consultants.

Since deployed groupware tends to be abominable, you'd think pointing at the social graph aggregation problem, saying "that's groupware" and linking to what Jamie Zawinski said about groupware would be a killer putdown. It might be.

Aggregation is also about money. Social graph aggregation and fluidity allows for better cross-selling. All those recommendation algorithms of the form "you like/bought x and y likes/bought x, you and y might have something in common" work better with larger data sets. Especially if you can jump verticals - such as connecting last.fm data to facebook. So it's gonna happen one way or another. I expect this is why Google is keen to figure this out and soon - they can win big if they can access and quantify over all that data; it's in their dna to do so.

On the balance I think I'd prefer targeted spam and online clubcards to a data silo anyday. So I'm leaning to the idea that access to this data should be uniform and fluid, even if I lose a lot of context. Which is to say, even though I accept Dare's issues, I'll take an 80% solution from Fitzpatrick. That said, I noted that "consumer analytics" didn't appear in Fitzpatrick's goals - or non-goals.

Once again, the semantic web has easily ignorable answers.

Danny picks up on this. True, the semantic web community have been talking about social graphs for years (I won';t be surprised that community is where the term "social graph" comes from). DOAP's been around forever it seems. Will this be another area that takes a pass on semweb technology like RDF?

As well as distributed data graphs, which frankly are semweb bread and butter, the semweb community also has most of what's needed to allow assertions of the form "only people in class x can see item y" that can travel across systems, assuming three things. First, that there are now working solutions for sourcing where a 'triple' (the smallest useful RDF fact) came from, something that was a semweb hot topic a few years back. Second, that you can make such assertions usable to consumers - consider that even domain experts that are paid to do so, get permission schemes terribly muddled. Third, you're actually crazy enough to want to bring groupware style permissions to Web.

Freedom 0. Think of the dwarves.

Here's what I said the last time Mark Pilgrim brought up Freedom 0 - "good luck trying to figure out who owns generated metadata, or anything that was mined. GPLv2 'linking' is straightforward by comparison."

Social graph data is exactly like that. A lot of it is computed; arguably you don't own it at all beyond your account details.

But, on reflection this social graph thing is only part of the picture - we should also be concerned about video game data. Because it's an important freedom to be able to let game characters and avatars switch worlds. A lot of people think video games are more important than social networks, and rightly so.

Forget interchange across social networks. What you want to be worrying about is why can't your WOW dwarf run amok in Vice City, once he adapted to urban life? Why can't Club Penguins roam free in the Second Life? Why can't Solid Snake merc it in Marioworld? Arbitrary restrictions like this are broken. Your game avatars are part of your online psyche, no? Game characters locked into a single game or world is clearly a looming crisis of personal freedoms. Universe jumping happens on TV shows and in comics all the time - this is what we *expect* to happen. That's because TV Shows and comics are to video games as the real world is to social networks.

Walled garden video game universes suck, and should be routed around. People are getting sick of registering and re-building characters on every game., but also: levelling up every time is too much work. Plus, it would be cool to have a network of network games - like the internet, but fun.

I'll have more to say on video games and freedom 0 in future posts.


August 19, 2007 01:45 PM

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/2137