Cooks Guild Database

Effort: Not Estimated
Target Users: Carolingian Cooks' Guild
I want this one a lot -- the existing DB works, but is a PITA to use. Have sent a note to the Cooks' list, asking whether folks are okay with me doing this.

Design Outline

Models

Recipe

Recipe is the primary Model in this Space, although most of the guts exist in other Models. A Recipe is one specific recipe from a Primary Source. It contains:
  • Name -- Standard Property -- the commonly-used name of this Recipe, from the primary source (usually translated into English?). Names do not need to be unique.
  • Alternate Names -- List of Text -- any number of other names for this Recipe, typically the original language. Names do not need to be unique.
  • Primary Source -- Exactly One Link to Source -- the original period Source of this Recipe. A Recipe always comes from exactly one Source, but note that a Reconstruction can be based on multiple Recipes.
  • Primary Index Location -- Optional Text -- the page number and/or Recipe number of this Recipe in the Primary Source.
  • Recipe Text -- Optional Large Text -- the actual text of the Recipe and/or a translation, if copyright permits.
  • Primary Ingredients -- Set of Tag of Ingredient -- the major Ingredients in this recipe, if applicable. This shouldn't be everything, but a lamb stew would say Lamb, or an omelet would say Eggs -- basically, the Ingredients that this dish is mainly about. This is so that a cook can easily look for "Lamb dishes".
  • Notes -- Optional Large Text -- any miscellaneous notes about this Recipe.
  • Similar Recipes -- Set of Link to Recipe -- links to other Recipes that seem to be the same dish or very similar ones.
  • Categories -- Set of Tag of Category -- the kind(s) of dish this is, such as "Soup" or "Pie".
Note that a single Recipe can have any number of Reconstructions, and a Reconstruction can be based on any number of Recipes.

Reconstruction

A Reconstruction is the work of one or more Guildmembers, to figure out how a Recipe would have been made. A Reconstruction may be synthesized from multiple similar Recipes, or may in rare cases be based on no specific Recipe at all. (Eg, Bread.) It contains:
  • Name -- Standard Property -- the name we're using for this Reconstruction. This is often based on the Name of the original Recipe, but doesn't have to be -- it may often be more mnemonic.
  • Based on Recipes -- Set of Link to Recipe -- the original Recipe(s) this Reconstruction comes from.
  • Sources -- List of Composites of Source and Text -- pointers to the specific Source(s) (typically secondary) used in preparing this Reconstruction, along with, eg, page/line numbers.
  • Reconstructors -- Set of Tag of Guildmember -- who worked on this Reconstruction.
  • Date Reconstructed -- Date -- when this Reconstruction was prepared.
  • Ingredients -- List of Composites of Quantity and Tag of Ingredient -- all of the Ingredients in this Reconstruction, and how much of each one. For the moment, Quantity is necessarily a simple text field; in the long run, it should become Convertible Units, but that's probably at least a year or two away.
  • Steps -- List of Composite of Large Text and Photos -- how to prepare this dish. This is being done as a List so that you can attach, eg, Photos to an individual Step. (To Do: there is currently a bug preventing us from putting Photos in a Step.)
  • Photos -- List of Photo -- pictures taken of the dish, in preparation and finished.
  • Notes -- Optional Large Text -- any miscellaneous notes about this Reconstruction.
  • Reviews -- Standard Property -- allows members to give their own opinions about the Reconstruction, including 1-5 star Ratings. Once Querki has Moderation, we might allow non-members to give Reviews.

Source

A Source represents a book, manuscript, or such. Both primary and secondary sources are grouped together in this Model, since the distinctions between them can be subtle. Source contains:
  • Name -- Standard Property -- the commonly-used name of this Source, however we typically refer to it. Uniqueness is not enforced, but preferable.
  • Alternate Names -- List of Text -- other names for this Source.
  • Contents -- Set of Link to Source Contents -- what sorts of things are in this Source (which implies whether it is primary or secondary)
  • Publication Date -- Text -- typically approximate in case of primary sources.
  • Websites -- List of External Link -- sites that are relevant to this Source: transcriptions, facsimiles, reconstructions, etc.
  • Notes -- Optional Large Text -- freeform discussion of this Source.
  • Based On -- Set of Link to Source -- other Sources that this one is adapted from, typically secondary linking to primaries.
  • Time Periods -- Set of Tag of Time Period -- the time period(s) relevant to this Source (eg, "15th century").
  • Cultures -- Set of Tag of Culture -- the culture(s) relevant to this Source (eg, "French", "Arabic"). We should curate these tags carefully.

