No additional Twitter meta tags, please!

Thanks to Chris Messina, who has received much credit as first formulating the hashtag idea in his blog, we all now know how to understand text marked up with additional #microstructure #meta #information.

Earlier last week Stowe Boyd, who is considered to be a social media thought leader by Alltop, has taken it to the next level and published “A Modest Proposal For More Microstructure: Twitter /Locations“. His key idea is using the forward slash to tag location information in our tweets.

So:

I am using my iPhone in Munich

would become

I am using my #iPhone in /Munich

He goes even further in suggesting a closing forward slash to allow multiword locations as in /New York City/, something which Messina did not consider for hashtags and which leaves us with all the difficult to read #OneWordHashtags these days. Stowe has now coined the new term “microsyntax” and centralized all of the related activities at Microsyntax.org.

Do we really want this?

For various reasons I think this is not want we want:

Readability

Short URLs and hashtags along with @-tagged usernames already convolute most of the tweets flooding through my timeline and decrease their readability. While most Twitter clients have come up with their own ways to work around this issue, I strongly believe it’s the content of a tweet that should count, not the markup it’s author added.

Keeping meta information meta

We’ve all learned that separating presentation from content and content from meta information is a key aspect of paving the way for semantic web technologies.

If we start mixing everything again, this would in fact be a step backwards. Google’s recent announcement to allow RDFa and microformats driven Rich Snippets is a good example for how to address the problem of presenting more relevant content, making it accessible for machines and at the same time keeping the presentation clean the right way.

Meta information is essentially called “meta” because it should not interfere with the content, which it annotates.

Too much overhead

Twitter’s 140 character limit is there for a reason and wasting 23% or more of my total text capacity for meta markup even in simple tweets like RT Using my #iPhone in /New York/ does not appear reasonable to me.

Don’t make me think

I could not say it any better as Steve Krug did in his bestselling book Don’t Make Me Think: “The book’s premise is that a good program or web site should let users accomplish their intended tasks as easily and directly as possible” (Source: Wikipedia). For the geeks amongst us adding special chars to our short message might feel natural. My mother, however, does not at all understand anything about the semantic web and a growing demand for identifying relationships in unstructured data. (And yes, she tweets, too!) The task of identifying meta information such as places and keywords should be implemented in a way that does not make the average user think. We’ve already solved this for spell checking, so why don’t we give it a try here?

No more Twitter API workarounds

But there is another not so philosophical reason why we should not go further with any of these suggestions: Fundamentally hashtags, @usernames and Stowe’s newly suggested location tags are merely workarounds for limitations of Twitter’s API.

Twitter essentially provides a real-time messaging infrastructure. Not more and not less. Twitter’s attempts to provide additional added value beyond being a free large-scale message pipe have yet to prove successful. The IT folks at Twitter already seem to experience severe technical challenges when it comes to implementing higher value features like conversational tooling and openly admit that it’s getting more and more difficult to address these advanced needs given the large scale user base Twitter has grown to.

Concepts like location, language, keywords and identity are obvious candidates when thinking about messaging and communication in general. It is somewhat astonishing that the Twitter API does not yet provide any good means for third parties to leverage these aspects. Instead we have to use hashtags to mark keywords, might use slashes to tag location and maybe sooner or later somebody will suggest using curly braces to mark products and brands.

As Steve Jobs uses to say: There must be a better solution.

Could an intelligent mashup be the answer?

One alternative could be to wait for the folks at Twitter to enhance their API. Developers of Twitter clients could then access a tweet’s meta properties like language, keywords, location, brand and other structured information simply by parsing the JSON or XML returned by calls to Twitter’s REST interfaces. For various reasons I’d not put my money into this one. As Twitter Co-founder Biz Stone stated earlier this week, one way of turning Twitter into a profitable business could be to provide richer tooling.

Combine this with the fact that it will never be in Twitter’s best interest to become a truly open social platform (“open” as described here by Chris Messina) I would rather expext them to make it even more difficult for third parties to easily enhance Twitter based services. Their stupid 100 requests per hour limit is a clear expression of how they plan to keep in charge (though they might continue to claim that technical scalability reasons force them to keep it up).

I’d rather encourage the community – and more specifically Twitter client developers – to reduce Twitter down to the core messaging infrastructure role it plays and start leveraging existing standards to bypass Twitter’s known limitations. Why don’t we build an independent, open source and community-owned service along with a non-request limited API that intelligently extracts meta information from any text provided as an input and returns the parsed results back to the client?

If Tweetie for the Mac would automagically identify an incoming tweets language via Google’s Language Detection service, extract any location information via Yahoo!’s recently announced Placemaker service and leverage other methods of applied Natural Language Understanding (NLU) technologies, this would be a much more clever way as opposed to further ask users to change their texting habits when in fact technology could do better.

As a nice side effect it would help reducing the dependency on Twitter’s product strategy. In case – for whatever reason – users would have to switch to an alternative messaging infrastructure, the value added features would not be tied to Twitter’s position on intellectual property.

What do you think? I’d love to read your comments and for a personal discussion you can also find me at twitter.

Update, May 26th

As tipster Matthias Lübken pointed out, Stowe has started a site dedicated to the topic. TechCrunch picked up all the details.