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

[rufinia.livejournal.com]

Out of curiousity, why do you think the "mundane name" is necessary?

[tpau]

when you start working on this, can i help?

[baavgai.livejournal.com]

I'm unclear of the meaning of "Crown 1, Crown 2" in Court. I would think that would warrant two separate records?

For residence, I'd recommend making a separated entity for (Date, Person, Residence) so that you can be historical about it. e.g. "is that the same Erik that used to be in..."

Event probably also wants a date, if not more.

Also, a quirk of the SCA. You'll probably want gender on both the Person and the "SCA Name" entity. You may also want a time stamp on SCA Name, because people change...

Dates, Bestowal to Branches, and Groups or Branches

[peregrinning.livejournal.com]

I'm having a hard time understanding the relationship of this database to the calendar. I don't see date fields where I expect them. I think you're focusing all date information at the "court" data type, which makes some sense. "Event" feels slim without dates or recurrence number (i.e. GNEW LXVII)... I think name of court should at least be created from the data in the court data type (i.e. "#th Court of Crown1 and Crown2 at Event on Date") so that you have something to select from for the bestowal data type, and something to list in the output.

I would also want dates for the founding/creation/elevation/retirement of SCA branches as well, though you may see that as part of the bestowal concept. Since this is focused on court reports, a way to connect that sort of court business is probably in your mind already. I think it would mean that "recipient" might be the name of an SCA branch.

I use "SCA branch," probably because my work as a cartographer forced me into a too-close reading of the Midrealm Seneschal's handbook. :-) "SCA Branch" helps to separate the standard branch types (Barony, Shire, Canton, etc.) from the many other groups in the SCA (Guilds, Households, etc.). I have no idea if that usage is widespread.

[goldsquare.livejournal.com]

I can see a lot of other fields to play with. For example:

Joe gets a Laurel in the East, moves to the Midrealm... how is that recorded? Comes back to the East, resigns. Or is banished. Do you want to record each of those, somehow?

I haven't gone through the entire data structure like that. Would it help?

[siderea]

Radical thought: why have separate SCA and Mundane name tables? Why not have a name table, with a bit for SCA vs Mundane? That way, when you're looking for someone, you can search one table w/o wondering if, e.g. "Jack Greene" is an SCA or a Mundane name? Also, it makes it trivial to return all of a person's identities.

[cellio]

Most of the time we won't know a mundane name but we will know that A and B are the same person (different personas, either sequential or concurrent). It would be good to have some way for that to all sort together -- if I'm considering writing someone in for an award, I want to know if he already has it and I don't want to play guess-the-alternate-persona. In the cases where you know a mundane name (e.g. if he's registered his name then the heralds have that in their DB), fine and dandy. If not, I would think you would need a way to cons up a unique ID.

Is it useful to have a place to hang (where known) the members of a collective?