Probably the simplest way to think about Fluidinfo is by analogy to Wikipedia. Wikipedia is not a storage system in & of itself. It sits on top of some form of storage and provides an alternate interface to information for normal people. Its most distinguishing characteristics are 1) that anyone can add information to any page, and 2) that there is a page for everything (you get to create it if it doesn't already exist). Ten years ago if you'd said you were going to build an encyclopedia by letting anyone freely write on any page, it would have seemed, uh, optimistic (to say the least). What if you wanted to do the same thing for applications (and their users)? You could build something like Wikipedia, but there are 3 things you'd need that Wikipedia doesn't have: 1. A permission system on the information that was being added (on tags & their values, in Fluidinfo). That would stop applications from overwriting or even reading each other's data, unless they had permission. 2. Typed data. A number on a wiki page is just text. In Fluidinfo it's really a number. 3. A query language. If you add those things to Wikipedia, you basically have Fluidinfo. Fluidinfo gives you an object for everything (it has an 'about' tag, whose values are unique across the system), each with its own URL. Because the objects are not owned, anyone or any app can add to any object. No need to stop to ask permission, no need to be anticipated, no need for the structure of your data to be anticipated. So in a trivial sense Fluidinfo is just a database, but that's like calling Wikipedia just a database. The value that both Wikipedia and Fluidinfo get at is simple: information becomes more useful and therefore valuable when it's stored in context. Search engines illustrate the same principle: pulling together related but independent information (in HTML) into the same place and making it searchable. In the digital world, most things are read-only or you can only add data when you've been given permission and when the underlying storage structure permits it. As a result, it's very common that when apps have new data (or metadata) about something (like a Twitter user, a URL, an email address, a zipcode, whatever), they have to put it somewhere else. This often means your own server, your own API, your own docs, etc. Instead of doing the natural thing of putting the new information with the old (making it searchable with the old and with future data), you've just made a new hoop for future programmers to jump through. And so it goes, independent but related information that could valuably be living together winds up spread all over the place and less valuable. I hope that helps. Please feel free to send me a mail (terry fluidinfo com) or drop by #fluidinfo on irc.freenode.net

Wikipedia is built on a database. It provides an alternate interface to information, allowing anyone to contribute. Ten years ago that sounded pretty ridiculous, I think to just about everyone. What if you had the same thing, but for applications and their data (or metadata, if you like). Is that also ridiculous? The idea of openly writable storage (with a permissions system, typed data, and a query language - as in Fluidinfo) isn't as bad as you're making out. Re vaporware - actually not. I've spent about 6 years of my life building and re-building versions of Fluidinfo, starting in 1998. I used to have an apartment, but I sold it and put all the money into starting the company. It hasn't been easy. You can go create an account if you like, at https://fluidinfo.com/accounts/new/ Feel free to drop by #fluidinfo on irc.freenode.net if you want to chat. Terry

LOL! I wish :-)

There are some pretty big differences from Freebase. All their data was readable. There were no perms and therefore no way to build apps with private or shared data. Freebase was also very heavily into ontology (which I guess is what you're getting at with your reference to semantics), whereas Fluidinfo is heavily into evolution (of representation, convention, reputation & trust). There's actually quite a bit of data in Fluidinfo, but we've not done a good job of making that obvious yet. Hop onto #fluidinfo on irc.freenode.net if you'd like to hear more in real time. Or comment further, etc. Thanks!

Hi. You might want to try that again (btw, what was the query?). You have to keep in mind that we just got slashdotted :-) Sorry!

Yes, that's a good example use case. Then just apply the same thinking to anything (URLs, stocks, email addresses, names, zip codes, etc), and include the possibility that normal people (via apps) might want to store their data onto the same objects - I own it, I want it, here's my rating, whatever.

Hi. Love the memoization comment :-) I don't know how technical you want it, but there are some slide decks on http://www.slideshare.net/fluidinfo/presentations and some more technical ones in http://www.slideshare.net/terrycojones/presentations (back when we were still calling it FluidDB). If you have specific questions I'll try to answer them. Fluidinfo doesn't provide the actual storage layer (we build on a variety of things), it's more that it's an alternate interface to information - a bit like Wikipedia was an alternative way for people to store information: one in which you didn't have to ask permission to contribute, your additions didn't have to be anticipated, and where there was a single logical place for any thing (i.e., a URL in the case of Wikipedia). Fluidinfo does the same, but for apps. Plus you get a perms system on tags, typed data (of any type), and a query language. The main change is to objects without owners, which allows related information to collect in the same logical place (Fluidinfo has a unique 'about' tag, which is like Wikipedia's URLs) because information in context is more valuable than identical information that's isolated elsewhere. It can be searched across, for example. Does that help?

