Please ✉️ mail or 📞 call to discuss your requirements. Please ✉️ mail or 📞 call to discuss your requirements.
This page is a placeholder. The ℞ system is new and the code and documentation are still being written.
Introduction
℞ is short for the Latin word recīpe, pronounced ‘reh-see-pay’ or ‘reh-thee-pay’ or ‘reh-chee-pay’ depending on your culture. It means ‘take’ or ‘receive’, and it’s how doctors’ prescriptions used to begin, when they were handwritten. It instructed the pharmacist what ingredients to take and how to mix them for your medicine. Old recipe books used to start each recipe with the same symbol, and old pharmacy counter-books often contained recipes for food done the same way. Cookery recipes used to be known as ‘receipts’.
Figure 1: A prescription hand-written on 8th July 1970.
It’s become all too obvious over the years that publishers can no longer afford proof-readers or copy-editors. Nor can authors, certainly not on the percentages that publishers pay; and least of all cookery authors, who need to have every recipe tested many times, meaning there are constantly different versions floating around. Even if they do all the testing themselves, mistakes are bound to creep in.
℞ aims to help fix some of the usual suspects. These are common errors or problems that have been noted many times by cookery writers and editors (Flynn, 2020):
ingredients listed but never mentioned (eg “What am I supposed to do with this 50 g of butter left over?”);
ingredients mentioned but not listed (eg “Sugar? What sugar? Nobody said anything about sugar !”);
ingredients listed out of order, or not in any order;
ingredients listed under one name but referred to by another;
ingredients not named consistently between recipes in a collection;
ingredients that can’t be indexed, searched, or categorised.
℞ can’t fix human problems. If you write that you need to “beat the eggs and sugar vigorously” when what you meant was to “stir the eggs and sugar gently”, no amount of software is going to correct you. Recipes need to be free of human errors before you publish them.
℞ is an XML system. That means the recipe has to be expressed in XML. If you’re going to be publishing it, it’s probably in XML already.
Each ingredient is specified with an xml:id to identify it (you can make these up), and a particular set of attributes to store the information, broken down into its component parts, eg
<ingredient quantity="220" units="g" dairy="butter" xml:id="butter"/>
<ingredient quantity="2" units="cloves" size="butter" vegetable="garlic"
treatment="crushed" xml:id="garlic"/>
<ingredient quantity="1.5" units="cups" meat="bacon" quality="diced"
xml:id="ham" comment="lardons"/>
Each time an ingredient is mentioned in the Method it uses the xml:id to refer to it.
Fry the <ing i="butter garlic ham"/> gently for five minutes
and it formats the instructions using the names of the ingredients you supplied
Fry the butter, garlic, and bacon gently for five minutes.
Don’t worry if this is all ελληνικά to you, your tech person will know what it means.
Because using XML is a standards-conformant approach, ℞ can be set up in any XML software on any system to be as raw or as sophisticated as you or your authors or editors need. Only the ingredient and reference elements need to be set up, so it can work inside your existing XML publishing system.
The software is written in XSLT3 and runs with any XSLT3 processor (eg Saxon). It’s currently alpha (α) status, which means most of it works, but some of it is still being developed, using http://xml.silmaril.ie/recipes/ as pilot examples. A useful side-effect of using the disaggregated data is that the XML files can be used directly as the print version of each recipe, styling them with CSS (additional formats could of course be written to do this differently).
that each ingredient gets used in the Method (or at least mentioned); and that all ingredients mentioned in the Method are in the List of Ingredients.
in standard recipe wording from the disaggregated data in the attributes, so recipes are consistently formatted exactly as normal, eg (from the examples above):
220 g butter
2 fat cloves garlic, crushed
1½ cups diced bacon (lardons)
because it uses the standard XML ID/IDREFS cross-reference feature to refer to each ingredient instead of the author or editor having to retype the name of each item by hand.
because it formats the actual names of the ingredients regardless of the xml:ids you give them.
of the items in the List of Ingredients, that they match the order in which the ingredients are mentioned in the Method.
, so if you are making a recipes website or publishing a book, your readers can search reliably, in the knowledge that everything there is listed, and nothing is listed that isn't there; it can also be used to generate shopping lists or grocery-site lookups.
because it is consistent in storing the details of each ingredient (quantity, units, size, name, etc). If you have access to such a database, this lets you get the calories, fats, sugars, carbohydrates, fibre, allergens, and other data for labelling, hygiene, legal, and food security requirements.
A detailed paper describing the system (Flynn, 2020) was presented at the Balisage conference in the summer of 2020.
Current status:
natural language generation algorithm is now stable, both in XSLT and CSS, but is being tweaked as new foodstuffs are added;
nonce CSS is now generated to handle underscores in IDs, used to add flexibility when one foodstuff occurs several times;
new recipes are being added, and more are sought (subject to copyright agreement);
Development is ongoing:
the token lists of foodstuffs are being expanded as new recipes are added to the pilot site;
discussions are under way with recipe editors on the categories of foodstuffs;
exception handling in the natural language formatting is being examined with linguists;
an experimental method is being tested for dealing with multiple lists of ingredients and multiple methods in a single recipe (eg ‘Ragù’, ‘Béchamel’, and ‘Lasagne’);
definition has started on the parameter requirements for an adaptive quantity/unit conversion method which will also handle cultural ingredient naming differences.
Peter Flynn, 1 March 2021