I haven’t had much time to tinker in the past week or two, but I have still been thinking about recipes and blogs. I’ve also been trading emails with Troy Hakala, who’s one of the food & techie geeks responsible for RecipeZaar and who also has had a hand in the aforementioned RecipeML spec -- clearly, this is someone who knows what’s what with recipes online.

The RecipeZaar site is very rich in functionality, allowing you to refine searches by various types of information in recipes such as ingredient, course, dietary needs, preparation, and occasion. The recipes themselves are shown with calculated nutritional information, and discussion and ratings are offered as well. But, what looks like one of the best features of the site is the recipe submission process.

With all the various ways recipes are organized and indexed on this site, I would expect that entering a new recipe would demand some tedious form field entry to get the information into the database. And, while there is a tiny bit of that toward the end, with regard to categorization and cooking time, the entry of ingredients and cooking steps is done by pasting them in whole into two text areas. It seems similar to some job listing sites which manage to parse ASCII dumps of applicants’ resumes.

As you’d guess, a parser -- which I’ve been told has been in constant refinement since the site started -- churns through the text of the ingredient list and separates things into their parts. And these parts include things like amounts and units, and ingredients which are themselves linked to nutritional and descriptive data. It’s all cross-referenced and classified in a way that makes the RDF fan in me cheer -- although this ain’t RDF or the Semantic Web.

But what if it could be? Or, at the least, what if recipes could join the list of content types available to be published by bloggers. If not in RDF, then say maybe in some further developed form of RecipeML? I see recipes in my aggregator from a weblog like this and I wonder what things could be done with data like this if it were in some structured and machine-readable form.

Well, for one thing, bloggers could ping RecipeZaar when they post new recipes, and that site could become the Feedster of recipes. Bloggers could also provide RSS indexes of their recipe postings, possibly for use by future aggregators -- although, I think some major work needs to be done on the behavior of aggregators before we go too far down that road.

So, what would probably be a great start is to come up with some MovableType plugin which helps support recipe post authoring. Ideally, this would produce both HTML and RecipeML (or better) content, for both human and machine consumption.

But, there’s that filling-out-of-forms issue again. I just read a post by Marc Canter talking about the growing formats for reviews, where he asks why there aren’t more fields to fill out for a properly constructed post. He acknowledges that end-users might not want to fill those out, but we need that data to be potentially available -- but my take on it is that end-users won’t ever want to fill out any fields that they don’t have to. And, if there are too many fields that they do have to fill out, they’ll never do it.

You’ll never get people posting reviews or recipes or anything beyond blog entries without dead simple tools to do it. Because, of course, your average person sharing recipes has absolutely zero interest in authoring XML or RDF. It’s the techies and machines that want to see things authored in these strange formats, so the motivation to see rich, structured data is on the wrong side of the fence to encourage its production.

Thus, RecipeZaar uses a parser in its recipe submission forms to ease the process as much as possible. And, it’s been successful, since they can point to over 70,000 recipes submitted to their site by users.

One solution for this, 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, we’re dependant on a web service not under our control for the basic functionality of this plugin. Maybe not such a bad option, practically speaking, since its a great site run by great people.

So, just sharing some thoughts here. I’m 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 haven’t 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.