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]

well, yes and no.

If it's not visible, it's still there, which could make people uncomfortable (And I'll say it makes me uncomfortable. I'm not sure why, but it does). And if it's not neccesary, then why have it at all? True, mundane names are less changable than SCA names, but not by a lot, and you are more likely to have repeats in mundane names, so having one as a unique identifier doesn't seem like the most elegant of solutions.

[jducoeur]

True, mundane names are less changable than SCA names, but not by a lot, and you are more likely to have repeats in mundane names, so having one as a unique identifier doesn't seem like the most elegant of solutions.

This is just plain not true. SCA name stock is quite small compared to mundane, and much more prone to ambiguity. You of all people should know this -- your mundane first name is completely unique in my experience, but your SCA name is barely even unique on my friends list.

Moreover, there's a multiplicative effect: having two pieces of data reduces the ambiguity by orders of magnitude over having only one. If we were *just* using mundane name, it might be only so-so -- but having both reduces the chance of confusion to *very* nearly zero.

And seriously: I think you're making a mountain out of a molehill. You don't want it tracked, say you want it out of the data. It isn't necessary, but it *is* often useful. ("Necessary" is a pointless term, and a distraction. The OP is not "necessary" at all. It *is* helpful. So is having more data behind the scenes so that questions can be researched when they come up.) It is absolutely, explicitly optional in the schema, and non-public.

I'm sorry if that's not good enough for you, but given those facts, I think your concern is going well beyond the rational. This isn't some government agency we're talking about here: this is just a private project to correlate the existing notes and files into more manageable form. Heck, in the new system it'll be much *easier* to take your mundane name out of the data, because it'll only be in one place, rather than potentially scattered across many...

[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...