Location, Location, Location: More on /Location and Microsyntax
It has been an interesting few days, since I posted A Modest Proposal For More Microstructure: Twitter /Locations, in which I presented the idea of a new sort of syntax for Twitter (or microsyntax) to represent location. Instead of tweeting this
Just landed at SFO headed downtown ASAP
tweeple could instead post this
Just landed at /SFO headed downtown ASAP
The idea being to have a human- and machine-readable to indicate location. Longer locations involving multiple words would be set off with trailing ‘/’ as well:
Working at /156 South Park, San Francisco CA/ this morning
This proposal has led to a great deal of feedback, ranging from ‘Cool, let’s build an app to try this out’ to ‘You’ve gotta be kidding’ and everything in between.
Perhaps the most organized arguments against the ‘geoslash’ idea (as Ross Mayfield and the WhereCamp folks are now calling it) are those offered by Ralf Rottman, whose post is entitled No additional Twitter meta tags, please!, which gives you a pretty good feel for his position on the subject.
Rottman uses the term ‘meta tag’ to represent what I am calling microsyntax (formerly I called it microstructure, but that is a bit less specific). Meta tags in HTML are various sorts of information buried in specific HTML elements, and these are intended to be machine readable, and not generally to be inspected by people. My goal with /location is to insert a small bit of punctuation in the tweet, which is human readable as well as machine readable.
His primary argument against microsyntax is clutter, which, he says, is already causing readability issues with usernames, shortened URLs and hashtags that are already in wide use. My answer to that is that people are trying to make Twitter workable, and these conventions have arisen to serve a need. Despite what the Sunday supplements are saying, most Twitter messages are not ‘just ate a pickle’, but are more likely to be something like ‘@ross Check this out, and get back to me http://bit.ly/vv1zC #passwords’. People are getting things done, not contemplating their navels, and if that means slightly greater complexity and lumpiness in the twitter stream, so be it.
The rest of his argument is really a tirade against the Twitter architecture. He wants metadata pulled out of the text of Twitter messages and supported in an invisible exterior way by a new Twitter plumbing:
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.
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 suggest that Ralf take these recommendation up with the nice folks at Twitter. In the mean time, bitheads like me will continue to offer up ways to encode intention or meaning into the twitter stream, for any number of reasons. In the case of /location, my goal was simply to make it easy for a relatively dumb Twitter appliance to keep track of users” locations over time, based on the Twitter that exists today.
Other feedback:
- Many asked about the use of ‘/’ and argued for other characters — ‘/’ is an interesting sort of punctuation mark. It is not used in a wide variety of forms likely to be common in Twitter. It is found in URLs, but not as the leading character. It is used in alternatives, like ‘contact me by email/dm’ but again, not as a leading character, in general. It is easily reached on cell phones and other mobile devices because it is needed for URLs. I therefore think it is preferable to parentheses, colons, asterisks, and other suggestions made. In particular, ‘^’ is already in use as a convention for identity — initials of authors in group or corporate Twitter accounts.
- Lat Long — I think lat long is interesting for machines, but I can’t parse it so it’s not in the same category.
- URL — Some have suggested use of a URL like http://sent.fm/san+franciso, which translates to a page at that service, but I am opposed for three reasons. First, I don’t like the idea that some service gets all the links (same argument I had years ago about Technorati and tags, when I argued for Open Tags). Second, the URL takes up a lot more characters than two slashes does. Third, it doesn’t read like everyday speech.
- People have asked about ‘l:’ and other proposed conventions — I don’t like ‘l:’ because it interrupts my scanning of language more than ‘/’ does. I don’t like the notion of taking over alphabetic letters to perform punctuation duties. That’s one of the reasons I dislike ‘RT’. Besides, ‘l:’ has been around and hasn’t caught on: time for another experiment.
- Some have suggested that smart apps should just read everything, scanning for location information. First, that could be very computationally intensive, and second, not all discussions about location mean that the author is asserting actually being there.
I wish I were in Paris
is different from
Just pulled into the train station in /Paris, France/
It is the latter case that I am interested in. Also, something like this
Just read that the #WhiteHouse is against sunflower seeds
is very different from
Taking the tour of the /White House, Washington DC/. Hope to meet Barack!
Ross Mayfield and some folks at the WhereCamp this last weekend are working on an app to parse /location from tweets. More to follow on that front. I know there are other developments going on in that direction, too.
