Building the Recipe Web?

RecipeML is a format for representing recipes on computer. It is written in the increasingly popularExtensible Markup Language - XML.

If you run a recipe web site, or are creating a software program -- on any platform -- that works with recipes, then you should consider using RecipeML for coding your recipes! See the FAQs and the new examples for more info.

So I'm all about this microcontent thing, thinking recently about recipes since reading Marc Canter's post about them. Actually, I've been thinking about them for a couple of years now, since I'd really like to start cooking some decent meals with the web's help. Oh yeah, and I'm a geek, so tinkering with some data would be fun too.

One thing I rarely notice mentioned when ideas like this come up is pre-existing work. Like RecipeML or even the non-XML MealMaster format. Both of these have been around for quite a long time, especially so in the case of MealMaster. In fact, if someone wanted to bootstrap a collection of recipes, you can find a ton (150,000) of MealMaster recipes as well as a smaller archive (10,000) of RecipeML files. Of course, I'm not sure about the copyright situation with any of these, but it's a start anyway.

But, 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. Hell, I'm thinking I might even give this a shot. 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.

The thing I wonder, though, is why hasn't anyone done this already? And why hasn't anyone really mentioned much about what's out there already like RecipeML and MealMaster? It seems like the perfect time to add this into the blogosphere.

shortname=the_recipe_web

Archived Comments

  • Though not "open", you do know of the epicurious recipe site, right? http://eat.epicurious.com/
  • I am a blogger that absolutely loves to cook (and throw dinner parties for that matter). I have just recently decided to start posting recipes (and pictures of finifhed dishes) as well as talk more about cooking. I would love to get involved in any kind of project like that where we could subscribe to each other's recipe feeds. I think it would be great.
  • FYI : http://www.eatdrinkfeelgood.org Plans for version 1.2 include some sort of support for things RDF-ish [1,2] (though may just mean an easy export facility) and the beginnings of a GUI tool. I know that it's not the easiest format in the world to write by hand. This was a conscious trade-off but it would nice to have a tool that hid some of that from users. Realistically, I won't start any of this until after the new year. Suggestions and patches are welcome. --- [1] http://eatdrinkfeelgood.org/misc/test2.rdf [2] http://aaronland.info/xsl/wordnet/wn-find-class/
  • As one of the contributors to RecipeML (and the person who named it ;), I like the concept. However, it isn't useful in practice. Imagine the same thing for auctions. There could be an XML format for auctions, everyone can post their items for sale on their weblog and auction aggregators would replace eBay. This would not be as good as eBay, obviously, as there is significant value to a centralized database of auctions. The same is true for recipes, in my opinion. Additionally, creating RecipeML for recipes is a difficult task. Sure, it's fairly easy to write a few recipes in RecipeML if you're technically adept, but to do thousands becomes impossible and for the average recipe producer (grandmothers, chefs, etc) it just won't happen. And you really do need thousands to be a useful database (even your average cooking magazine publishes hundreds a month). We (Recipezaar) wrote a natural language recipe parser to make this possible and it's a difficult job. It took us 3 years to write it! Recipes are far more complicated than you might think, believe it or not. And a natural language recipe parser is not trivial software, which is why no other recipe web site has done this except for Recipezaar. We could release the software under the GPL so that everyone can start creating XML recipes. We've considered it and we've talked to people about doing it but after some thought, people do realize that it wouldn't be useful. Because, again, having recipes distributed across web sites is less powerful than a centralized repository of freely-available recipes. 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.
  • I agree with the central database theory.BUT, why limit to KRAFT or epicurious or the like.There are LOTS TONS even of unpublished or un-online recipies out there.My mother has several shoe boxes full and can't organize them yet.

    I know HOW to do it, but there is no stable MMF reader for OSX that fixes corrupted input yet.MacGourmet FAILS. Shop-n-cook uses propeitary display routines and Gourmet RM for *nix wont build on OSX, which is what I normally use.

    Digital chicken comes close but takes FOREVER,even on dual core to convert to the database format just to spit out an error message.These recipies, the PROBLEM IS, are NON-standardized. There are comments EVERYWHERE.

    This would throw off ANY parser.I had a method that may have worked, but I lost the pascal routines a few years ago.It used screen 'pages' to store the data.Mind you it wasn't GUI mode, but it could have been.

  • I am a blogger who loves to cook (and dinner parties for that matter). Recently I decided to start posting recipes (and photos of dishes finifhed) and talk over the kitchen. I would like to participate in any such project in which you can subscribe to the source of income of the other. I think it would be great. Viagra Generic Viagra Kamagra
Building the Recipe Web II  Previous The Whuffie Web II Next