476 words
It being a public holiday today, we enjoyed the leftovers of the massive shopping spree that Ansgar and Birgit had gone on on Saturday and had a serious barbecue. Nice salad and antipasti, lots of meat and fish and waffles for dessert. We simply took the waffle iron out on the balcony. We also managed to finish off the last bottles of the (mostly bad) leftover wine from our party that people had brought and not drunk.
While on the topic of food, I am once more convinced that English speaking people fail to grasp the concept cheese cake. That's sad: The main point is that it's not about chocolate and not about fruit. Quite simple. The next problem may be the correct cheese. Whatever is sold as cream cheese most likely won't do the trick as it tends to be too solid. The right cheese to use is Quark which used to be hard to get outside Germany, but by mid 2000, seemed to be standard at both Sainsbury's and Tesco's. If you don't know Quark, it's a bit tricky to describe. It's sour-ish and not as solid as crème fraîche or cream cheese are. Just try to find it and don' be afraid because the name sounds like advanced physics.
For the crust:
For the filling:
Hmmm, cake. Once you've got that bit sorted, you may want to put some sliced almonds and a bit of the egg yolk (to make them stick) on top of the cake. Or, if you absolutely must have some fruit, add well-drained cherries on top of the crust before you put the Quark mixture on top or put raisins into the Quark mixture. In summer, serve the cake straight from the fridge and be generous with the lemon flavour as it makes the cake taste very refreshing.
I’ve converted your recipe into EatDrinkFeelGood [1] XML, and posted it on my site [2]. Thought you might be interested; it’s a different way to represent recipes :)
[1] http://www.eatdrinkfeelgood.org/ [2] http://www.crystalflame.net/recipes/Cheesequark.xml
That’s quite cool. I keep my recipes in an ancient FileMaker database. Back when we started it (for my mum) it seemed like the best way to organise the recipes in a way that they could be sorted and categorised while still being searchable. Thanks to FileMaker it was also easy to have nice print versions.
That system seems to be a more modern and structured approach. My only objections would be that it is too precise, i.e. that entering ingredient data seems like a bit of a pain. I quite like freeform data entry. On the other hand, this looks like it enables you to have automatic conversion to the units the reader is most familiar with (e.g. all metric, or ounces and cups), which can save a fair amount of conversion and confusion when exchanging recipes internationally.
The other would be that it’s not precise enough: If you specify units, they should be precise. I have the impression that the idea of the size of a tablespoon varies significantly or that of a pint (Imperial vs. U.S.) etc.
While I’m not totally convinced of this yet, I suppose it has potential. But I’d prefer to see that potential show in the form of easy access to recipes, easy conversion etc. before making the effort to write anything down in that format.
To quote the front page of eatdrinkfeelgood:
I would also remind readers that reliance on precise recipes alone can be a trap. The dangerous person in the kitchen, wrote Marcel Boulestin, is one who goes rigidly by weights, measurements, thermometers and scales.
— Elizabeth David
There’s tools [1] and xslt to html [2] templates available for processing the recipes, as well.
[1] http://www.eatdrinkfeelgood.org/tools [2] http://www.eatdrinkfeelgood.org/examples
I of course saw that quote. And I mostly agree with that - if only for the fact that I can’t remember the exact quantities and mostly am too lazy to look them up, thus having to approximate them.
All that doesn’t make sense to me though. Why have a format that lets you nitpickingly enter the ingredients, their quantities and their units if they’re not all that important anyway? Free form entry of quantities, e.g. in a simple text field would be much more convenient.
The only reason I could see for having those measurements and units specified precisely, would be to enable automatic conversions easily. If the size of a tablespoon can vary by a factor of two, say and the measure of a pint by almost 25% between their definitions, conversions become very hard though.
I see lots of interesting applications by the way: Say, a recipe needs 500ml of some ingredient. Depending on the user’s preference, a program could convert this into an exact equivalent in pints or liquid ounces or a rough equivalent (e.g. ‘slightly less than a pint’ for UK users or ‘slightly more than a pint’ for US users, or ‘2 cups’ if that’s more appropriate for the kind of ingredient). The same could go for all other conversions and even include conversions from say ‘ca 250g of flour’ in a German recipe into ‘about 2 cups of flour’ in the English version.
In short: I don’t see any need for that kind of precise data entry in the spirit of that quote. But I do see potential niceties you could use them for if they were precise and better defined. Thus I don’t see the point of doing it the way it seems to be done now.
Coming to think of translating recipes. If aiming at a worldwide audience, there should also be a way to specify equivalent items for certain ingredients. E.g. I mentioned vanilla sugar in my recipe. It seems to be a German thing: You buy it in little portion size bags and it’s like white sugar with vanilla taste. In Scandinavia, however, people seem to use a kind of icing sugar with vanilla taste which comes in tubs that last for a while. In England, you’ll get some vanilla essence, a few drops of which will do the trick as well. All of them are alomost the same thing but when reading foreign recipes it’s sometimes a bit tricky to figure out how to do it in local ingredients.
Re: the tools. I briefly looked at them (their server is slow, isn’t it?) but they seemed to complicated for me to deal with for the time being. It’s only recipes after all.
I of course saw that quote. And I mostly agree with that - if only for the fact that I can’t remember the exact quantities and mostly am too lazy to look them up, thus having to approximate them.
Agreed. I don’t mind using exact, but it’s nice when it supports approximates well. The ‘range’ feature was quite unexpected, and did work out well enough to help a couple things. I think I also put a replacement approximation in a tag in the , which I saw someone else do.
All that doesn’t make sense to me though. Why have a format that lets you nitpickingly enter the ingredients, their quantities and their units if they’re not all that important anyway? Free form entry of quantities, e.g. in a simple text field would be much more convenient.
It fits many of the recipes I do have, from others, that aren’t flexible about the ingredients. I’ll need the flexibility on a few, but there’s quite a lot that are reasonably precise — like the ones I’ve been doing. Learning how to say “one egg” is interesting, though.
The only reason I could see for having those measurements and units specified precisely, would be to enable automatic conversions easily. If the size of a tablespoon can vary by a factor of two, say and the measure of a pint by almost 25% between their definitions, conversions become very hard though.
Absolutely. I didn’t know the size of a tablespoon could vary — I thought that exactly three was a 1/4th cup, when measured with a good tablespoon.
I see lots of interesting applications by the way: Say, a recipe needs 500ml of some ingredient. Depending on the user’s preference, a program could convert this into an exact equivalent in pints or liquid ounces or a rough equivalent (e.g. ‘slightly less than a pint’ for UK users or ‘slightly more than a pint’ for US users, or ‘2 cups’ if that’s more appropriate for the kind of ingredient). The same could go for all other conversions and even include conversions from say ‘ca 250g of flour’ in a German recipe into ‘about 2 cups of flour’ in the English version.
That’d be awesome; internationalization xslt translation documents.
In short: I don’t see any need for that kind of precise data entry in the spirit of that quote. But I do see potential niceties you could use them for if they were precise and better defined. Thus I don’t see the point of doing it the way it seems to be done now.
Many of my recipes are precise and defined, and the ones that aren’t will shoehorn into it somehow. It’s a really useful experience for me to learn XML by, and I get the side effect of having a recipe database that’s maintained by little tidbits of code and a lot of translation.
Coming to think of translating recipes. If aiming at a worldwide audience, there should also be a way to specify equivalent items for certain ingredients. E.g. I mentioned vanilla sugar in my recipe. It seems to be a German thing: You buy it in little portion size bags and it’s like white sugar with vanilla taste. In Scandinavia, however, people seem to use a kind of icing sugar with vanilla taste which comes in tubs that last for a while. In England, you’ll get some vanilla essence, a few drops of which will do the trick as well. All of them are alomost the same thing but when reading foreign recipes it’s sometimes a bit tricky to figure out how to do it in local ingredients.
I’ve been using <detail>, maybe an <alternatives> tag would be useful in the future.
Re: the tools. I briefly looked at them (their server is slow, isn’t it?) but they seemed to complicated for me to deal with for the time being. It’s only recipes after all.
Yeah. I’ve fought the complication for a little while, and I’m still not satisfied. On the other hand, it should be possible to XSLT the xslt-generated xhtml back to recipe xml, so i can edit the web page in html and have it translated to data changes. It’s a really interesting thought. I don’t mind fighting raw XML now, though it slows me down.
Absolutely. I didn’t know the size of a tablespoon could vary — I thought that exactly three was a 1/4th cup, when measured with a good tablespoon.
There seem to be two notions of tablespoon: A spoon used for eating and a spoon used for serving potatoes and stuff. The latter tend to be a lot larger. I tend to use the smaller ones which should be about 20 ml I guess. While 1/4th of a cup should be 1/16th of a litre and thus about three times as much.
I’m not sure whether this is a cultural or a measurement issue. Using cup is quite funny as well. It’s a proper measurement unit in English speaking countries and, judging from the conversion given on those I bought, contains 250ml. Giving that measurement without any further details to a German, could result in anything from a small coffee cup (150ml or so) to a coffee mug (350ml, perhaps), making it not very precise.
Yeah. I’ve fought the complication for a little while, and I’m still not satisfied. On the other hand, it should be possible to XSLT the xslt-generated xhtml back to recipe xml, so i can edit the web page in html and have it translated to data changes. It’s a really interesting thought. I don’t mind fighting raw XML now, though it slows me down.
I’m not too much into XML and all that ‘semantic markup’ stuff. The main reason probably is that I don’t need it. Entering information in that kind of over-tagged database way is quite annoying and unnatural. I am not convinced the few advantages of this kind of precision justify the extra effort needed to enter it. I guess I’ll just wait for smarter software that’s capable of interpreting free-form data adequately.
Hi all,
I’m a bit late to the party as I just sort of tumbled across this link looking for something else.
A couple points :
The driving motivation behind EDFG was to be able to store recipes in some sort of abstract, happy-medium (hahaha) format that would be easy to transform it in to a variety of other formats - specifically: text, html and pdf
The second iteration was also designed, from a technical point of view, to move away from any single language implentation (modulo XSLT.) I know lots of people who think that natural language processing is the only practical way to handle parsing things like an ingredients list in a recipe. But that means all that logic has to be implemented in every different widget that wants to use the documents. XML/XSLT is, I think, a pretty good compromise.
You’ll get no argument from me that entering ingredients can be a pain. Medium-term the goal is to write some sort of GUI tool for hiding all that stuff. (You should see the nightmarish dumps that were generated while investigating EDFG+RDF ;-) I think, on measure, that the “stuff” is valuable for the ability to search and/or do measure conversions.
Convesion, conversion, conversion. Your points about U.S. vs. U.K. measurements have been noted.
The Elizabeth David quote was just an acknowledgement that “it’s only recipes after all” :-)
I am eager to do some more work on EDFG but I am trying to disciplined about finishing some other stuff first. Realistically, I won’t get anything done until after the new year. Thoughts, suggestions and patches are welcome.
Cheers,
Aaron: Interesting.
I can of course see your points about how it is necessary to get formally hold of the data in order to process it in helpful ways. And it seems you see my point that entering data in that way isn’t fun.
I’ll be interested to see programs that generate formally structured data from relatively freeform input. In fact, I think this may be one of the big challenges to make computers more useful in the future.
Re Conversions: Most dictionaries have extensive lists of weights and measures.