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]

It's also worth noting: you seem to be fixated on the idea that "mundane name is the unique identifier", which has nothing to do with reality. The truth is that the OP is always, by the nature of the system, a gigantic muddle -- we don't *have* unique identifiers, nor are we ever likely to get any. There is a variety of highly-scattered, highly-ambiguous information.

So when problems do arise -- and they *do* arise moderately often, and are usually quietly addressed by the OP-keepers -- they need all the information they can get their hands on to resolve them. Mundane name is *one* element of that, and it can prove handy when it is available.

This isn't about some massive government database tracking people by mundane names. This is about trying to do a fairly hard job, using whatever information can be scrounged up. The point of the DB is to make that scrounging process a little less arduous...

[fosveny.livejournal.com]

The mundane name can't be the unique identifier. I'm sure we have more than one "John Smith" in the SCA.

The SCA name, if registered, is supposed to be unique. It says so right here on the label. Of course, 'supposed to be' is wishful thinking - there are a handful of cases where we have duplicates, and even one duplicate is enough to screw up a database that wants a unique field.

It's not just highly scattered and highly ambiguous. It's also highly incomplete.

[jducoeur]

The SCA name, if registered, is supposed to be unique. It says so right here on the label. Of course, 'supposed to be' is wishful thinking - there are a handful of cases where we have duplicates, and even one duplicate is enough to screw up a database that wants a unique field.

More importantly, you can't count on a registered name, and unregistered names certainly are *not* unique. Having two "Joe of Carolingia"s historically is downright easy. (Indeed, imputed SCA names are especially hard to distinguish.)

So yes -- incomplete, ambiguous, the whole nine yards. Hence, the DB needs to be extremely flexible and tolerant of crappy input data, because that's what we have to work with...