Fluidinfo

TunkRank is an influence measure for Twitter users. It was originally proposed by Daniel Tunkelang, and an online implementation was written and is maintained at tunkrank.com by Jason Adams. Given a Twitter user name, TunkRank computes a measure of that user’s influence based on followers of the user, how many people the user’s followers follow, etc. As well as a web interface, TunkRank scores can be obtained through their HTTP API.

Today we’re excited to announce that TunkRank scores can now also be accessed through Fluidinfo. This gives us a great way to concretely illustrate some of the unique properties of Fluidinfo. I’m going to give some examples that use Tickery, so you might want to go play with that a little first, or read our earlier postings, Meet Tickery and Tickery, for programmers.

1. But wait, TunkRank already has an API
   That’s true, but why stop at one? The TunkRank API provides TunkRank scores in isolation. So a 3rd party application can fetch a score and use it in some way. By also putting TunkRank scores into Fluidinfo though, they become searchable and can be combined with other data in Fluidinfo. For example, here’s a Tickery query showing people I follow who have a TunkRank of over 30. Look at the Fluidinfo query: has twitter.com/friends/terrycojones and tunkrank.com/score > 30. In English: "Hey Fluidinfo, get me all objects that have a twitter.com/friends/terrycojones tag on them and that also have a TunkRank score greater than 30." That’s pretty interesting: a data mashup of Twitter friend information with TunkRank scores. You can’t (easily) do that when the two sources of data are held in isolation, each behind their own API, but it’s trivial if the information is in the same place.
2. TunkRank’s domain name is on their data in Fluidinfo
   In the query above, the tag name for the TunkRank score is tunkrank.com/score. The tunkrank.com domain is part of the name of the data. With that name comes reputation and trust: if you see a tunkrank.com/score on a Fluidinfo object, you know it came from TunkRank. Want to put your domain name on individual pieces of data? Send us an email and if you can show us you own the domain, we’ll give you the Fluidinfo namespace with that name.
3. TunkRank continue to control their own data
   The permissions system of Fluidinfo allows TunkRank to control their own data. If Jason Adams wants, he can take permission away from Tickery to read the TunkRank scores. Because Fluidinfo’s permission system works at the level of the tag, not at the level of the Fluidinfo object, you get fine-grained control over the pieces of information that comprise objects.
4. Tickery was conceived independently of the idea of TunkRank scores
   Tickery doesn’t know anything about TunkRank. It happens to have an advanced tab that allows arbitrary Fluidinfo queries because that’s part of why we built it – to illustrate how other data added to Fluidinfo objects could easily be queried. Think about it – here we have two applications that were built independently of one another able to enhance each other because their information is in the same place.
5. TunkRank did not ask for permission to add their scores
   Because Fluidinfo objects do not have owners, there was no need for TunkRank to ask for permission to put their scores onto the same Fluidinfo objects that Tickery is using. They just did it. You can too, all you need is a Fluidinfo user name (you can get one here) and then send mail to api@fluidinfo.com requesting an API password. (Fluidinfo is still in private alpha.)
6. TunkRank and Tickery can move at different speeds
   As described in the Tickery for programmers posting, Tickery is using the Fluidinfo about tag, putting its information onto objects with a fluiddb/about whose values have the form twitter.com:uid:XXXX, where XXXX is a numeric Twitter user id. In Fluidinfo, anyone can create an object that’s "about" something. The upshot of that is that TunkRank does not have to wait until Tickery adds a user, it can just go ahead and put a tunkrank.com/score onto an object with the appropriate about tag – no questions asked. TunkRank doesn’t care or need to know if the object already existed, or whether Tickery had already put its tags there. Think about this too: here we have two (or more!) applications that are following the same convention, putting their own data into the same database, and each can move at its own speed without regard for the other. There’s no coordination beyond the about tag convention, when new data shows up from an application, it naturally goes to the place it belongs.
7. Anyone can play – that’s the point
   Other tags can be added to the same Fluidinfo objects, and can be queried on using the Fluidinfo query language in Tickery’s advanced tab (or by using the Fluidinfo API directly). To illustrate, Esteve Fernández and I put esteve/met and terrycojones/met tags onto objects to indicate people we’ve physically met. That data can be instantly (and interestingly!) mashed up with other data. For example, here are the people Esteve is following that he has not met, but who I have met, via the query (has twitter.com/friends/esteve and has terrycojones/met) except has esteve/met. And to show Twitter friends info, TunkRank scores, and our met tags in a single query, here are the people I follow who have a high TunkRank but who I’ve not actually met.

If you’ve read all the way down to here, thanks.

If you were having trouble grasping the point of Fluidinfo before, I hope these concrete examples have helped (if not, please let us know in the comments). Considering just Twitter, TunkRank, and Tickery as three related web applications, it’s clear that when their data is in the same place – via something like a Wikipedia for data – that it becomes more valuable.

But Fluidinfo is not about Twitter – the above is just an example of three applications (four, if you count the informal esteve/met and terrycojones/met tags) that are related and which all benefit from having their data co-located. People (and applications) can do more with it – they can search it more easily, they can add to it, they can do things that the original application designers did not and could not have anticipated. This applies to any data anyone cares to add to Fluidinfo.

Finally, Fluidinfo does not have the disconcerting (to some) free-wheeling anarchy property of a wiki. While preserving the essential character of wikis: it is always writable and it has an object for everything, it has three important things that a wiki does not have and which make it suitable for use by applications: 1) a strong permissions system (e.g., only TunkRank can add tunkrank.com/score tags to objects, unless they allow others to too), 2) a query language, and 3) typed data.