Goodbye 'social-media' world

You may or may not have noticed, but recently a number of 'social media' services have begun looking and working very similarly. Facebook is the poster-child, followed by google+ and twitter. Their modus operandi is to entice you to interact with family-members, friends and acquaintances and then leverage your interactions to both sell your attention advertisers and entice other members of you social circle to join the service.

There are, naturally, a number of shiny baubles you get for participating it the sale of your eyeballs to the highest bidder, but recently I have come to the conclusion that my eyeballs (and those of my friends, loved ones and colleagues) are worth more.

I'll be signing off google plus, twitter and facebook shortly. I my return for particular events, particularly those with a critical mass the size of Jupiter, but I shall not be using them regularly. I remain serenely confident that all babies born in my extended circle are cute, I do not need to see their pictures.

I will continue using other social media as before (email, wikipedia, irc, skype, etc) as usual. My deepest apologies to those who joined at least party on my account.

Interlinking of collections: the quest continues

After an excellent talk today about LibraryThing by LibraryThing's Tim, I got enthused to see how LibraryThing stacks up against other libraries for having matches in it's authority control system for entities we (the NZETC) care about.
The answer is averagely.
For copies of printed books less than a hundred years old (or reprinted in the last hundred years), and their authors, LibraryThing seems to do every well. These are the books likely to be in active circulation in personal libraries, so it stands to reason that these would be well covered.
I tried half a dozen books from our Nineteenth-Century Novels Collection, and most were missing, Erewhon, of course, was well represented. LibraryThing doesn't have the "Treaty of Waitangi" (a set of manuscripts) but it does have "Facsimiles of the Treaty of Waitangi." It's not clear to me whether these would be merged under their cataloguing rules.
Coverage of non-core bibliographic entities was lacking. Places get a little odd. Sydney is "http://www.librarything.com/place/Sydney,%20New%20South%20Wales,%20Australia" but Wellington is "http://www.librarything.com/place/Wellington" and Anzac Cove appears to be is missing altogether. This doesn't seem like a sane authority control system for places, as far as I can see. People who are the subjects rather than the authors of books didn't come out so well. I couldn't find Abel Janszoon Tasman, Pōtatau Te Wherowhero or Charles Frederick Goldie, all of which are near and dear to our hearts.

Here is the spreadsheet of how different web-enabled systems map entities we care about.

Correction: It seems that the correct URL for Wellington is http://www.librarything.com/place/Wellington,%20New%20Zealand which brings sanity back.

fuzzziness

I've been using topic maps in my day job, so I decided to try out http://www.fuzzzy.com/, a social bookmark engine that uses an underlying topic map engine.
I tried to approach fuzzzy with an open mind, but the increasingly stumbling on really annoying (mis-)features.

1. This is the first bookmark engine I've ever used hat doesn't let users migrate their bookmarks with them. This is perhaps the biggest single feature fuzzzy could add to attract new users, since it seems that most people who're likely to use a bookmark engine have already played with another one long enough to have dozens or hundreds of bookmarks they'd like to bring with them. I know this is non-ideal from the point of view of the social bookmark engine they're migrating too, since it makes it hard to do things completely differently, but users have baggage.
2. While it'd possible to vote up or vote down just about everything (bookmarks, tags, bookmark-tags, users, etc), very little is actually done with these votes. If I've viewed a bookmark once and voted it down, why is it added to my "most used Bookmarks"? Surely if I've indicated I don't like it the bookmark should be hidden from me, not advertised to me.
3. For all the topic map goodness on the site, there is no obvious way to link from the fuzzzy topic map to other topic maps.
4. There doesn't seem to be much in the way of interfacing with other semantic web standards (i.e. RDF).
   
5. The help isn't. Admittedly this may be partly because many of the key participants have English as a second language.
6. There's a spam problem. But then everywhere has a spam problem.
7. It's not obvious that I can export my bookmarks out of fuzzzy in a form that any other bookmark engine understands.

These (mis-)features are a pity, because at NZETC we use topic maps for authority (in the librarianship sense), and it would be great to have a compatible third party that could be used for non-authoritative stuff and which would just work seamlessly.

OpenID - Everybody Wants To Go To Heaven, Nobody Wants To Die

I've been looking recently at OpenId a little more closely. It's a great system, that I've been using for a number of years.

