Wikifying Fluidinfo¶
One of the descriptions people have been known to use for Fluidinfo is
The database with the heart of a wiki.
I have hated that description from the first time I heard it. For me, the defining, central idea of a wiki is that it offers a single version of the truth that anyone can change. Fluidinfo isn’t like that: anyone can write to it, but each user writes in her own, private space; Fluidinfo offers as many versions of the truth as there are users. There are no edit wars in Fluidinfo.
Sometimes, this is brilliant. Rhiannon sticks her opinion in rhiannon/opinion and I stick mine in njr/opinion. For information that is personal—whether because it represents an opinion, or something to do with the user, or something of interest only to one person and a few friends—storing information in namespaces is perfect. On top of that, the permissions system adds a powerful layer of flexibility.
Where it feels unnatural is when we are recording facts. For example, I published the periodic table to Fluidinfo under the miro namespace (Miró being the data analysis software produced by my company, Stochastic Solutions; probably the only analytics software in the world with native integration to Fluidinfo at this time). So now, if you go to the object with about tag element:Hydrogen (id 270a8269-f02d-4925-b152-da3934edaa43) you will find lots of useful data about Hydrogen. (It was all culled from about seven different pages of not-very-structured data in Wikipedia, that would be nightmare for a machine to use.)
It looks like this;
and like this:
fdb tags -F -a 'element:Hydrogen'
Object with about="element:Hydrogen":
/objects/270a8269-f02d-4925-b152-da3934edaa43
fluiddb/about = "element:Hydrogen"
njr/index/class = "element"
miro/elements/Etymology = "Greek hydrogenes"
miro/elements/Period = 1
miro/elements/Group = 1
miro/elements/AtomicWeight = 1.007947
miro/elements/RelativeAtomicMass = 1.007947
miro/class = "record"
miro/elements/MeltingPointC = -258.975
miro/elements/Description = "gas"
miro/elements/Symbol = "H"
miro/elements/BoilingPointF = -423.17
miro/elements/BoilingPointC = -252.87
miro/elements/db-record-number = 1
miro/elements/ChemicalSeries = "Nonmetal"
miro/elements/Name = "Hydrogen"
miro/elements/Z = 1
miro/elements/Colour = "colorless"
miro/elements/db-next-record-about = "element:Helium"
njr/rating = 10
njr/index/about
miro/elements/MeltingPointKelvin = 14.2
miro/elements/Density = 8.988e-05
But that’s crazy. Hydrogen has atomic number 1; its symbol is H; its relative atomic mass really is somewhere near 1.007947. These simple facts have nothing to with Miró, or njr. In fact, if they turn out to be wrong, matters are even worse, because no one except Miró can change them.
For all Fluidinfo’s elegance and power, it encourages information to be ghettoized and personalized even when people are really wanting just to add uncontentious, factual data. In doing so, it makes it hard for others to correct, extend and improve it, and harder for it to be found and used. It’s natural that if you want to know how I rate something, you would look at a tag called njr/rating; but how could you know that you need to look under a user called miro to find information about Hydrogen? It’s a problem.
What if Fluidinfo Were Actually More Like a Wiki?¶
Fluidinfo comes with a fairly powerful permissions system that allows detailed control over who can read and write each tag and namespace. A tag can be set so that only its owner can write to it, or so that everyone can, or so that only a named set of users can write to it.
This means that Fluidinfo already has a core piece of infrastructure for enabling some wiki-like functionality. At the simplest level, we could have a user whose top-level namespace gave write permission to everyone, and we could augment this with a policy that made that apply recursively to all sub-namespaces and tags under it. Perhaps we would call that user wiki. (I could actually create such a user; or you could; Terrell probably won’t.)
The suggestion would then be that anyone who wanted to publish factual information to Fluidinfo consider defaulting to writing it under the wiki namespace. Instead of
Is that enough?¶
I confess that if anyone had described Wikipedia to me before it existed, I would have been a naysayer; I would simply never have believed that its anarchical processes could possibly have produced anything of value. Clearly I was wrong; in practice, there is a vast amount of useful information in there, and the level of accuracy of information in Wikipedia is remarkably high.
Wikipedia deals with vandalism largely through the work of humans undoing vandalising changes, often with breathtaking speed. Fluidinfo does not, today, have a mechanism for tracking and reverting changes, though it would clearly be possible to create such a mechanism. (I’m not even sure what transaction records Fluidinfo keeps today, but the great thing about software is that if it doesn’t keep enough today, it could be changed so that it did tomorrow.)
Even today, Fluidinfo’s permissions system does offer some powerful controls. We could allow everyone write access to the whole of the wiki namespace by default, but remove abusers. Or we could be more restrictive. We could have groups controlling different tags or namespaces under wiki. We could allow people in cautiously, perhaps requiring endorsement first. There are many possibilities. In the absence of an easy way to revert vandalising changes, we might need to lean towards being more restrictive early on; if reversion capabilities were added to Fluidinfo, together with detailed tracking of which user makes which changes, we might be able to become more liberal.
We could also have loose restrictions when we are trying to build up information in some domain, and potentially tighten them later. (After all, the periodic table is fairly stable, as are the planets, even if Pluto’s not a planet any more.)
Is this a Good Idea?¶
I don’t know.
I think there is a clear need for Fluidinfo to have some mechanism for detaching non-personal information from a (personal) user; for making reference information available in a more predictable, uniform, cooperatively gathered way. This can happen to some extent through individual initiatives, but something like the idea of a wiki user seems like a possible improvement.
On the other hand, this may just be a recipe for edit wars.
Overall, it seems to me that Wikipedia, and other similar collaborative projects, stand as a kind of existence proof that wiki-like mechanisms can work. So on balance, at the moment, I think there might be some benefit in trying something like the idea of a wiki user.