Guildmember

This represents a person who has done reconstructions with the Cooks' Guild, either currently or in the past. It contains:
  • Name -- Standard Property -- usually the SCA name of this person.
  • Sources -- Set of Tag of Source -- the sources they own or have ready access to (if the Guildmember chooses to make that list public) so that others know who to talk to if they need one.
  • Notes -- Optional Large Text -- other miscellaneous notes about this person: expertise, alternate personae, where they are currently living if not Carolingia, etc.

Time Period

This is simply a Model to hook the Time Periods Tag on. Expected values are along the lines of "10th century", "Classical", "16th century".

Culture

This is simply a Model to hook the Cultures Tag on. Expected values are along the lines of "Roman", "Italian", "Elizabethan".

Ingredient

This is mainly a Model to hang the Ingredients Tags on -- "Lamb", "Eggs", "Garum", "White Pepper", etc.

Category

This is simply a Model to hang the Categories on. Expected values are along the lines of, "Soup", "Stew", "Pie", etc. We will need to curate this set carefully.

Source Contents

This defines what can go into a Source. This list should probably be more or less fixed, not dynamic like most Tags. Offhand, this includes:
  • Primary Recipes -- this Primary Source contains a substantial number of recipes
  • Primary Cooking -- this Primary Source contains a good deal of cooking technique, philosophy and discussion\
  • Facsimiles -- this Secondary Source contains facsimiles of primary source material
  • Transcriptions -- this Secondary Source contains transcriptions of primary source material
  • Translations -- this Secondary Source contains translations/modernizations of primary source material
  • Reconstructions -- this Secondary Source contains reconstructions of period recipes
  • Analysis -- this Secondary Source contains a significant amount of analysis of period cooking
  • History -- this Secondary Source contains a good deal of history, such as the history of the primary source(s)
This list is not exclusive -- we can add to it if we find additional categories we want to use.

Pages

Besides the below pages, note that clicking on any Tag will display all things that use that Tag. (This is a built-in feature of Querki, and is why Tags are so nice.)
As is standard in Querki, all Pages can have Conversations, so members can talk about a given Recipe or Source freely.

Home Page

This should display summaries of the most recent Reconstructions (say, the first ten), and have links to get to everything else.

Guild Info

We should have a page to talk about the Guild -- what we do, when we meet, and so on.

All Recipes

This should be a list of all the Recipes in the database, initially sorted in reverse chronological order of the reconstruction date.
The plan is that this should become highly dynamic. There should eventually be controls to filter on any of the major fields of a Recipe or Reconstruction, and to sort on various fields. This will become the easy way to find what you're looking for.

Source

The page for any given Source should show all of the information directly on that Source. If it is a primary Source, it should show all the secondary Sources based on it. It should display all Recipes and Reconstructions based on it.

Ingredient

For each Ingredient, it should be easy to see which Recipes use that as a primary Ingredient. We might occasionally also want to see all Reconstructions that use an Ingredient, but that's likely less useful.

Interview Notes

From an email thread on the Cooks' list. My responses are italicized.
Initial comments from me:
The primary Model here is Recipe. That seems intuitively obvious: this Space is all about recipes, after all. But I think that Reconstruction is probably separate -- one Recipe can have multiple Reconstructions, by different people on different dates with different results.
A Source is a book or manuscript, and includes:
  • The Name,
  • A Date (usually approximate in the case of primary sources),
  • One or more links to websites, and
  • Notes.
    A secondary Source should be able to point to one or more primary Sources that it is adapted from. A primary Source should have tags for Time Period (eg, "10th century", "15th century") and Culture (eg, "Roman", "Arabic", "French"). Note that the line between "primary" and "secondary" is very fuzzy, given that we have lots of facsimiles, transliterations, translations and adaptations; therefore, we probably shouldn't get too attached to the distinction.
