some thoughts on metadata

Through a series of random links I ended up a recent post by Ramesh Jain on metadata. He raises a number of issues that have crossed my mind a lot recently, particularly with all the hoopla about podcasting ("how do I search all that audio content?") and makes a number of good points. Quote:

Text is effectively one dimensional – though it is organized on a two-dimensional surface for practical reasons. Currently, most meta data is also inserted using textual approaches. To denote the semantics of a data item, a tag is introduced before it to indicate the start of the semantics and another closing tag is introduced to signal the end. These tags can also have structuring mechanisms to build compound semantics and dictionaries of tags may be compiled to standardize and translate use of tags by different people.

When we try to assign tags to other media, things start getting a bit problematic due to the nature of media and the fact that current methods to assign tags are textual. Suppose that you have an audio stream, may be speech or may be other kind of audio, how do we assign tags in this? Luckily audio is still one dimensional and hence one can insert some kind of tag in a similar way as we do in texts. But this tag will not be textual, this should be audio. We have not yet considered mechanisms to insert audio tags.

[...]

I believe that we can utilize meta data for multimedia data. But the beauty of the multimedia data is that it brings in a strong experiential component that is not captured using abstract tags. So techniques needs to be developed that will create meta data that will do justice to multimedia data.

I agree. However, I'd point out that the problem is not just one of metadata creation, but of metadata access.

Metadata is inevitably thought of as "extra tags" because, first and foremost, our main interface for dealing with information is still textual. We don't have VR navigation systems, and voice-controlled systems rely on Voice-to-Text translation, rather than using voice itself as a mechanism for navigation.

Creating multimedia metadata will be key, but I suspect that this will have limited applicability until multimedia itself can be navigated in "native" (read: non-textual) form. Until both of these elements exist, I think that using text both as metadata (even if it's generated through conversions, or context, like Google Image Search does) and text-based interfaces will remain the rule, rather than the exception.

the synth look and feel: what Sun should do next

One of the much-hyped new features in JDK 1.5 (or "Java 5" as we're supposed to call it now) was the new Synth Look and Feel, which is a "skinnable" L&F that allows non-programmers to create new look and feels by editing an XML file. Since creating a look and feel before involved complex acts of witchcraft, this is actually good news for programmers as well.

But.

There's very little documentation available. The most referenced article on Synth is this one by SwingMaster Scott Violet, which is a good intro but doesn't go into much detail. There's a mini-intro over at JDC. There's a more recent article by John Zukowski over at IBM DeveloperWorks which also covers the new Ocean L&F (which replaces the absolutely-positively-obsolete Metal L&F). Then there's the API docs for Synth and the Synth descriptor file format. And... that's about it, as far as I can tell. All the examples stop at the point of showing a single component, usually a JTextField or JButton.

But, let's assume that documentation will slowly emerge. There is something that Sun should do as quickly as possible (and that in fact it should have done for this release), which is to use Synth for its own L&Fs. What better chance to show off Synth than to rewrite the Metal L&F in it? (I am fairly sure that this hasn't happened yet, since the way to load the Metal L&F remains the same, and all the Metal L&F classes remain under its javax.swing.plaf locations in the JDK 1.5 distribution).

In fact, while we're at it, why not write all the look and feels with Synth, including Windows, which would make it much easier to correct the inevitable problems with it that appear after every release (and because of which something like winlaf exists)?

This is also known in the vernacular as "eating your own dog food". :)

Re-writing Metal in Synth would also be a perfect use-case that would serve both as a testing platform and example for others. As it stands, it's hard to know if this wasn't done because of performance limitations, limitations in Synth, time-constraints, or what.

So I'd like to see Sun clearly spell out the reasons why Synth wasn't used for Metal, and where they are taking it next. I, for one, am not thrilled about the idea of yet another look and feel that will remain dead in the water (like Metal did all these years), when there are so many other important things that Sun could be improving in the JRE (platform integration, anyone?).

If all L&Fs will eventually be Synth-etized, that would simplify usage and fixes of L&Fs for all developers (and maintenance on Sun's side), and prove that Synth is the way of the future.

PS: it would also be a good idea to add built-in support for the notion of L&F hierarchies to Synth files (Currently all the commands must exist in a single file; you could create a single stream of XML descriptor out of multiple Synth files, but who's gonna do that?). Having to do copy+paste for everything and then changing two or three lines in a file because all you want is a different image somewhere doesn't sound like good practice to me.

the switch from berkeley db over to mysql

One of the objectives of my recent server switch was to move from Berkeley DB to MySQL (aside from an expected performance improvement, I was tired of seeing plug-ins for MT that I couldn't run-- example). Plus I feel more comfortable with MySQL. I followed the instructions for this in the movable type documentation and aside from some glitches during conversion (weird messages such as "WARNING: Use of uninitialized value in string eq at lib/MT/Util.pm line 754.") and one timeout (which forced me to restart the process after deleting the old tables) everything went fine.

One thing to note though, which the documentation doesn't make completely clear: when you run the mt-db2sql.cgi script, you must leave both the previous BerkeleyDB pointer as well as the configuration for MySQL. Once the conversion is done, you can comment out the BerkeleyDB location line. During the process, I also renamed the trackback and comment scripts, to avoid overlaps.

Now all seems to be running fine, and simple tests seem to show that some things are a bit faster (example: posting takes about 20 seconds, as opposed to 30 seconds before).

One more thing I can cross off the list. :)