On Jan 31, 2004, at 7:35 AM, J.Pietschmann wrote:

> jcowan@r... wrote:
>> The components of person.name given by your schema are given, middle,
>> family, prefix, and suffix.  How do you map names like "Abu Ali 
>> al-Husain
>> ibn Abdallah ibn Sina" (alias "Avicenna"), or "Karen Ingridsdottir",
>> where "Ingridsdottir" is *not* a family name?
> [snip]
>
> That's why we have settled for a simple cname.
>  <person>
>    <cname>J. Pietschmann</cname>
>    ...
> or
>  <person>
>    <cname>Wang Zheng-Jiang</cname>
>    ...

Yes well, the same schema fragment that validates

<person.name>
	<given>John</given>
	<family>Smith</family>
</person.name>

also validates:

<person.name>
	<given>Abu Ali al-Husain ibn Abdallah ibn Sina</given>
</person.name>

if that's how you want to represent it -- or if that's all you know 
about a particular name. Name components are text. I am *not* claiming 
that marking up names using the ASTM E2182 schema or HL7 DTDs will 
actually imply some particular name semantics (beyond that some 
components are prefixes, some are delimiters, some given, some 
associated with families and some suffixes :-) In particular, I am not 
claiming that reading the spec will magically give one knowledge of how 
to tokenize a text string. We are simply providing a small set of 
(perhaps useful)  buckets.

>
> I'm always quite surprised why people insist on a more
> detailed structure with implied semantics, because the
> structure proved much less useful in practice than many
> people think:

Yes well when MURATA MAKOTO signs his name, it is frequently associated 
with some metadata that says which component is family and which is 
given. We should not presume that the western practice of given names 
before family name is used in other cultures.

In practice our schema fragment works great with forms that have slots 
for firstname, middlename, lastname


> 1. Sorting: Doesn't matter much in interactive online
>  applications. It matters on printed lists, but lists with
>  more than a few dozen names are unwieldy anyway.
> 2. Search: Do a substring search.
> 3. Incremental search: Split the cname in word tokens,
>  with "word" defined as "sequence of Unicode letter".
>  Match all records where the entered string matches the
>  beginning of any word in the cname.

The old "markup vs. free text" arguments arise. Not that tokenizing is 
a problem, but tags do that for you.

Jonathan