Frequency of Branch Designators

As the herald of the Crown Province of Østgarðr, I am well aware that it is the only branch in the Society to bear that particular designator — a result of its curious history as the home territory of the earliest royalty of the East Kingdom — and became curious as to what other unusual branch designators were to be found in the catacombs of the Society’s armorial database.

A bit of data extraction produced the following table:

584 Shire (or Schire, Scir)
297 Canton (or Kanton)
187 Barony (or Baronnie)
93 College (or Collegium, Université)
20 Kingdom
20 March (or Marche)
19 Stronghold (or Fortaleza)
11 Province
9 Principality
8 Riding
2 Hamlet
2 Bailiwick
2 Borough
2 Port
1 Barony-Marche
1 Dominion
1 Crown Province

I’ve grouped spelling variations and translations into different languages together.

The most common cases are the standard organizational units of the Society:

  • Kingdoms are the highest level of the hierarchy, with all other branches contained within a kingdom.
  • Principalities are large regions of a kingdom with their own royalty.
  • Shires are independent groups, and the most common type of branch in the Society.
  • Baronies are regions with landed nobility.
  • Cantons are subgroups within a barony.
  • Provinces are equivalent to baronies but do not have landed nobility.
  • Ridings are subgroups within a province.
  • Colleges are groups associated with a university or other educational institution.
  • Strongholds are groups associated with a military base.

The term March seems to be used by groups that are organizationally equivalent to shires or cantons.

Although listed in the Armorial as a Principality, Tir Mara is considered a “Crown Principality,” which is an organizational structure for a group that is on a path towards becoming a Principality, as described in the Cunnan wiki.

I dug a little deeper into the least-common designators to see when they were issued:

  • Crown Province: Østgarðr (1973, but shown as 1984 in the O&A)
  • Barony-Marche: Debatable Lands (1975)
  • Dominion: Myrkfaelinn (1975)
  • Bailiwicks: Ivyeinrust (1981), Broken Bridges (1984)
  • Boroughs: Southe Banke (1981), Duncorlach (1988)
  • Ports: Crickstow-on-Sea (1998), Curragh Mor (1995)
  • Hamlets: Gildenwick (2018), Wildmoor (2018)

Most of these unusual designators are associated with submissions from the East Kingdom, although the Debatable Lands and Myrkfaelinn are now part of Æthelmearc.

The first three date from the era of Alfgar the Sententious’s role as Brigantia Herald (1970–77). All three are still active. Østgarðr and Debatable Lands function as baronies, while Myrkfaelinn is organizationally equivalent to a shire but has a unique schtick.

Both Bailiwicks were organized as cantons, one within the Debatable Lands and the other within Bhakhail. Broken Bridges dissolved within a few years, but Ivyeinrust remains active in and around the University of Pennsylvania.

Boroughs appear to have been initially thought of as an incipient  form for college groups. Neither of these groups is still active. The concept of Boroughs seem to have been an invention of Carolingia.  Subsequent attempts to register the Borough of Haven’s End and the Borough of Felding as branches were returned, although they were allowed to register as households.

Ports are branches associated with ships or naval bases; for example, Curragh Mor was a branch aboard the aircraft carrier USS NimitzCurragh Mor dissolved years ago, and the last visible activity in Crickstow-on-Sea was around 2007.

The only one of these uncommon designators that is in active use for new registrations is “Hamlet,” a term used in Lochac and Drachenwald, first registered in April 2018.

An OSCAR Commentary Checklist

The SCA’s College of Arms processes around three thousand name and armory submissions per year, attempting to ensure that each is properly structured, historically plausible, and unique within the society. A distributed system of commentary allows the burden of this process to be shared among multiple heralds and minimizes the number of things that fall through the cracks.

By commenting on Letters of Intent, first at the kingdom level and then at the Society level, these other heralds help to catch problems, suggest additional resources, and highlight issues that need to be considered during the monthly decision meetings in which the senior-most heralds make the final determinations as to whether submissions will be accepted or returned.

The online system used for commentary is named OSCAR (the Online System for Commentary and Response), which was introduced around 2005 to replace the previous process which involved sending photocopies of submissions and heraldic comments back and forth by postal mail.

