Slashdot Mirror
Fluidinfo, Wikipedia For Databases
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."
I didn't find a link where I can actually access any data (not even to read it).
The Tao of math: The numbers you can count are not the real numbers.
just like Wikipedia has a web page for everything
So they're taking a bold anti-deletionist position. Good for them.
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Fluidinfo is an online information storage and search platform.
So what is it?
Fluidinfo provides a universal metadata engine because it has an object for everything imaginable, just like Wikipedia has a web page for everything.
So what is it?
Fluidinfo makes it possible for data to be social. It allows almost unlimited information personalization by individual users and applications, and also between them.
So what is it?
Can anyone express what this does in technical terms? Everything I could find was sorta like liberal arts major expounds on the new (to the liberal arts establishment) idea of memoization.
http://en.wikipedia.org/wiki/Memoization
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
I've had some ideas for wiki-like databases for awhile now, if this were open people could create some really cool open information sets
A database that can both read and write.
The mind boggles.
It sounds like Freebase to me, which has been around for years.
A thought experiment how their service might be used to automatically confirm or reject friendship requests: http://blogs.fluidinfo.com/fluidinfo/2011/06/01/personalized-filtering-of-friend-requests-in-social-networks/
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 basically a single place to store all their clients' metadata. You store all your metadata at fluidinfo and it does neat thing.
The OmegaWiki project provides a multilingual database, is based on MediaWiki and was authored in large part by a Wikimedia staff-member. It's an interesting re-imagining of Wiktionary.
Wikipedia *is* a database. This is like proposing a search engine for "data"....oooh! Sounds amazing!
100% vaporware. But please don't tell the VC guys who got bamboozled. They're just figuring it out and hoping to pass the buck to a greater fool.
------ The best brain training is now totally free : )
What about a skateboard that doubles as an external keyboard? You could thrash around on it in the daytime and blog about it at night.
I read the title as "Wikipedia for Dumbasses" and thought "This will be fun! Ragging on Conservapedia and the morons who use it."
Reading the about and blog sections, sure sounds like the '11 version of the Semantic Web.
Quote from the discussion:
"The justification is simple. We're removing the Firefox version number
from all of the common user-visible locations because we don't believe
that users need to know what version they're on. We're moving to a model
that'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 it
from the download button on the Website. We're removing it from how we
talk to users about Firefox. We're ending version numbers because
they're not meaningful to users (except in troubleshooting situations.)
People using Firefox do need to have confidence that they're on the
latest version, though, and that's what this feature provides. Telling
the user explicitly that Firefox has checked and that she is indeed up
to date is a much better way of letting the user know that she's up to
date than giving her a number she can compare with some other number on
a website somewhere to figure out if she's on the latest version. "
I cannot subscribe to this reasoning. There are many, many reasons why an end-user will want to know the version of Firefox he's using. For instance if he wants to avoid a certain feature present in some builds but not in others. Example: the so-called "AwesomeBar" (more of an AwfulBar if you ask me) which I had to go to extra lengths to avoid. Not everyone likes every single bit of Firefox.
I hadn't known there were so many idiots in the world until I started using the Internet -Stanislaw Lem
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
This is simply a REST API for OnLine Object Model
They offer an online service to share one single object model betwen several web apps (much like the apps architecture for oberon_F/blackbox runtime but on the web) to build object models similar to the extensible object stores from the smalltalk world
On second tought... why bother? having seaside/pharo building a library to add the semantics (of the architectonic anotations) in oberon_F/blackbox for secure extensibility in a REST API gives you the same and its sturdier (that also all givesmany "ready made" storage backends)