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

[jducoeur]

Hmm. Intriguing suggestion -- I'll think about that. I tend to think of them as qualitatively different, but the similarity of the data fields suggests that that may not be as true as my gut says.

Playing Devil's Advocate: the difference in privacy levels, obvious in the discussion above, may be one good reason to keep the tables separate -- it makes it less likely that they will accidentally get wires crossed and expose non-public information. Indeed, the difference in terms of public/private may be the *most* important difference between the two...

[siderea]

An interesting point. (Normalization is great stuff, right up to the point it isn't.)

BTW, this brings up the point: how is this going to be used? Is there going to be a public interface on the internet? You're aware of the SCA, Inc's policy on systems that connect SCA name to legal name?

[jducoeur]

The intent is mostly to generate the static OP pages, which are currently maintained by hand, and to be a tool when msmemory needs to look things up. Trying to set things up live -- well, that might be possible at some point down the road, but it's definitely getting ahead of ourselves.

You're aware of the SCA, Inc's policy on systems that connect SCA name to legal name?

The only rule on the subject that I know is from the Chronicler's Policies, and states that you aren't allowed to *publish* the correlation. As emphasized in the discussion above, that is absolutely not intended here. Indeed, that's why I bring the issue up in the context of the tables -- I want to make sure it doesn't happen accidentally. The point of keeping track of what information we have is solely for the problem-solving part of the job, not the public OP. (Most people don't have the slightest notion how much of msmemory's job is dealing with problems over and above what shows up in the OP.)

I don't know of any other restrictions. Indeed, I'd be surprised to find any, given how many SCA regulations *require* you to track both SCA and mundane names for various purposes...

[dagonell.livejournal.com]

"Indeed, I'd be surprised to find any, given how many SCA regulations *require* you to track both SCA and mundane names for various purposes..."

*Snort!* Yeah, like shire voting procedures! This was recently a PITA in our shire during elections. Only 'eligible' members can vote. Who's an 'eligible' member? A paid member within the zip codes. Which means you need to see both SCA proof of membership like a TI subscription AND mundane proof of residence like a gas bill, but you're not allowed to correlate SCA name with mundane name, oh no...
-- Dagonell

[jducoeur]

As far as I can tell, you *are* allowed to make the correlation -- you just aren't allowed to publish it publically. Did you come across any rules that say otherwise? (That would, obviously, be relevant here...)