It's any data - yours or anyone who cares to add it. You can add tags to objects, and the tag values can be null, Boolean, numbers, strings, sets of strings. But they can also be anything you like: PDF, binaries, audio, etc., each with a MIME type (and you can make up your own MIME type if you like). So you can store HTML, CSS, JS tags onto objects in Fluidinfo and get at them through your browser. Or anything else you like.

In a way, but it's much simpler than the semantic web stuff. It's more like post-it notes - walk up to anything and put a note containing anything onto any object you like. I don't think it should be a requirement that you have a PhD in CS to understand a data model (and in the case of the semantic web with its jungle of acronyms that's sometimes not enough). Fluidinfo has an object for everything, in a very simple way, and those things don't have to be URLs - they can be email addresses, zipcodes, DNA sequences, dates, names, whatever. You get to add any tag to any object you like, you have a permissions system for your tags, and a query language to find things. It's pretty simple. The most important aspect is that the objects don't have an owner - the tags do. It turns out that an openly writable object system like this changes some interesting things - though it takes a while to "get" it. One high level one that people often don't appreciate is that (digitally) we are frequently forced to put new information about something somewhere else - because we were not anticipated, because we don't have permission, etc.

The problem with your model of "I expect the same info to simply be published by data owners. Or, simply extracted by an app for us running in a Google data center." is that many people (and apps) don't have a place to put things. And if they do, they put it all separately and it's less valuable (you can't search across it easily). The problem with having Google extract the metadata (as with microformats) is that then only the owners can add to it. Fluidinfo lets you put your data alongside other related info (just as in a wiki, though with good permissions), without asking for permission.

Hi. I know, it's easy to be a cynic - I'm great at it :-) I'm happy to help you understand if you like. There is a perms system on tags, so you don't have to collaborate with others over the data you add to objects. Your tags are in your namespace, like lordgrey/rating and you control them. And sure, it's a database (in fact it used to be called FluidDB). It's also a Turing Machine :-) The main point it that normally when people or apps have information about something (a URL, an email address, a zipcode, a name, whatever) they are forced to store it somewhere else - by which I mean you normally can't just add your own information to the digital objects you bump into. That's because you weren't anticipated, the data structure doesn't support you, you don't have permission, etc. So you (and your apps) end up putting your data elsewhere - in another database, behind another API, etc. - and that information is then less valuable than it could be. Fluidinfo is like wikipedia for data - anyone, or any app, can contribute data about anything - no questions asked, don't stop to ask permission. The incremental information (metadata, if you like) becomes more valuable because it is stored in context and can be queried with other related but independent information on the same object. Humans work like that all the time in the real world, but it's usually impossible in the digital world.

There are a few browsers for Fluidinfo data beginning to pop up. The most accessible is at http://explorer.fluidinfo.com/ which lets you do almost anything (make objects, add tags and values, query, change tag perms, etc) but its interface isn't crystal clear. You can also get at the data using http://shell-fish.appspot.com/ which is a browser based shell for interacting with Fluidinfo (type help). You can get visualizations of Fluidinfo objects at http://abouttag.appspot.com/ You can search Fluidinfo about tags at http://abouttag.appspot.com/search There are several other tools, but those are the main ones I'd suggest looking at to start with.

Hi sakdoctor Sorry, you're right that it's hard to figure out what Fluidinfo is - and it's hard to make a website that is understandable to a wide range of people too. One summary is to say that Fluidinfo is like Wikipedia, but for applications and their data rather than for humans. Like Wikipedia has a page (URL) for everything, Fluidinfo has an object for everything - lazily created, of course. The differences from a wiki that you need to make a Wikipedia for data are: 1) a permissions system so apps can't overwrite each other's data, 2) typed data, and 3) a query language. Fluidinfo provides those. Does that help at all? Terry