Microformats and Web Services Redux

Earlier I made a comment about how I wished there was a better way to connect microformats to web services. I’d like to elaborate on that comment and see if I could get some discussion going around the subject. First let me summarize the problem. (Note that throughout this post I will use the term microformat, but all these problems hold true for RDF as well)

The problem is that there is no standard way (that I’ve found) to interact with various web services that deal with the types of data involved in microformats. Note that in some cases there are standard data interchange formats (like vCard and iCal), but the web services do not always accept these formats.

The way Operator solves this problem through the use of user scripts that implement actions. What these actions do is take the microformat and use the data to construct a URL (or even a POST request) that connects to the appropriate web service. For instance, if I want to add my hCard to to the Yahoo! address book, the URL might look something like this:


In this case, the user script has taken apart the microformat and then constructed a URL that emulates adding a Yahoo! Contact. In doing this, lots of code was involved because the Yahoo! Add Contact does not map completely to the data that was in the microformat (you can see that code in yahoo.js). (Folks might ask why I’m not using Yahoo! APIs – that’s mainly because I don’t want to mess with authentication keys and stuff – this is a web interface, so I’d rather just redirect to websites)

The problem with this code is that in order to express the mapping from a microformat to Yahoo!, I require a large chunk of code.

For Firefox 3, I want to provide some UI that connects microformat to web services, but I want that to be extendable by third parties. I want it to be similar to how feed readers work in Firefox 2 (see registerContentHandler). While my action architecture works in the context of Operator, I do not believe that it is robust enough to be a part of Firefox 3. So what I’m trying to find is some better way to describe the mapping between microformats and web services or possibly to create a new standard around interacting with these web services. It might be as simple as just encouraging all of the vendors to accept the upload of vCard and iCal. I don’t know. Here are some thoughts I (and others) have had.

Encourage people to support the submission of vCard and iCal in a standard way

The obvious thing to do here would be for services to allow the submission of vCards and iCals directly to their web services as a way to provide information to the services. 30 Boxes currently allows this, but unfortunately the iCal must be physically located on a web site, so I can’t send it to them. Other services that accept vCards use a POST mechanism that is difficult to emulate because it relies on lots of private data during the POST submission.

Server Data Broker

Setup up a web service that would essentially act as a data broker. Data could be given to this server in a standard way, and then the server would turn that data into a URL that could be used to redirect to the appropriate web service. In this way, the logic to turn the microformat data into a URL would be done on the server. The client would give some common data source to the server, telling the service where it wanted the data to be sent and the server would simply send the client a redirect URL.

OpenAction similar to OpenSearch

S. Sriram had an interesting thought in reply to my previous post. He thought about using something similar to OpenSearch where web services can have an XML description file that describes how to interact with their services and then we could use that file to determine how to map the microformat data to the web service.

Those are just a few ideas we’ve come up with. I’d love to hear any other ideas you might have…

Please note: I reserve the right to delete comments that are offensive or off-topic.

Leave a Reply

Your email address will not be published. Required fields are marked *

11 thoughts on “Microformats and Web Services Redux

  1. Instead of “Encourage people to support the submission of vCard and iCal in a standard way”, why not “Encourage people to support the submission of hCard and hCalendar URLs” (e.g example.com/hcard or example.com#hcard)? Then you could simply pass the URL of the page or part-page you’re parsing. Of course, that would require each microformat to have a UID. Maybe that should have been mandated anyway? Hindsight is wonderful…

  2. > why not “Encourage people to support the
    > submission of hCard and hCalendar URLs”

    That doesn’t work because you can’t submit intranet data to the internet.

    The interchange needs to be about the data, not about URLs…

  3. I think the Server Data Broker doesn’t realy solve the problem, because you always need kind of User Scripts to build the URLs and you still have to use URLs.

    An adaptation of the OpenSearch principle or a simple version of the Web Services Description Language (WSDL) would be more powerful. It enables a decentral work and replaces the use of User Scripts nearly complete.

  4. I think encouraging web service providers to handle hCard and iCal file uploads is the right way to go. Preferably by pushing for an extension of registerContentHandler, so that is can do POST file uploads.

    Using a server data broker doesn’t make things better, but instead more complex.

    I cannot see the difference between a JS and a XML based format to describe how to send things to the web service.

  5. The URL templating stuff is very interesting. It certainly would give me a better way to define URLs for passing to the web services. Thanks for the link.

  6. Bleh!

    link elements with the rel attribute

    A webpage wants to tell you where to look for uploading generic microformat info:
    //link[@rel=”microformat add”]/

    Perhaps the type attribute can be used to suggest the specific microformats allowed; ie; text/v-card

    Atom does this reasonably well with:
    link rel=”edit” href=”http://example.org/blog/entries/1″

  7. Mike: your point about intranets is well made. It applies to local files and RSS feeds (and probably HTML e-mails, evil though they are) also.

  8. There’s another aspect of this problem – linking a website to its own web service.

    A lot of websites (especially in the field of biology) consist of a large database and a web interface that allows the user to look things up and navigate through the data. A lot of those sites provide web services for programmatic access to the same data.

    But, the HTML interface and the web service are totally disconnected. Microformats could do the job of linking the two back together. The user could then browse through the database, find datasets of interest, then use a webservice to download the data.

    Our group developed a Firefox extension called Firegoose which seeks to enable exactly that for bioinformatics websites. We follow the somewhat painful route of screen-scraping enough information to build up calls to related webservices. Standards for connecting web services and microformats could go a long way towards making that process easier and less manual.