Alphanym is a full-stack solution, and can help anywhere you need to use people's names.
For storing names, I'd suggest two very long Unicode string fields. At least 1024 characters or greater (some names actually get that long). One field being a full name field, the other being a "betanym" field (the name used anywhere you'd use a persons "first name" normally). Use the full name in billing/idiomatic contexts, and the betanym when addressing customers directly (or if you need a shorter name for UI reasons).
The full-stack UI is there to encourage user feedback, because names are surprisingly ambiguous. Though in more lax contexts like ML/NER, direct API calls without feedback may be adequate.
>Is this 'just' the front end part (in quotes because it's such a hairy issue, I imagine you have lots and lots of 'special case' code)?
There's surprisingly little special case code on the backend, because it primarily relies on ML to generate name interpretations. So most of the special casing is embedded in the ML models. However I am introducing more special case code to refine the ML models with a cleaner dataset.
Using names is ridiculously complex in the general case, seeing as it's a proper subset of NLP. So the API relies on user feedback, which is stored by Alphanym so it can offer more accurate interpretations in subsequent requests. The `name-uncertain` field allows clients to bypass the confirmation if the API has encountered the name before, so at no point does the system assume anyone's name. Yet most of the time people will only have to fill out a single form field.
For storing names, I'd suggest two very long Unicode string fields. At least 1024 characters or greater (some names actually get that long). One field being a full name field, the other being a "betanym" field (the name used anywhere you'd use a persons "first name" normally). Use the full name in billing/idiomatic contexts, and the betanym when addressing customers directly (or if you need a shorter name for UI reasons).
The full-stack UI is there to encourage user feedback, because names are surprisingly ambiguous. Though in more lax contexts like ML/NER, direct API calls without feedback may be adequate.
>Is this 'just' the front end part (in quotes because it's such a hairy issue, I imagine you have lots and lots of 'special case' code)?
There's surprisingly little special case code on the backend, because it primarily relies on ML to generate name interpretations. So most of the special casing is embedded in the ML models. However I am introducing more special case code to refine the ML models with a cleaner dataset.
Using names is ridiculously complex in the general case, seeing as it's a proper subset of NLP. So the API relies on user feedback, which is stored by Alphanym so it can offer more accurate interpretations in subsequent requests. The `name-uncertain` field allows clients to bypass the confirmation if the API has encountered the name before, so at no point does the system assume anyone's name. Yet most of the time people will only have to fill out a single form field.