Below is a checklist of some of the things I check when reviewing names and armory in OSCAR — it’s not exhaustive, and other people would approach this process slightly differently, but if you’re just beginning to participate in the commentary process, this gives you a possible reference point to start from.

Note that you’re not required to check all of these items for all submissions — in fact, a lot of heralds end up specializing in certain areas, like only focusing on names from a certain language group, or only running conflict checks on armory — so feel free to pick and choose which things you’re going to work on.

And remember, when commenting you don’t have to have authoritative answers for everything — it’s fine to ask questions, or say “I’m not sure, but I wonder if this rule might apply to this case,” or just provide a link or piece of extra information that might make it easier for other people to make the final decision.

Names

Documentation:
  • Scans are included, or sources are on the no-photocopy list (see Admin Handbook Appendix H).
  • If links provided for web resources, they work when they’re clicked and bring up the correct resource.
  • Each name element exists in the referenced documentation…
    … using the submitted spelling exactly as shown…
    … as actual entries not just modern header forms….
    … and are either specifically dated, or the whole source is dated to a specific period.
  • If the documentation seems insufficient, can you find any relevant sources to supplement it?
Construction:
  • Personal name structure matches one listed for this language group (see SENA Appendix A) — or documentation is provided for the name construction.
  • Personal name elements are dated within 500 years of each other and are from a single regional naming group — or are dated within 300 years and are from compatible regional naming groups (see SENA Appendix C).
  • Household names follow a documented pattern (such as one from Alys’s Simple Guide to Household Names).
  • Order names follow a documented pattern (such as one from Alys’s Simple Order Name Checklist).
Conflicts:
  • Search for names using the same elements or variations that could sound similar.
  • Sufficient difference is established through addition or removal of a syllable, or a change in spelling of at least two letters of a syllable (a vowel and a consonant) that causes the sound to be different.
  • If you find some existing registrations that seem to conflict, or are questionable, or very close but probably clear, mention those in a comment.

Armory

Identifiability:
  • When looking at the image, a person familiar with medieval armory would be able to recognize the charges — e.g. the beast looks like a bear or a dog or a lion, not just a generic quadruped.
Charge Groups:
  • No ambiguity between primary and secondary charges (“sword and dagger”)
  • No charge group contains more than two charge types (“slot machine”).
  • All of the charges in a group that could be in the same posture/orientation, are so (“unity of orientation” / “unity of posture”).
  • No charges on tertiaries or overall charges (“excessive stacking”).
  • Overall charges extend well beyond the underlying charges without obscuring them (“barely overall”).
Contrast:
  • Parts of a multiply-divided field or charge have contrast with each other (not required for the common divisions of two or four pieces).
  • Primary and secondary charges have contrast with the field they’re on.
  • Tertiary charges have contrast with the charge they overlay.
  • Overall charges have contrast with the field, and do not share tinctures with the charges they overlay.
  • Contrast here means they’re not both metals, they’re not both colors, and there are no shared tinctures along the boundary where they meet.
Complexity:
  • If you count all of the tinctures, and all of the charge types (ignoring field divisions), the total is not higher than eight.
Blazon:
  • Terms are in standard order: field, primaries, non-peripheral secondaries, tertiaries on those charges, peripheral secondaries, tertiaries on peripherals, overall charges. (See Bruce’s “A Grammar of Blazonry”.)
  • Charge are described with number, type, complex line, posture, arrangement, orientation, tinctures, omitting any that are inapplicable or in their defaults.
  • All of the terms in the blazon are ones we use (use blazon pattern search for words you don’t recognize to see if they’ve been registered since 2012).
Documented Elements:
  • All divisions, complex lines, charge types, animal postures, and charge arrangements have either been registered since 2012, or are supported by documentation as dating to period.
  • No plants, animals, or objects that were only discovered or invented after 1600.
Marshaling:
  • If the field is divided per pale or quarterly, with plain lines, without charges that overlay the lines of division, and with each section plausibly registrable as independent armory, it might look like marshalling, which we don’t register.
