Image: Jin Wicked
I’ll have to explain what I mean by that, especially seeing as some people got the impression from the earlier post on data vs metadata that we don’t think metadata is important, or that it doesn’t exist, or similar. I tried to make it clear in the post, and in responding to the comments that followed, that that’s not what was meant: In fact that’s one of the major initial goals of Fluidinfo – to be a metadata engine for everything. So that’s how important we think metadata is! The way to support metadata on anything is to have an underlying architecture that’s flexible enough to allow that to happen – without someone setting the thing up with an a priori determination of what’s meta- and what’s not. True support for metadata is too important for that – to do it properly you need the architecture to be neutral.
The question is: how can Fluidinfo be used as a universal metadata engine?
Metadata can be loosely defined as data that’s about other data. So to provide a universal metadata engine, any time any application wants to store some metadata (M) about anything (A), Fluidinfo should always have a place to put M. Moreover, the application shouldn’t have to stop to ask if it’s ok to store the metadata, and its needs shouldn’t have to be anticipated.
The key word in the above paragraph is about. Fluidinfo has an about tag that can (optionally) be added to objects to indicate what they’re about. There’s a lot that could be said about the about tag – in fact, the person who pushed for its inclusion in Fluidinfo, Nicholas Radcliffe even started a blog of that name. The main thing to know for now is that the about tag on an object (if any), is immutable and its value (always a string) is unique across all Fluidinfo objects.
To give some simple examples, there might be objects in Fluidinfo with about tags that have values such as isbn:140679239X or http://www.abebooks.com/servlet/BookDetailsPL?bi=588210745 or US:ZIP:90210 or info@fluidinfo.com or IP:207.171.166.252 or….. anything you like. That’s the point.
So when an application – any application – wants to store information about A, it just asks Fluidinfo for the object whose about tag has the value A. If the object already exists, Fluidinfo returns it. If not, Fluidinfo creates a new object, sets its about value to A, and returns it.
That’s the first part of being a universal metadata engine: if you want to store information about something, Fluidinfo gives you an obvious place to put that information (provided you can convert your particular A into a string of some kind). In this regard, Fluidinfo is like a wiki. When you use a wiki, you can ask it for the page on any subject, and if it doesn’t exist it will be created. As with a wiki, you can think of Fluidinfo as already having objects about everything; just like a wiki, Fluidinfo doesn’t actually create any particular object until someone asks for it.
The second crucial component is Fluidinfo’s model of control. As mentioned in the Information. Naturally. post, Fluidinfo objects do not have owners. That means that all applications are guaranteed that they can store information onto the Fluidinfo object about A.
Putting these two together, you get something that starts to look very much like a universal metadata engine. Got some metadata to store about something? Fluidinfo gives you an obvious place to put it and a guarantee, in advance, that you’ll be able to do so. This is what we mean when we say Fluidinfo makes the world more writable.
To give a couple of quick examples, Emanuel Carnevale has written two Javascript programs for the Firefox 3.5 Jetpack extension. These are just quick proofs of concept for now, but they will mature. One is fluidy-hood that offers functionality along the lines of Google’s Sidewiki (though more general), and the second is BRB, the Borthwick Remember Button, in honor of John Borthwick of Betaworks who asked for one. These are very simple pieces of code that use Fluidinfo as a universal metadata engine, in both cases putting information onto the object that’s about the URL you’re currently looking at in Firefox.
A final comment about the creation of value: These tiny apps have limited and unremarkable value to their individual users. Things get much more interesting though we you consider that these applications are creating truly social data. It is directly searchable via the Fluidinfo query language. It can be combined with other information—homogenous (created by the same app being run by someone else) and heterogenous (related but different information about the same thing created by other apps). It can be accessed, augmented, and mashed up by others. And the person who created the information can continue to control it: share it, protect it, edit it, delete it, etc.
When you look at data and applications like this, you begin to see why we’re so excited about the kinds of changes in how we work with information that we think Fluidinfo can help to introduce.
There’s a lot more that can be said regarding the about tag, about how all this affects customization, personalization, and information organization in general, about ambiguity and its resolution, and about the creation of value via putting information into context. Those things will have to wait for later blog postings, though.
Stay tuned.
[…] This post was mentioned on Twitter by Roman Stanek. Roman Stanek said: RT @terrycojones: Blogged: FluidDB as a universal metadata engine http://bit.ly/6igiR […]
Pingback by Tweets that mention FluidDB » Blog Archive » FluidDB as a universal metadata engine -- Topsy.com — October 3, 2009 @ 5:30 am
Be interesting to use FluidDB for metadata on URLs. e.g. geolocation data for a Tweet at http://twitter.com/paulmwatson/status/4679912501
Would one set the about tag as the URL?
Comment by paulmwatson — October 7, 2009 @ 5:41 am
Hi Paul. You certainly could set the about tag to hold the URL. That would be a natural place for others to go to to find metadata (if that's the word) about the tweet.
But you could also make an object with about = “52.35464,37.1817282” (a lat/long) and put information onto that object: the fact that you were there, the time, and a tag whose value was the URL of the tweet. A convention would perhaps need to spring up about the exact format of the about contents in this case. It's entirely at the discretion of the programmer/app. I'm not claiming that this approach is necessarily useful but I want to mention it to illustrate that there are various approaches and that you wouldn't have to pick just one.
Such an app might also choose to put some information onto the object in FluidDB that's about you.
I hope that helps. Thanks for commenting & feel free to ask more.
Comment by terrycojones — October 7, 2009 @ 5:56 am
Ah good point, it depends on how one sees the data being used. From a URL perspective or a location perspective. Which begs the question; would you create both objects, almost mirror images of each other. Seems like duplicate data though. But that touches on your post about the real world being filled with inconsistencies, often useful.
Comment by paulmwatson — October 7, 2009 @ 6:05 am
Yes, if I wanted both, I'd make both. In this case I don't think there's much concern with duplicated data – you're basically recording a fact, and it's (likely) not something you'll want to change (although you could). And yes, you're right, I also wouldn't worry about inconsistency or at least it seems to me to be here greatly outweighed by utility.
And a slight clarification: FluidDB doesn't care about inconsistencies – it can't. So at that level there's no help available 🙂 I don't advocate blanket inconsistency, ambiguity, etc., it just feels natural to build an information storage architecture that allows it, allows the evolution of convention (i.e., in a sense, the removal of inconsistency), etc.
Thanks!
Comment by terrycojones — October 7, 2009 @ 6:26 am
Be interesting to use FluidDB for metadata on URLs. e.g. geolocation data for a Tweet at http://twitter.com/paulmwatson/status/4679912501
Would one set the about tag as the URL?
Comment by paulmwatson — October 7, 2009 @ 11:41 am
Hi Paul. You certainly could set the about tag to hold the URL. That would be a natural place for others to go to to find metadata (if that's the word) about the tweet.
But you could also make an object with about = “52.35464,37.1817282” (a lat/long) and put information onto that object: the fact that you were there, the time, and a tag whose value was the URL of the tweet. A convention would perhaps need to spring up about the exact format of the about contents in this case. It's entirely at the discretion of the programmer/app. I'm not claiming that this approach is necessarily useful but I want to mention it to illustrate that there are various approaches and that you wouldn't have to pick just one.
Such an app might also choose to put some information onto the object in FluidDB that's about you.
I hope that helps. Thanks for commenting & feel free to ask more.
Comment by terrycojones — October 7, 2009 @ 11:56 am
Ah good point, it depends on how one sees the data being used. From a URL perspective or a location perspective. Which begs the question; would you create both objects, almost mirror images of each other. Seems like duplicate data though. But that touches on your post about the real world being filled with inconsistencies, often useful.
Comment by paulmwatson — October 7, 2009 @ 12:05 pm
Yes, if I wanted both, I'd make both. In this case I don't think there's much concern with duplicated data – you're basically recording a fact, and it's (likely) not something you'll want to change (although you could). And yes, you're right, I also wouldn't worry about inconsistency or at least it seems to me to be here greatly outweighed by utility.
And a slight clarification: FluidDB doesn't care about inconsistencies – it can't. So at that level there's no help available 🙂 I don't advocate blanket inconsistency, ambiguity, etc., it just feels natural to build an information storage architecture that allows it, allows the evolution of convention (i.e., in a sense, the removal of inconsistency), etc.
Thanks!
Comment by terrycojones — October 7, 2009 @ 12:26 pm
I'm beginning to like the pattern of permissionless annotation, and a range of use cases that extend far beyond the browser.
Speaking of browsers, my own open social reader research has lead me to a modified web browser which includes following people and topics in addition to urls (thinking of building on/branching chromium).
Comment by Mark Essel — April 26, 2010 @ 12:24 am
That sounds good – the later. I like chromium.
The combination of objects without owners and perms on the annotations (tags, attributes, what have you) takes a while to sink in – at least it did for me. It is the key to several key things about FluidDB, and at least IMO a couple of them are important. It took me about a year to really grasp that 🙂
Comment by terrycojones — April 26, 2010 @ 5:50 am
how do you handle possible ambiguities in describing the entities? If I want to attach a meta data to about = “52.35464,37.1817282” but express it as about = “52.3546,37.181728” (one decimal less), for example?
Does this lead to some sort of standards, with the implied loss of flexibility?
Comment by Adriano — February 25, 2011 @ 5:29 pm
Terry, sorry. You already mentioned the issue in your comment. I read too quickly.
Comment by Adriano — February 25, 2011 @ 5:54 pm