Tools are cool, but semantics matter more
It’s now been a month since I switched over to Google Reader, and as could probabaly be expected I’ve found various behaviors annoying once the novelty wore off. I suppose a lot can simply be chalked up to its beta status, and certainly there have been new and nifty features added (like the scriptlet that now shows the last few starred items in the RHE sidebar at left).
However, as I struggled to wade through a backlog (nearly 800 from just two days!) of items last weekend, while still ruminating on an article on tagging from SXSW, I found myself mildly irritated that these two salient components of the web-as-platform wave are still so sorely lacking in perhaps the most useful measure from the human perspective: semantics. Some examples of where the current common tools are appallingly lacking:
- The meaning of ‘updated’. Every newsreader seems to have some concept of an update. Yet they seem to be lacking the fundamental concept that an update means the previous version of the item is obsolete. Perhaps 10% of the aforementioned backlog in my newsstream could have been zapped if only the tool were smart enough to clear the cache of the obsoleted items. Okay, perhaps the real fault here lies in either 1) the RSS spec, which doesn’t really define any temporal or informatic relationships between items, or 2) news sources that simply spew out new items without establishing relationships among them. Yet the web has had a long history of toolmakers programming around deficiencies in specifications and content providers, why not this one too?
- Cross-posting duplications. Another 10% of my recent backlog appeared to be duplicate postings of items from different but related feeds, e.g. the general-news and sports feeds of the Tribune. I lay this annoyance squarely at the feed of the newsreader providers. All aggregators cache the feed data, so scrubbing an item from the ‘unread’ category in one stream when the same item has been read in another should be a no-brainer. Hel-lo…hash table, anyone??!?
- Tag relationships. The primary brilliance of tags vs. categories is the ability to generate (and update) metadata on the fly without having to first go define a schema for it. The secondary brilliance is the natural way that they can be searched in a logical way (a la SQL). However, I wish there had been some more forethought about tag relationships, particularly ways to formalize relationships among tags than just between tags and items. Anyone using del.icio.us or Flickr for a few weeks probably comes to learn that managing the tags becomes a project unto itself; some will no doubt tout the tag cloud, but I find this next to useless–merely eye candy for novices–since it provides no information about the semantic connections between the tags. I have always been one to categorize ideas and look for the connections–indeed, often the insight gained from the relationships is more important than any of the underlying information individually–so I find the inability to manage tagged relationships in what I would consider an effective manner to be stifling.
Hmm, I suppose such gripes might be better directed on sites monitored by people developing the various tools. But these items would seem so fundamental to the whole web-as-platform, involve-the-users ethos that I can’t believe I’d be contributing anything novel. Has no one considered them before? Are they really that difficult to implement?
