Order of Precedence Schema

[jducoeur]

Some time ago, msmemory and I sat down and hashed out a tentative schema for an Order of Precedence database, designed to reflect all of the information she is currently tracking by hand. I've been busy enough on CommYou and other projects that I haven't managed to code the thing up yet (the difficulty of having a thousand interesting projects on tap at any given time), but I don't want to lose track of it. And since the cats keep knocking over the whiteboard, I'd better transcribe it before they manage to erase it completely.

So the following are our notes on the OP schema. It's a bit informal, but should be good enough to get the point across. It's described in terms of data type; these might or might not all actually wind up DB tables, but they're the conceptual objects and relationships we need to track. (In particular, when I say "Enumeration" below, it means a relatively finite list, but they might be represented as either real enumerations or small tables.) Note that most pointers may be null -- the sad reality is that information is often incomplete. It's by no means final, but it's mostly right.

This is potentially interesting to programming or heraldry/OP geeks, and probably not to anyone else.

In no particular order (well, in the order they wound up in the white board sketch):

Crowned Head
Type: Crown Type
Name: SCA Name
Group: Group

Crown Type
Enumeration -- King, Baron, Prince, etc.

Group
Name: String
Type: Group Type
Contained By: Group

Group Type
Enumeration -- Kingdom, Barony, Shire, etc.

SCA Name
Name: String
Person: Person
IsRegistered: Boolean
Gender/Type: Gender/Type

Gender/Type
Enumeration: Unknown, Male, Female, Collective

Person
Primary Name: SCA Name
Resides In: Group
Current Mundane Name: Mundane Name
Registered Arms: String
Is Collective: Boolean
Is Living: Boolean

Mundane Name
Name: String
Person: Person
Gender/Type: Gender/Type

Award Level
Enumeration: Peerage, Upper Kingdom, Lower Kingdom, etc.

Award
Name: String ("Laurel", "Crescent", "AoA", etc)
Group: Group
Level: Award Level

Court
Crown 1, Crown 2: Crowned Head
Date: Date
Name of Court: String (optional, eg, "First Court of TRM")
Event: Event
Sequence: Integer (eg, first, second, third court of the event)

Event
Name: String
Hosting Group: Group

Bestowal
Court: Court
Recipient: SCA Name
Award: Award
Sequence: Integer
Data Source: Data Source (where we got the info from)
As Part Of: SCA Name (collective)

Data Source
Enumeration -- Court Report, Heard from Recipient, Other Kingdom OP, etc

Comments

[msmemory.livejournal.com]

You still need some name under which to centralize each person's stuff. I could see an argument for using the SCA name, but I think it makes more work. Some people change their names several times, and I often see lots of spellings even of one correct name. I could imagine over the course of several years seeing Typheinne de la Croix, Typhenne de la Croix, Typheinne dela Cross, Typheinne de Northshield, etc.

[eclecticmagpie.livejournal.com]

The mundane name is a useful way to do this -- though not completely watertight (SSN would be better for most people), but it doesn't need to be _visible,_ which seems to be Aurelia's complaint.

[msmemory.livejournal.com]

Mundane name is not going to be visible to the average user. It's part of the under-the-hood records only (as is gender).

[tpau]

can you at least make persona gender availible? us scribes needs it...

[jducoeur]

Hmm. That's up to msmemory, but keep in mind that it's one of the fields that probably isn't going to get populated very often, because we usually don't have anything more than the name to go on. And remember that this won't happen until *after* the award, so at best it'll only be available for higher-level secondary awards, not for AoAs.

So even if she decides to make it public, it's not going to be useful to you very often...

[dagonell.livejournal.com]

How do you handle the case of the mundane name changing? Ghod knows, I've seen enough cases where Miss Jane Doe who is Lady Jane of Herplacename marries Mr John Smith who is Lord John of Hisplacename and not becomes Mrs Jane Smith, but also Lady Jane of Hisplacename.
-- Dagonell

[jducoeur]

Note that Mundane Name is a separate table that points to Person, and "Current Mundane Name" is a pointer from Person to Mundane Name. That reflects exactly this point -- there may be multiple Mundane Names, of which one is thought of as "currently best".

Not that we usually have that much data (as previously mentioned, we typically *don't* have the mundane name, much less two of them), but the structure can cope with it if we do...