Alternate name structures

[klambacher]

We have a highly structured alternate name system that includes individual entries for multiple alternate names (AKAs), former names with dates of change, and legal names. I wouldn't necessarily argue for adding a heavy structure, but would like to see some formal guidelines for those that have structured data. In the perfect world, I'd like to be able to distinguish the type of alternate name (it's important to know the difference between a legal name and and what people might informally call something) and the year (if applicable) . However, I'd be pleased to at least see guidelines for delimiting multiple names.

[timgdavies]

@klambacher Which objects do you have this information for?

My initial instinct would be a split this out into a alternate_names table when it gets down to years and other information - and to treat that as an advanced feature that most systems are unlikely to track.

Do you version other information? As a different pattern in some standards would be to have a data-wide approach to versioning.

[klambacher]

@timgdavies we keep all these types of alt names for locations, services, and organizations. It includes all of the above for each AKA (type of the name - alternate, former or legal), sometimes date of name change, plus we actually also distinguish between publishable names and names that are there for search purposes only (e.g. when people add informal names for search keyword cramming). Again, I don't expect all our features to be available but would like to see more structure be available for those that can use it.

[timgdavies]

I'm tagging this to look at in the next round of updates.