In comments Dylan writes about having a visual RDF browser, …it would seem that a RDF Browser would be useful in traversing different distributed data as you follow connections and learn new information.. Danny Ayers also responded with:
If I have your Poet Vocabulary plugin for my browser, whenever I encounter material containing appropriate terms from that vocab those parts of the screen will go sepia-tinted and slightly out of focus.
I rather like that myself. Except not out of focus, let’s have the words pulse, as if they’re the beat of a heart of a new born bird. Or some such thing.
Sigh. How semantical.
They both do have a good point if you consider the visual tools that have been available for relational data models for years. I can’t remember the first tool I used, but the modeling technique was known as IDEF0, following an Air Force requirement.
In this technique, independent data objects were square cornered, but dependent objects were curved. Arrows were drawn to represent the relationships between the objects, and the key columns were highlighted above a solid line within the boxes. Categories had a circle above a couple of bars.
Models allowed us to look at the data and its relationships with each other, and helped us identify dependencies, as well as missing data. Typically, we would define the model to a particular normalized form, and then denormalize it for performance. In both cases, we’d create data models so that we could show a mapping for this conversion.
A key difference, though, between RDF and relational data, is that the meta-data to drive a data model is included with the data itself, so a model could actually be automatically generated from the same database that contained the data. RDF, on the other hand, doesn’t necessarily provide the meta information included within the same source as the data. The RDF namespace should have a defined schema, and this schema should provide this meta information – but there’s no guarantee this is accessible.
Still, as BrownSauce demonstrates, much about the model can be defined from what can be found, and if there’s enough to display nicely as HTML, there’s no reason that we can’t draw a bubble. Or a box, if we’re so inclined. But then that gets us back to my original question: would we want to?
One of the keys to understanding the RDF data is to have good text definitions to go with the objects so that we know what the data is all about. Unlike with our IDEF0 efforts, when we had a fairly good idea of the business context, an RDF/XML file (or other format if you’re a picky purist) is out there on the web, just hanging around and if you don’t know the context (i.e. “This is my FOAF file”), you need good definitions associated with the objects. A visual model won’t help with this, thought BrownSauce, with its text extrapolation is very helpful.
But there are those times when we start looking at merging data from the same or even dissimilar schemas, where a visualization could be a handy bugger. But it’s also much tricker than IDEF0. You see, a IDEF0 model has a basic functionality and purpose and the relationships between objects are very well known. The same can’t be said about any relationships between data discovered out on the web.
It’s not that the visualization can’t be done, but when it is done, it may not add value or useful information. Somewhat like a FOAF file for a person who claims five hundred people as close, personal friends – visualizing this, even to one or two levels will be impossible, and meaningless.
Probably about as meaningless as a friendship with someone who can claim 500 friends…and counting.
However, it could be a fun project, with interesting results. I’m always up for new toys. So who’s going to do it?
