Les Orchard has some interesting ideas on building out [1 2] a microcontent client for recipes, based on RecipeML: “The real strength in a recipe web would come from cooking bloggers. Supply them with tools to generate RecipeML, post them on a blog server, and index them in an RSS feed. Then, geeks get to work building the recipe aggregators…Since I’d really like to play with some RDF concepts, maybe I’ll write some adaptors to munge RecipeML and MealMaster into RDF recipe data. Cross that with FOAF and other RDF whackyness, and build an empire of recipe data.”
A respone from Troy Hakala:
We (Recipezaar) wrote a natural language recipe parser to make this possible and it’s a difficult job.
Imagine a world of XML recipes distributed around the web on weblogs. An aggregator would need to aggregate millions of weblogs just to cull together a few hundred or thousand recipes. Now imagine millions of aggregator users doing this daily or hourly the way they do this today for weblogs. And if a weblogger had 1,000 recipes on their weblog archives, they wouldn’t want millions of aggregators eating their bandwidth every day to maintain the database for each individual using an aggregator (webloggers today already complain about aggregators costing them too much money in bandwidth costs). Additionally, 99.999% of people who create recipes are unlikely to have a weblog to post their XML recipes so you’d lose the majority of the potential content.
A centralized repository provides a place for regular users to post their recipes and get them seen by the most number of people. And a centralized repository provides an easy way to search for recipes, browse for recipes, review & rate recipes, discuss recipes, etc. And let’s talk numbers…. today, Recipezaar has 73,000 recipes in the database and, while it’s the largest database of recipes on the internet, people still can’t find a particular recipe because there is an infinite number of possible recipes that can be created. Having a few hundred or a few thousand recipes is not a useful database to people. More is better. And acquiring more via an aggregator is a big and expensive job.
Distributed databases are useful in some contexts and centralized databases are useful in other contexts. Each has their own advantages and disadvantages, but like auctions, recipes are best stored centrally where everyone has access to them.
Adds Orchard:
If the people behind RecipeZaar like the idea, is to borrow their parser via web service for use in my hypothetical MovableType plugin. This could also be used for any number of other blogging tools. On the upside, we get the benefit of all the work done by Troy and company, and they get to pull in more recipes. On the downside, were dependant on a web service not under our control for the basic functionality of this plugin.
Im excited to see more varieties of micro-content shared between the people of the web, but the thing I see least talked about is how this stuff will be authored. I read about data formats and all that, but in terms of user interface, we havent progressed much past the HTML textarea. Also, I often see handwaving and assumptions that the content is really pretty simple — but as Troy Hakala would tell you, not even something as simple as a recipe is a slam dunk in terms of digestion by a machine. There needs to be some happy medium between a natural human expression of information, and the rigorous structuring required by a machine, mediated by good user interface.
As I read all this, I couldn’t help thinking that we need is an Information Marketplace. I think I have to speed up the thinking and just get it done. There are many areas I can now think of applying it: for SMEs to find each other, an IndiaMirror and now recipes.
