Posted
by
CmdrTaco
on Monday August 15, 2011 @12:16PM
from the all-your-base-are-belong-to-us dept.

Slags writes "The idea behind Fluidinfo is that read-only information is just not as useful on the Web as openly writable information. Metadata is used routinely in the real world from name tags to post-it notes but it is much harder to apply metadata to information on the Internet. That is where Fluidinfo comes along. When information needs to be stored about an object the Fluidinfo database is queried. If the object exists in Fluidinfo, the information is appended to the object. If the object does not exist then it will be created and stored."

You have to sign up for API access. It looks liek this is early stages, plus they want to create an architecture for devs to build on, less than a site for browsing. So hopefully we'll see apps using their API soon. I'm going to play with it.

There are a few browsers for Fluidinfo data beginning to pop up. The most accessible is at http://explorer.fluidinfo.com/ [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/ [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/ [appspot.com]
You can search Fluidinfo ab

The first thing I notice: It's incredibly slow. To be of practical use, it must speed up at least by the factor 100 (probably more; I've still no result for my first query, and that was one of the example queries shown by the help command!).

The first thing I notice: It's incredibly slow. To be of practical use, it must speed up at least by the factor 100 (probably more; I've still no result for my first query, and that was one of the example queries shown by the help command!).

Fluidinfo is a database of metadata. But since metadata is really just data, Fluidinfo is really a database of data. Which is to say, it's a database. But there's a twist. You can make new "objects" at will. Kind of like most other databases, actually. But with even more of a twist, anyone can do that! Like what happens when you forget to secure your firewall. Then the excitement starts: You can add arbitrary key/value data -- metadata! -- to the object! Like a JOIN with another SQL table but with different semantics. But since the actual usage of the key/value pairs is not governed, you will have to collaborate with other users and applications through some external channel. The shared keys could be coordinated in an external database, for example.

Sarcasm aside, I'm sure this project is really cool and stuff, but the cynic in me thinks otherwise.

My 15s appraisal:They want to be the single-source OO database for 'everything'. Take all the data in wiki or any webpage ( assuming it's about an entity), extract any quantitative properties, ( Size, color, temperature, weight, Atomic Number... etc) and add them to Fluidinfo. Incorporate a way for domain names

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 seq

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 i

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 #flui

Sarcasm aside, I'm sure this project is really cool and stuff, but the cynic in me thinks otherwise.

Same here. Why do I get the feeling that my name, address, and birth-date will be stored in this DB and all spammers will have easy and immediate access to it? More importantly, what's to keep them from doing that?

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

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.

from the blurb it actually sounds like it's another spin on so called "context web" or "flock".

looking at the site, it seems it's that idea expanded to random strings that can have a random number of strings as attributes which can.. and then calling those object.

tags mentioned, of course. there's also some api, which I guess is the main entree here, actually. but I still fail to see the advantage and practicality and freshness of this... an article which would have done some performance testing etc etc on

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 c

The Cat: [to Rimmer] What *is* it?Rimmer: It's a rent in the space-time continuum.The Cat: [to Lister] What *is* it?Lister: The stasis room freezes time, you know, makes time stand still. So whenever you have a leak, it must preserve whatever it's leaked into, and it's leaked into this room.The Cat: [to Rimmer] What *is* it?Rimmer: It's singularity, a point in the Universe where the normal laws of space and time don't apply.The Cat: [to Lister] What *is* it?Lister: It's a hole back into the past.The Cat: Oh

Welcome to fluidinfo. This is fluidinfo. Welcome. You can do anything at fluidinfo. Anything at all. The only limit is yourself. This is fluidinfo, welcome. The infinite is possible at fluidinfo. The unattainable is unknown at fluidinfo. This is fluidinfo. Welcome to fluidinfo.
The OP reminded me of zombo.com. Where anything is possible.

If I understand what they want to do, I think it's a failure. They make a big deal about metadata being context dependent and, as such, it should stored in the context in which it is meaningful rather than in a single place. But, if I understand what they do correctly, their service is basical

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 [slideshare.net] and some more technical ones in http://www.slideshare.net/terrycojones/presentations [slideshare.net] (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 Wiki

Duh. Build up a huge hierarchy of preferred "editors" of the database and have them camp out the bits of metadata that they wrote. Then when it gets successful have those same people start marking en masse lots of the metadata to be deleted because it's not notable.

Well if you're creating a db of measurements or values, like dimensions of various objects, or automobile specifications, there's much less bickering to be done. If the nature of the DB isn't open ended && subjective, you avoid lots of landmines.

If the nature of the DB isn't open ended && subjective, you avoid lots of landmines.

You can also avoid the landmines if you have a mechanism for attributing content to specific users as Fluidinfo does via namespaces. There can only be one Wikipedia page for Transformers 3, so there might be a lot of contention about whether the article was fair/neutral, but in Fluidinfo you, RottenTomatoes, IMDB, and anyone else can place a rating or review tag on the object about Transformers 3, without any conflicts.

Over at C2.com, the very first web wiki, we have kicked around various ideas for things that are kind of catch-all dumping grounds for semi-structured info: part wiki, database, file-system, note-pad, content manager, and CRUD-stack. It wouldn't necessarily do any of these well (up front at least), but integrate various aspects of them all.

It could be useful for projects where you are not sure what you want yet and want to grow in an organic way.

It's similar to Freebase *but* rather than curating the organisation of data (as Freebase does) Fluidinfo is, er, "fluid" in that it expects conventions in tagging and organising data to emerge. Evolutionary pressure will make the best / most appropriate "schema" to survive (become conventions) in much the same way that hashtags is a bottom-up convention that emerged in Twitter.

No idea. The biggest thing I used it for was pulling data on video game and game console release dates for a demo website. That was more due to the amount of data and convenience than anything else and pretty simple.

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

"The justification is simple. We're removing the Firefox version numberfrom all of the common user-visible locations because we don't believethat users need to know what version they're on. We're moving to a modelthat's more like the Web. What version of Gmail are you on?

We've removed it from all of our marketing materials. We're removing itfrom the download button on the Website. We're removing it from how wetalk to users about Firefox. We're ending version numbers becausethey're

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 an

You're exaggerating wildly re "respond to EACH and EVERY post" and "respond to absolutely everyone individually". Have you counted?
You're of course right that people are saying WTF, and with good reason. Fluidinfo is a bit abstract and our web site sucks. People are asking questions here and I'm trying to help. It's not about control, it's about trying to answer the questions of people who are trying to understand. If people were asking questions about a project you were involved in, what would you do? Y