Period Style:
  • Charges should fill the available space (or else “feed ‘em some charge chow”).
  • Complex lines should use a limited number of large repeats, not tiny zigzags (bumps should be “big and bold” not like “pinking shears”).
  • Ideally, the symmetry and use of space should match a visual style found in period.
  • Style problems may result in an artist’s note and are not always a cause for return.
Reserved and Restricted Charges:
  • Reserved charges, like crowns, loops of chain, or laurel wreaths, may only be used with appropriate evidence of entitlement. (Glossary Table 2.)
  • No restricted charges of the Red Cross, or traditional national symbols, like a red-and-white Tudor Rose, Chinese Imperial five-toed dragon, or a Papal cross. (Glossary Table 3.)
No Offensive Elements:
  • No prohibited charges like the swastika, flaming cross, or Hand of Glory. (Glossary Table 3.)
  • No depictions of human genitals, overly gory violence, degrading or insulting images.
  • Not excessively modern to the point where it would break the medieval atmosphere.
Conflicts:
  • You can look up the primary charge (or field division, for field-primary armory) in the Ordinary to find everything that could possibly conflict and then check by hand.
  • You can construct a complex search using armorial categories and features found in my.cat, then ignore items scored two points or more below the maximum possible, and check the remainder by hand.
  • You can use Kiho’s blazon parser as a shortcut to constructing a complex search, but make sure you review and understand the search terms it suggests, as sometimes it is mistaken, or needs some additional refinement to produce an efficient search.
  • If you find some existing registrations that seem to conflict, or are questionable, or very close but probably clear, mention those in a comment.

 

An Armory Conflict-Checking Checklist

SENA devotes over 10,000 words to conflict checking armory, which the below guide attempts to summarize.

It includes references to the relevant sections of SENA so you can track down more details if needed.


To conflict-check a new piece of armory, search the armorial database to find a list of all existing registrations which could possibly conflict, then review the new item against each of them in turn.

Work through the list below until you find that they are clear of conflict through at least one Substantial Change (SC) or two Distinct Changes (DCs). 

If you reach the end of the list without finding an SC or two DCs, the items conflict and the new one can not be registered without permission to conflict. (A5H)

First, identify the charge groups in each piece of armory. (A3D)

If one piece of armory has a primary charge and the other doesn’t, that’s an SC. (A5E1)

If there is a primary charge group, any of the following changes to it is an SC:

  • Type of all charges are substantially different? (A5E2)
  • Number of charges is substantially different (1, 2, 3, more than 3)? (A5E3)
  • Arrangement of charges is substantially different? (A5E4)
  • Posture or orientation of charges is substantially different? (A5E5)

If there is no primary charge group, any of the following changes to the field is an SC:

  • One field is divided and the other is undivided? (A5F1a)
  • Direction of lines of division has changed? (Number of lines doesn’t count.) (A5F1b)
  • No tinctures in common? Or for divisions into two, three, or four pieces, each section has changed and each item has at least one tincture the other does not? (A5F2)

For the field, each of the following is a DC — however, if there is a primary charge group, you can only get one DC for the field regardless of how many changes there are:

  • Is either item (or both) fieldless? (A5G1e)
  • Tincture changed for at least half of the field? (But if divided into more than four parts, swapping or rotating tinctures does not grant a DC.) (A5G1a)
  • Direction of line of division has changed? (A5G1b)
  • Style of partition line has changed? (A5G1c)
  • Number of pieces is different (1, 2, 3, 4, more than 4)? (A5G1d)

For each of the charge groups, each of the following is a DC:

  • Entire charge group has been added or removed? (A5G2)
  • Type of charge changed for at least half of the group? (A5G4)
  • Tincture changed for at least half of the group? (A5G3a)
  • Addition of division line, or change in direction, style, or number of pieces (1, 2, 3, 4, more than 4)? (A5G3b, A5G3c, A5G3d)
  • Number of charges is different (1, 2, 3, 4, 5, more than 5)? (A5G5)
  • Arrangement of charges in the group is different (and it wasn’t forced by contrast rules)? (A5G6)
  • Posture or orientation of the charges is different? (A5G7)

This checklist is also available as a PDF file or as a high-resolution PNG.

See also: A more-detailed guide that includes visual examples of each of these types of checks is found in Master Modar’s 2015 conflict-checking guide on Calontir’s heraldry site.

