Personal name field schemas

Registered by Justas Sadzevičius

This is (probably excessive) take on personal naming problem. Personal names vary greatly throughout cultures, leaving only one thing certain - a person has at least one given name. Amount and names of fields to describe the person vary, also the traditions to display names in various context. It is natural to assume that a school may contain records of persons from more than one culture.

Blueprint information

Status:
Complete
Approver:
None
Priority:
Undefined
Drafter:
Justas Sadzevičius
Direction:
Needs approval
Assignee:
None
Definition:
New
Series goal:
None
Implementation:
Implemented
Milestone target:
None
Started by
Tom Hoffman
Completed by
Tom Hoffman

Whiteboard

This is quite a complex topic. Here's my take on this.

Universally, personal names consist of four components:

1) optional: titles - basically the social standing, not considered part of the actual name
2) core: given names - always at least one, commonly two fields (middle name or patronymic)
3) core: surnames - commonly one field (though in some cultures omitted entirely), usually family name, sometimes tribe, caste or other
4) optional: qualifiers - commonly generational standing, sometimes qualification (like Ph.D., M.D.)

Actual fields per component are culturally dependent, thus dependent per *person*.

Another wide known issue is given name and surname ordering (Eastern vs Western), it manifests in two separate places:
  - entering a personal name
  - displaying lists of persons (their names can come from different cultures and initially have different Easter/Wester order)

-----------------------------------------------

As a full solution, I'd like to have (eventually user customizable) field schemas for the personal name components. So that ST would support schemas like:

  - Western; titles:[prefix] given_names:[first_name] [middle_name] surnames:[last_name] qualifiers:[suffix]

  - Eastern; titles:[title] surnames:[surname] given_names:[given name] qualifiers:[] (note Eastern name ordering here)

  - Slavic; titles:[prefix] given_names:[name] [patronymic] surnames:[last_name] qualifiers:[generation?]

Schemas are a thing of configuration, end users would only see the fields, like:
[prefix] [name] [patronymic] [surname] [generation?]

When entering a new person, there should be a preset schema for the school or an option to select the desired personal name schema.

When displaying a person list, there should be an option (per school probably) to select Eastern/Western name ordering.

----------------------------------------------

A serious unsolved problem is "the phone book problem", i.e. sorting a list of persons from different cultures. Thing is, that this problem *is not solved* universally worldwide as far as I know. There are some local rules and approximations per *country*.

So, a simple solution on our side would be: allow to specify language (per school) to be used for collation of person lists. And that's it. Leave the collator pluggable/customizable for custom deployments or future development.

Hazy approaches for future consideration:
- transliteration to latin/other alphabet as a sorting step
- removal of affixes (think "Gillian van der Waal") as a sorting step

More information on problems can be found in Wikipedia, "collation", section "complications" and on the internet in general. "ICU locale explorer" also gives some insight.

----------------------------------------------

Why bother at all with the personal name schema complexity?

It gives a separation layer that eases the development while still allowing full cultural personal name variety.

Though the whole scope of the problem is big, once initial separation is implemented, it can be developed (and updated as needed) in series of separate small chunks.

One fixed schema -> 2-3 fixed schemas -> customizable schemas.

Fixed schema per deployment (think customized grant deployments) -> schema set in preferences.

Basic unicode person list sorting -> sorting by school preferred locale -> intelligent sorting.

Two aggreagators for developers (short name, full title) -> many aggregators (as needed).

No Eastern/Western name order support -> partial support -> full support.

Just saying that it can be broken down to simple steps.

----------------------------------------------

Example name aggregators for developers:

  - display short name: first field of given_names, whitespace, fields of surnames separated by whitespace, fields of qualifiers separated by whitespace (given_names may follow surnames instead if option is selected in school).
Example: "Gillian van der Waal Jr.", "John Smith"

  - display full name: fields of given_names separated by whitespace, fields of surnames separated by whitespace (again, Eastern/Western ordering).
Example: "Gillian Lucille van der Waal", "John Abraham Smith"

  - display given name: first field of given_names.
Example: "Gillian", "John"

  - display surname: fields of surname.
Example: "van der Waal", "Smith"

  - display full title: all fields in schema order, separated by whitespace.
Example: "Dr. Gillian Lucille van der Waal Jr.", "Mr. John Abraham Smith"

  - display short title: everything, just ommit other given names.
Example: "Dr. Gillian van der Waal Jr.", "Mr. John Smith"

  - for integrations with other software, fields like "title", "givenName", "surname", "generationQualifier", or whatever the requirements are, can be tuned/aggregated for each software respectively.

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.