My first free openid provider (http://stuartyeates.videntity.org/) went belly up for reasons I'm still not too sure about, but the life expectancy of internet startups and free services has never been that long. I have a new identity (http://stuartyeates.myopenid.com/) which does me just fine.

One thing I've been noticing is that while a host of the internet services that I use want to be my identity provider, very few of them want to let me login using an openid provided by another identity provider. From a business point of view I can completely understand this: they want to know everything about the user so they can (a) off better, more integrated services and (b) see more customised advertising. I have no problem with (a), but (b) is one of the reasons I'm eying up openid in the first place.

They don't understand that to get to openid heaven, they're going to have to die. By giving away the user-authentication-and-give-us-your-personal-information step, they can drive significantly more logins and significantly deeper interaction with their website and with their content. Sure, they can't necessarily get access to the users email address and whatever fake personal details they submitted at sign up, but I've yet to see this used particularly well anyway. The personal details certainly don't seem to be used to anywhere near the same effect as analysis of user behaviour.

What would be really good is an openid identity provider with (a) shared no information with any of the large advertising groups or dominant internet companies, (b) really clear information about privacy expectations (and I'm not talking here about a page of legalese titled "privacy policy," but discussion and disclosure of things which jurisdictions user data is stored in, steps taken to avoid collection of user data, etc) and (c) a clear sustainability model to prevent it being bought-out for the user data and to ensure it's continuity (I can imagine paying a subscription for it).

I can imagine that this is the kind of thing that google or yahoo might sponsor in their efforts to promote their next generation of web authentication standards. The existance of such an outfit would hugely boost the reputation of such a standard and lacking the huge advertising and existing lockin it would hardly challenge their own identity providers while answering a whole range of independence, privacy and monopoly questions.

Tinkering with ohloh

I've been tinkering with www.ohloh.net, which is probably best described as a web 2.0 freshmeat. Rather than tracking manually-updated releases it relies on automatically detected updates to version control repositories, RSS and geo-urls. It relies on wiki like editing rather than the strict ownership rules of freshmeat. ohloh does automatic language detection and source code analysis based on the version control repository and attributes individual commits to specific developers and their ohloh user account.

I've added and am actively curating a group of go/baduk projects. The overall goal is to encourage reuse and reduce the willingness of hackers to rewrite go/baduk systems from scratch.

My next step on the technical side is to write some GRDDL (Gleaning Resource Descriptions from Dialects of Languages) to transform the XML returned by the API into RDF, which I can them import into simal.

My next step on the social side is to mention what I'm doing in some of the go/baduk mailing lists, but I want to wait until I've got something concrete to provide that Sensei's Library (the current repository of information about go/baduk programs) hasn't already got.

RedHat's MugShot and lockin

I've been playing with MugShot, the RedHat's venture into the social networking sphere. I was initially impressed by the site, which has builds a dynamic (if HTML-only) website while asking for really very little information and not asking for any confidential information (i.e. no asking of gmail passwords to pester friends to join up). The website is slick and glossy, if a little heavy on my dialup connection.

The more I use MugShot, however, the more I see it supporting rather than undermining lockin in the social networking sphere.

1 Login with Gnome account or local username/password

While many of MugShot's Gnome account initial target audiance may have had Gnome accounts suitable for logging into to MugShot, I'm guessing that a really small proportion of people they knew did. Login using openid or similar would be great.

2 Supporting only a small number of services, and not flexibly

It's great that mugshot supports delicious. However, by only supporting a single service of this kind, not only are my magnolia bookmarks unsupported, but the current delicious control over the social bookmarking market is strengthened. I understand that the differences between the delicious and magnolia APIs are largely cosmetic, and find it hard to believe that much effort would have been required to support it. Similarly, there are a number of exciting competitors to youtube, amazon, facebook and other MugShot supported services which could be supported with very little time and effort on the part of MugShot.

The services that are added, use a one-size-fits all approach, when I know of no two long-term users of (for example) facebook who use it in the same way.

3 No machine-readable export

There is (that I can see) no constructive machine readable export of any kind from MugShot. Two basic RSS feeds (which aren't advertised in the GUI). No RDF/FOAF, no blogroll for integration into the next generation of social networking and web services. MugShot may see itself as the top of the social networking heap, but until that's evident to the rest of us, they need to play nicely with third parties, both below them and above them on the heap. Failing to export anything useful in a machine-readable format is not playing nicely.

4 No "deep connection" back to the data sources

Having configured MugShot, I can see lots of books, photos and links that those in my network find interesting. But even though Mugshot can tell the difference between books, photos and links when it's displaying them and knows about the accounts I have on services for bookmarking, favouriting or commenting on books, photos and links it doesn't offer functionality to bookmark, foavourite or comment on them. By not driving content and information back to the underlying datasources, MugShot undermines the underlying services and devalues them, in so doing it also (a) devalues the commitment and investment I've made to those systems and (b) reduces the likelihood that those services will go out of their way to help MugShot.

5 "Invitation to tinker" only covers look-and-feel

MugShot has a great system for creating skins for music players, and several hundred people appear to have accepted this invitation to tinker and made come great skins. Unfortunately only cosmetic changes are possible. What I would like to see is a generic feed subscription creator which let me add new services that MugShot could listen to. Just like the music player skins, only a very small proportion users would bother, and most of those who did would not produce anything to shout about, but with a feed subscription creator, each success would lead to a whole new service that Mugshot could access and channel to their users. Such a effort would completely alleviate issue problems with the small number of supported services.

MugShot has an invitation to tinker in the traditional open source web 1.0 sense, with a wiki and version control system, but it doesn't have an invitation to tinker in the web 2.0 sense in which users can scratch their itch (and make the project better) from within their browser in the way the yahoo pipes, for example, does.