Artistic Variation in Heraldic Art

A notable characteristic of armorial depiction is that any illustration of a given design is considered to be heraldically equivalent. For example, any illustration of “Gules, three lions passant guardant in pale Or” is said to represent the English Sovereign, no matter in what style the lions are drawn, as long as they accurately reflect that blazon.

Konstantia Kaloethina has assembled a nice demonstration of this principle in her “Heraldic Mythbusting” blog post containing nine different illustrations of “a seraph proper” by six different artists.

Two seraphs proper; the first by myself using an illustration by Vinycomb, the second by Konstantia Kaloethina. (Shared with permission.)

In addition to these illustrations, the post provides some period examples of “artistic license,” explains some boundaries on when it’s taken too far, and discusses the Society’s heraldic registration policies — it’s definitely worth a read.

What Does Morsulus Herald Do?

Notes from a session with Herveus d’Ormonde at the Known World Heralds and Scribal Symposium, June 9, 2018.

Who serves as Morsulus Herald?

Herveus d’Ormonde has held this position since Apr 2000.

His predecessors in the role were:

  • Master Renfield Wanderscribe (1980–1985) created first society armorial and ordinary.
  • Alban St. Albans (Jul 1985–) and Ianthus (sp?) set up a searchable database.
  • Iulstan Sigewealding (early 90s– Mar 2000) wrote most of the current codebase.

What is the job of the Morsulus Herald?

The primary task of the Morsulus Herald is maintaining the database of heraldic registrations, including indexing new entries, making corrections, and maintaining the software that powers the oanda.sca.org web interface.

Also responsible for publishing the LoARs to the heraldry.sca.org/loar web site, which  only takes a few minutes each month. When the LoAR is published, Morsulus downloads these in HTML format and uploads them to the web site.

Where does the master database and code live?

All of the data processing happens on Herveus’s local workstation, a Mac laptop. This machine is archived on a external backup device in the same location.

The code is written in Perl and run from the command line. There are multiple scripts which perform different parts of the process. Morsulus has a text file that shows examples of the various script invocations required and works through each of the steps as required every month, figuring out which commands need to be run and making minor changes to the file names or options as needed.

The code is tracked in Git, and exposed to the public at github.com/herveus, although the GitHub version lags somewhat behind the current working version used by Herveus.

The master database is maintained in a SQLite database file. The headings used internally correspond to the ones in the mike.cat file described below.

How is the database updated for new LoARs?

Every month, the Laurel team sends Morsulus a batch of XML files corresponding to the new LoAR. Actually, this happens three times, the first two times corresponding to the two proof passes, and then with the final version. The XML files are generated by OSCAR, but then undergo manual revision during the editing process. If problems with the XML files interfere with processing the data, Morsulus reports this to the Laurel team which makes corrections in the next pass.

A Perl script converts the XML file to a delimited-text “action” file which includes all of the changes for each name or armory as a single line.

Another Perl script applies those actions to the master database, after doing some logical consistency checks — eg, confirming that you don’t add armory without a name, that you don’t add two pieces of armory with identical blazons, that you can’t do a name change unless the old name is already registered, etc.

Lines in the action file which can’t be successfully applied to the database are flagged as errors, and Morsulus comments them out and hand-writes a revised version of the line called a “temporary edit” which can be applied, and notifies Laurel about the issue so it can be fixed in the next revision of the XML.

Then Morsulus runs a program in which he can perform the indexing of armorial headings and features for each blazon. This is a Perl TK app which runs in the X11 environment. It has a point-and-click interface that allows you to add multiple armorial descriptions for each blazon, picking from lists of headings and features. The descriptions are then copied to the local batch and the master database, indexed by blazon. Because the descriptions are indexed by blazon, this process can be done when the first proof pass is received, and does not need to be repeated for the next two passes except for any items whose blazons are changed during editing.

