Working the last months with microformats a lot, I come up with the conclusion, that microformats enable us to implement mashups in a totally different way … I call this kind of implementation mashup2.0 … or a litte less buzzword like:

(Short note: Here you find the RSS feed for englisch articles on my blog - it’s mainly written in german)

MicroMashUp - remixing content without any web API

Microformats gives us the possiblity to markup microcontent within XHTML pages semantically, and thereby enables maschines to read, understand and process this data. Web API’s are most of the times used to access data, which is allready visible to humans, but not marked up and well structured to handle them in a different automated way.

In the moment where I markup this data with a adequate microformat, which gives the microcontent the semantik I need for my mashup, the way we access this data could(should) change dramatically … and even perhaps makes mashups much more easier!

Because: why should I use a not standardized application programming interface, when I can easily access this standardized data format by parsing a (standardized) XHTML page? The problem is of course the way I can access this data, because I need to know the URL of it. But for this problem I see solutions at the web2.0 horizon and several possibilites.

The impact of MicroMashUps on information architecture and URL design

I have a lot of accounts at a lot of webservices, always using the same nickname. And these services let me access my personal page, through descriptive URL’s:

• http://claimid.com/pixelsebi
• http://beta.plazes.com/user/pixelsebi/
• http://flickr.com/people/pixelsebi
• http://qype.com/people/pixelsebi

Whow - that’s awesome, because did you now, that the hCard specification allready includes a property called “nickname”? So if I parse a hCard from someone, which includes his nickname (under the assumption, that he uses allways the same), I could crawl through ever know webservice, which is using descriptive URL’s and check, if he has a profile there and start my data discovery tour.

Of course this way would not proof, that this nickname is always used by the same person, but there I see concepts like microID coming up, which could solve this problem.

Anyway - beside descriptive URL’s for profiles, we all allready know the rel-tag microformat and URLs like

• http://flickr.com/photos/tags/barcamp
• http://del.icio.us/tag/barcamp
• http://claimid.com/pixelsebi/tag/barcamp
• http://qype.com/tag/barcamp

So here we have another real world example of accessing data, by using values of microformats within a descriptive URL. (and I could continue this with other cases, as for example where the name of places is used in the URL to access Reviews of those)

What is missing at the moment, is a standard for descriptve URL’s, which would make it possible to access every web service the same way! A standard like this, should be based on the same roots as microformats do, and use the same nomenclature if possible.

Desgined for humands first, maschines second …

The interesting thing about descriptive URL’s is the fact, that they originally came up due to humanistic influences on usability issues. In a nutshell: URL got descriptive to make the usage of them easier and more intuitive for humans. And now I see there a big advantage for maschines, because it could enable them, to access data by URLs with values they have accessable through microformats.

This is a great relfection of the design prinicples for microformats, which should now be applied to URL design and help creating a standard for URL design, which is really needed … for humans first and maschines second.

We can’t regard URLs without the impact on the information architecture itself! Information architects have to take the advantages of microformats, descriptve url’s and the easy accessable power of MicroMashUps into account, when they design the structure of a webservice in the future (or redesign it right now!)
In a ideal world, we can not only access “static” content through descriptve URL’s but also access functions, which give us a XHTML page in result. A good existing example for this is plazes.com. I can request the current whereabout by using the following URL:

http://plazes.com/whereis/pixelsebi

Descriptive again - easy to usw for humans and perfect for maschines again. I hope my explanaitions help you to understand the decreasing need fo API’s anyway! Theoretically I can build web services in such a way, that I can access anything needful.

Why we don’t need web API’s for mashups anymore?

Because there are two realy good reasons for this:

1. we can markup every single microcontent we wanna have for our mashup with microformats. If the microformats does not exist yet, we will have it in the future!
2. we could make every potential remixable data marked up with microformats, accessable through descriptive URLs, based on the nomenclature and standard

What else do we need, to make it happen?

Beside everything I illustrated up here allready, I see there a increasing need for better semantik marked up hyperlinks within XHTML pages. Theoretically we could cover a majority of the usecases with descriptve URL’s, but for the rest, we need our maschines to understand more, how the data is networked among each other.

We allready have a few microformats for this, using the rel-tag, but those can’t cover the hole requirements of future MicroMashUp-Cralwer, which will have the task to satisfy us human beings … humans first, maschines second. ( I reiterate my self, do I?)

I think the next importand technique beside descriptive URLs, is the strengthened usage of crawlers, which collect the needed data based on microformats. Microformats will on the one hand, markup the data the crawler have to collect and on the other hand, implement the needed semantic to understand the relations between them and help them find the right way.

Conclusions

• a lot of mashup use cases could be done based on microformats
• a lot of mashup use cases could be done without any api usage
• we need standards for URL design and nomenclature
• we need more microformats based on the rel-tag to guide crawlers

… and the last conlusion is:

We need a showcase to demonstrate the possiblities!

And on this showcase we are allready working here in germany and will present it on our barcamp in berlin. on day befor the official barcamp, we will have a intensive MicroMashUp-Session and will experiment with the possiblities on the basis of the allready mentioned services called QYPE* and Plazes.

Plazes is a kind of people localizer and detects your location, by the network you are using with your laptop. Your plazes and people arround you are illustrated with Googlemaps, you can set up friends and so on. This service allready implemented microformats.

QYPE* is a kind of “local search engine and places review/recommendation” service, also using microformats allready. So we wanna mashup these two service based on:

• microformats
• descriptive URLs
• a small crawler
• … and as less as possible API request at all!

You only point to your hCard (with nickname included) and there you go. You will get your places, with its reviews, you can display other places nearby with their reviews, people who have written reviews, visted the place before and so on. (we will try to aggregate as much as we can)

More over we could imagine to integrate upcoming.org as well, to show the events in your area etc. - but at upcoming might began the problem, because we have no influences there, to make easy adjustments.

Of course we will document our project and if you wanna keep intouch with it, just continue reading my blog

The End

So if you have made it so far, thanks for your time reading my long article. I hope I could give you a deeper inside in the power of microformats, combined with descriptive standardised URLs .

I am very excited about your feedback and hope that you take additional time to write a comment, send me an email or even odeo!

Spread the word about MicroMashUp … the Mashup2.0!