A Guildmember is a person, with an SCA Name, and maybe a list of Sources that they own. Maybe a field for general Notes? (Eg, "Marian is the big expert on Bread", "Caterina is well-versed in German cooking".) From a Guildmember's page, you should be able to see the Reconstructions they've done.
A Recipe corresponds to an actual, specific historical recipe that we've got from some source somewhere. It should have a Name. It should include a link to a primary Source, and usually one or more secondary Sources (typically translations), with page/recipe numbers in those books. There should be a big field to enter the text of the original recipe. (Modulo copyright considerations, which we should think about.) Maybe tags for Primary Ingredients? Maybe general Notes? A Recipe usually has one or more Reconstructions.
A Reconstruction has:
  • A Date,
  • One or more Guildmembers who worked on the Reconstruction,
  • A list of Ingredients,
  • A big text field for Steps (how to cook this -- anybody got a better name?),
  • Notes
  • Photos
You should be able to easily find:
  • Recipes from a given Source
  • Reconstructions by a particular Guildmember
  • Recipes from a given Time Period or Culture
  • Recipes involving a given Primary Ingredient As well as general Search capabilities.
Sephareh:
I think a search for similar recipes would be cool-- ones with (for example) three of the same main ingredients. Because we've come across very similar foods in different sources/cultures/times, it would be interesting to see what people across time did with (for example), apples, butter and sugar.
Hmm. That may be a bit of a long-term feature (going to have to think about how to implement it as an automatic thing), but would folks like a starting point of an optional manually-maintained "similar recipes" list? That is, if I've done one recipe for Snowballs, and I know we have three others already there, I can link to them for easy reference?
Also, a way to categorize stuff into broad categories would help-- for example, pies vs stews vs. soups. (those those last two may overlap).
Oh, right -- yes, you're absolutely correct. We should talk about what categories we want to encourage, from a curation POV.
Any of this seem doable?
For reference: requiring the system to figure out "similar recipes" automatically isn't in scope yet, but it's good to get ideas like that on the table for later. The manual linking to similar recipes, and categorization, are both trivially easy. (Indeed, categorization is one of the things Querki is best at -- Tags are a first-class type, and we can have as many different kinds of Tags as we want.)
Orlando:
From my work on music sources, I would suggest that you be more specific on sources. If someone knows that their source was a translation-by-such-and-such of a particular MS, then give them a place to note that -- when you run into an interesting situation, like an instruction that doesn't fit well, or a recipe that closely parallels another but with key differences, being able to retrace the steps can be valuable. Having a place to be formal about what the source is can inspire the writer to take an extra moment to be extra clear, which can save a good deal more time when someone else is using the work later.
Hmm. Good point -- how about a link from Reconstruction to Source, with the connotation that this is where you give the specific secondary source you were working from on this Reconstruction?
For Sepherah's ideas: I'd envision the first as 'search for +apple +butter +sugar', and the second as a tag system. But could be even better to say 'search in ingredients for ...'. Search could be refined considerably, though possibly difficult to code for, I could easily see someone saying "I want to find a recipe tagged as a stew, using lamb, from a French source". How's Quirki at handling stuff like that?
As I just replied to her, the tagging thing is trivial.
Search per se in Querki is fairly primitive for the moment -- it's ubiquitous, but for it's a simple string search. Something like +apple +butter +sugar is probably in the cards, but a ways down the road.
But what you're talking about here isn't really Search, it's ad hoc Query. That does already exist -- it's totally possible to do exactly what you're describing -- but there's no UI for it yet, it's essentially writing a short QL query. (QL isn't precisely a cognate to SQL -- it's a slightly more general-purpose programming language -- but for purposes of this discussion it's conceptually similar.)
So at the moment, you'd have to go into Querki Explorer and work up (interactively, but without, eg, IDE-style prompts) an expression along the lines of:
Recipe.instances -> _filter(Categories.contains(Stew)) -> filter(Ingredients.contains(Lamb)) -> filter(Culture.contains(French))
That works, but it'll be awkward for the time being.
There has long (2+ years) been a design for an all-encompassing wizard to write this stuff, but that's a ways out. But this might be a use case for a simpler mechanism that I've been contemplating for a while -- basically, an automatic UI that presents you with all of the Tag/Link fields on a given Model, and lets you easily filter on any of them through simple drop-down menus. That won't be available in the first pass, but I'll add it as a desireable enhancement for this Use Case...
Zohane:
These seem like good design points. The only thing I would want to add, offhand, is the ability to add alternate names for a recipe - a lot of the actual names are charming but very unhelpful if you are looking for something by our modern terminology, e.g. "A Dish for Ruffians and Harlots" which you would never find by searching for omelets unless we can tag it with other names.
Makes sense -- I'll add that to the list...

Open Stories

Required:
Helpful:

Completed Stories

All Use Cases