In the course of processing a month’s batch, Morsulus may need to add items to the category file. It’s fairly common to add new category cross-references (eg, “bay leaf – see leaf”) and less common to add a new category with a heading (eg “manacle|MANACLE”). When this happens, related changes must be made to several files in parallel.

  • The my.cat file is exposed to the public and corresponds to values visible in the oanda.db.
  • There is a separate mike.cat file which is used for indexing and which contains some additional headings and in some places uses different heading names. The mike.cat file also includes a list of which feature sets are applied to a given heading.
  • There is a tprint.cat file which lists all of the categories in the order they should be listed to the public. (They used to be sorted alphabetically by heading, which is why some of the heading names are strange.) It also specifies which categories to break down into smaller sections by tincture, number, or group; this is used to generate the web ordinary interface as well as the print ordinary.

Then Morsulus runs a consistency-check script that scans the SQLite database and summarizes various kinds of totals, and compare the output to a copy saved from the previous month, to see what’s changed and confirm that the number of changes match the expectation based on the number of items in the LoAR.

A Perl script exports a copy of the database from SQLite to a flat file format called “classic format.” This includes converting some internal headings from mike.cat to the public equivalents used in my.cat; for example, “BIRD-PELICAN” gets exported as “BIRD:pelican.” These changes cause the exported file to line up with the combined categories used for the ordinary display and for the complex search form.

A set of “DB Diffs” are created that compare the new oanda.db file with the one that was generated last month. This simplifies the process of loading new data into another search tool built by another developer, as they only have to import the changes rather than the entire file. (I am not sure which of the other search tools use this, but I think it’s Hirsch von Henford’s Golden Stag app.)

The updated my.cat and oanda.db are then uploaded to the oanda server and the search daemon is restarted so that it will re-index the file; this only takes a couple of seconds.

How is the database accessed by others?

Most people use the oanda web site. Among other things, log files show that some local kingdom OP sites crawl the oanda web site to automatically collect armorial blazons for people in their region.

You can get a copy of the software needed to run the oanda web site by downloading and running the config.web script, which unpacks a copy of the Morsulus-search package.

Some folks, especially in the West Kingdom, are heavily invested in using a “print” version of the ordinary for lookups and conflict checks. Rather than actually being printed on paper, this is a set of documents accessible from oanda.gigo.com which are built from the oanda.db in formats such as epub and PDF using some third-party software. That process uses a file named templ.cat which is similar to my.cat but has print-specific notes such as “do not print” added to some categories.

(There was an old print version which was built by Morsulus using some custom C code which used the database to generate PostScript, but the last time this was used was for Pennsic 2011 and it has now been retired.)

(Although not discussed in detail during this meeting, there are also a couple of other search tools which can import the oanda.db file, including two Windows apps and a Lotus Notes interface.)

How are errors corrected?

People write in to Morsulus when they notice a problem with an armorial listing.

Morsulus checks the reports against the original LoARs and against an archive of scans of the original registration files to figure out at what stage of the process the error appeared.

In some cases the error originates in the LoAR; for those, people need to go through an LoAR errata process, get Laurel signoff, and then the correction is processed as part of the corresponding LoAR update.

In other cases the problem is due to a transcription error, in which the LoAR entry was garbled when it was transferred to the database or the indexing of categories and features was done incorrectly. In those cases Morsulus can simply correct the problem to accurately reflect the LoAR and push that change out in the next update cycle.

Those changes are made via a command-line tool that can search and edit the SQLite master database. This has various internal-use-only functions like looking up records by regid (a synthetic primary key) and directly editing raw database fields.

What are some random factoids about the database?

The database contains approximately 110K registrations. It takes up 120 MB in SQLite with the various indexes, but the flat-file version is only 16 MB.

There are a few cases of where there are two name registrations for the same name.

Jointly owned items have a primary name that they’re attached to, plus a second entry that just references that they’re a co-owner.

Armory Conflict-Checking Resources

One of the seemingly-black arts of Society heraldic practice is checking new device and badge designs for conflicts against registered armory.

I’ve been doing this for a couple of years now and still need to ask for help or get other heralds to double-check my work, so I thought it might be useful to post a few links to some of the resources I use to try and remind myself of how the process works.

The Rules

The rules for armory conflict are laid out in SENA section A5.

A succinct summary of those rules is provided in the SENA Submissions Checklist (which also includes a number of other useful guidelines for all types of submissions).

Visual Examples

