TechFold - Bold tech & web commentary
Bold tech & web commentary
Subscribe to RSS FeedTechFold is technology discussion, commentary, reviews, and opinions from well outside the valley. There's no koolaid to drink here, and TechFold is not in SL, or on Twitter.
Another Tag Silo - Twitter Hashtags
A few days ago, I riffed on how the failure of user-powered tagging was what was driving the need for a semantic web - that jumbled, discontiguous tagging implementations had created a plethora of tag city-states who’s inability to talk on a “national” level had reduced the tagging movement to a curiosity.
Today, another entrant in the form of Hashtags - tags for twitter post. Again, useful within the silo of the twitter-verse, but clunky to extend outwards. You can read more on hashtags via stoweboyd, or stephanie booth, or check out full coverage.
The stated purpose of hashtags is to all one to follow a topical twitter-stream, as was useful for those techies fleeing the SoCal fires this past year. But how much cooler would it be if you could stitch together Twitter content, Flickr coverage, posted videos, blog posts, and news, into a single realtime view of a given situation? That would look a lot like the output of a semantic application.
To do so now would require onerous hard-coding of proprietary hooks into each services API (twitter, flicker, youtube, etc.), with more custom coding to parse out time and geo-relevance data. As I mentioned in my previous article, a two-tiered tagging system composed of machine and human tags, shared in a consistent format, and conforming to common baseline standards would enable this.
hashtags, semantic, tagging, tags twitterIf you enjoyed this post, make sure you subscribe to my RSS feed!
Related Posts
Tweetmeme DOA?
Track your Memes on Twitter!
Follow me through Asia on Twitter
Twitter Spamming
Twitter Quibble
6 Responses to “Another Tag Silo - Twitter Hashtags”
Leave a Reply
Subscribe to TechFold RSSRecent Posts
- Google Blogsearch: the Techmeme sapper
- Stubhub Revisted
- Yahoo and Bain: What’s Really Going On
- IE7 Hanldes Flash Way Better than Firefox3
- Microsoft is Hamstringing themselves
- Does anyone else think Google is over-extending itself?
- Going Travelling? Try VentureFar.net
- If you could go anywhere in the world and meet with any geek, executive, or company, who would it be?
- Is Apple Paying for Product Placement in Paperbacks?
- Scoble and Twitter in the Borneo Bulletin: the future of news?
Recent Comments
- Mike on How to Make Cluztr the Next Big Thing in Four Easy Steps
- RajSri on Does anyone else think Google is over-extending itself?
- Stubhub Revisted « TechFold - Bold tech & web commentary on The StubHub Scam
- Leibowit » Excited for Tickets? Too Bad on The StubHub Scam
- Bartek on Facebook Gets It, Becoming the Web OS: Microsoft 2.0
Post Archives
- October 2008 (1)
- September 2008 (6)
- July 2008 (2)
- May 2008 (5)
- April 2008 (9)
- February 2008 (5)
- January 2008 (26)
- December 2007 (28)
- November 2007 (16)
- October 2007 (7)
- September 2007 (17)
- August 2007 (15)
- July 2007 (19)
- June 2007 (67)
- May 2007 (62)
- April 2007 (66)
- March 2007 (1)
Categories
Links
What’s wrong with simply using the rel-tag microformat?
There’s nothing “wrong” with it, IMHO - its just not a complete solution. Rel-tag marks up a bit of information contained within a larger document but doesn’t cover how that information can be shared or communicated (as I understand it).
i.e.: extracting rel-tag info requires parsing/scraping, where the microformat is even used (flickr and del.icio.us don’t use it that I can see). I don’t think anyone, regardless of programming skill level enjoys writing scraping apps, particularly when they need to span a wide and disparate population of potential formats.
So - I think the argument I was making in my last post on the topic was that tagging should be written into the next rss spec so that tag-data can be consistently communicated/shared/indexed. FWIW I think the in-page elements of rel-tag are part of the solution, just like building well-marked up template for one’s blog posts is only part of the solution for blog publishing (rss feeds being the other part…)
Fair enough. I see your point. Seems to me then you should get behind ATOM’s categories:
http://www.atomenabled.org/developers/protocol/#appCategories2
Some balance between these formats will at least allow for the tagging data to flourish… and then it’s a matter of building the proper “data strainer” to sift through it all!
Chris - thanks for the link to the ATOM page; I don’t know a lot about ATOM to be honest, and so far have enjoyed working with RSS, or with parsers that negate the need to understand the differences between the two.
That being said: the ATOM categories parent/child structure looks like what I’m envisioning in my head. The only counter suggestion would be to do something lighter weight - like collecting tags in a single “tag” element with spaces as the sole delineation between “tags” - then parsers can just explode the element’s contents as opposed to navigating a tree (less overhead, lighter feeds?). Just a thought…
In any event, thanks for stopping by to share your thoughts!
-R
[…] - and those special situations seem to me to be better served by something more explicit, like hashtags. techmeme, techwatching, tweetmeme twitterShare This If you enjoyed this post, make sure you […]
good post, as is “Tweetmeme: DOA”. Why don’t you put your Twitter URL in your posts, let’s talk there…