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]

i would think if nothing else it ties together two personae of the same person

[msmemory.livejournal.com]

Right.
Freydis Ragnarsdottir and Luke Knowlton, both personae of L. Pearson.

It's also useful for disambiguating two people with similar/identical SCA names. ("Elizabeth of Ostgardr, mka Liz Doe; Elisabeth of Ostgardr, mka Beth Smith.")

[rufinia.livejournal.com]

I don't know if that's neccesary. I don't know the structure, but the Midrealm OP combines them- in my entry, my AoA came under "Typheinne de la Croix" but the Court barony is under Aurelia Rufina, and either name takes you to the combined entry under Aurelia Rufina with a note "WAS Typheinne de la Croix." If people would rather not have thier mundane names involved, I don't think it's needed.

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

[jducoeur]

I think there are a couple of fundamental confusions here, the biggest of which is that, as it says at the top, all fields may be null. That's technical speak for "optional". Essentially *all* of this data is optional -- indeed, mundane name is often not known. But it *is* often very helpful, which is why it's recorded when we have it.

Also, as others have pointed out, this is *not* describing what this looks like to the public, it's describing the internal database schema. Many of these fields are for internal use only, not for public consumption. Mundane name is one of them.

So (a) if people don't want their mundane names involved, they can say so and that can simply be left out (if it was known in the first place, which it often isn't), and (b) even when they are known, they're not visible.

In general, you seem to be interpreting this as what the OP *looks* like, which it isn't -- the look isn't intended to change. It's just an under-the-hood change to the way the data is managed...

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