Reading those rules can be a bit daunting for a newcomer.

A useful guide that includes numerous visible examples is Master Modar’s Basic Conflict Checking supplement to the Calontiri Herald’s Handbook.

Another presentation of the rules with good visual references is provided in Yehuda’s Armory 103 presentation and accompanying hour-long class video.

Using the Complex Search Form

Modern conflict checking is nearly always done using the armorial’s complex search form.

A good reference for using the complex search form is Marie de Blois’s Conflict Checking with the Complex Search Form. There’s an accompanying hour-long class video.

Use of the complex search form is also covered in Yehuda’s Armory 201 presentation and accompanying hour-long class video.

An Overview of the Heraldic Submission Process

People seeking to register a name or armory with the SCA’s College of Arms are often baffled by the length of time the process takes and the inscrutable jargon used to describe the various stages.

There have been numerous attempts to provide an overview of this process, to which I have now added my own contribution below.

Some of the terminology here reflects current usage in the East Kingdom; in other places the ILoI may be called an LoP, the LoD may be called an LoR or ILoAR, and the LoI may be called an ELoI or KLoI.

Likewise the timelines maybe slightly different in other kingdoms, as each kingdom’s commentary process is run on its own calendar. (And few kingdoms have the same backlog of submissions after Pennsic to cause slower processing in the fall months.)

This diagram is also available as a printable PDF.

Heraldic Tincture Hexcodes

Any set of colors can be used as heraldic tinctures if they can be interpreted easily and unambiguously.

Below are examples of color palettes I’ve used for pieces of armory. (Click for a larger image, or download a printable PDF with additional examples.)

The only one of these that’s special is the set of colors used for OSCAR’s color correction; when submitting images, it make things easier if colors are close enough to these that they’re not transformed incorrectly.

When armory images are uploaded to OSCAR, color-corrected thumbnails are generated which convert each area of color to one of the nine standard tinctures shown in dashed circles below. Solid outlines delimit the range of colors that are converted to each of those targets.

(Click for a larger image, or download a printable PDF.)

While the color-correction process usually goes smoothly, there are a few things to watch out for:

  • Warm golds (containing more red than green) can end up being rendered as orange or brown.
  • Warm browns can develop streaks or splotches of red.
  • Blues and purples can become ambiguous if either of them comes too close to the violet boundary.
  • Although not apparent on this chart, fine-line details like black outlines around an argent charge in a fieldless badge can disappear entirely.

Many thanks to Elena Wyth for the experimentation which allowed these OSCAR ranges to be estimated.

The Submission Escutcheon

A recent question on a society heraldry Facebook group about the dimensions of the escutcheon on the submission forms reminded me that I never posted the comparison outline I put together last year showing how it diverges from the geometric construction typically used to create this “heater shield” shape.

The most common technique for drawing a heraldic escutcheon, shown in red below, is to lay out a rectangle which is three times as wide as it is tall, then add a pair of quarter circles below it, enclosing the area where they overlap.

The escutcheon on the society’s submission forms, shown in black below, is slightly different; the curve starts lower and then pinches in more steeply.

I don’t know if there’s a concrete reason these curves are different; it may have been an accident, or an aesthetic judgement by the illustrator, or perhaps there’s some other explanation that’s been lost in the mists of time.

The difference is relatively small, but it’s enough to bite you if you use a computer to create field divisions or peripheral ordinaries or the like. Submissions which do not use the precise escutcheon shape from the form are likely to be rejected.

I haven’t found a geometric construction that precisely matches the submission form, but I’ve very carefully traced the outline from the form so that I can create heraldic clip art that matches it.

For the curious, the whitespace inside the escutcheon is a couple of hundredths of an inch over 5″ wide, and a couple of hundredths of an inch less than 6″ tall. After adding a two-point outline (2/72″) around the edge, the solid black outline is 5.06″ x 6.06″.

The diagram above is available as a PDF; you’re welcome to print it out and hold it up behind a copy of the submission form to confirm that the outlines match up precisely.

Folks who are creating digital submissions might be able to save some time by reusing the outline I’ve traced, either with the alignment tick marks (SVG vector, 300 DPI PNG) or without them (SVG vector, 300 DPI PNG).