USM Bish wrote: >On Wed, Mar 09, 2005 at 10:29:45AM +0100, Bert Verhees wrote: > > >>I will come back to the answers I got about II later. >>Thanks for this. >> >>I have another question: about EntityNamePart in the CEN-standard. >> >>There seems to be no way to tell if a certain namepart actually are >>name-initials. >> >>f.e. >>Sometimes people often have more firstnames. >> >>Often they have a name that is used for casual contacts, and they have names >>which are in their passport, their official firstnames, which are often long >>names. >> >>Often, these long names are only known by initials >> >>Now I am extracting data from a local GP-system, and there is stored the >>shortname (f.e. Johnny) and the initials J.B. >>His friends call him Johnny B. Good. The second name in that system is only >>known by Initial. I have to deal with that. >> >>Because I want to present as much information as is possible in the standard, >>and I want to present the shortname (GIVEN NAME=Johnny), FAMILY NAME=Good, >>and because I want to give as much information as possible, because this can >>be important to identify a person, I want to add an extra entityNamePart: >>J.B. >>And now I am looking for a namepartType or namePartQualifier for initials. >> >>Someone have an idea? >> >> >> > >Naming conventions and methods of writing vary all over the >world. It may be difficult finding a common rule fitting all. > >I thought all that the CEN/TC251 specified for Class:EntityName >was merely 'a character string' (or several entity name parts >in sequence). This is applicable for a person, organisation or >even place or an object. 'EntityNamePart' would therefore be >sub-components of the above. > > Following the CEN standard, an EntityName is a list of entityNameParts, which are objects having three properties: I qoute from the CEN documentation I am using:
entityName: SET<EntityNamePart> EntityNamePart: - entityNamePart: The name part represented as a string - namePartType: VALUES: family name, given name, prefix, suffix - namePartQualifier: VALUES: preferred, birth, professional, maiden name >But how do you define the sub-componets, as far as name is >concerned ? > > As I understood from the previous email concernig this question, from isabel at trajano.us.es the qualifiers in the standard document are only examples, I thought, they were rules. So, at the moment, I define the nameparts using the qualifiers provided by CEN. >There are no fixed patterns for names or naming conventions. >There are many societies where there are no 'Family' names at >all. Some have Tribe names in lieu, some with father's or >village name as 'names' somewhere wedged in the name string. >Some with just unique names with nothing else. To add to this >confusion you would then have to find sub-components for nick >names and aliases. > >Bert, like your query regarding short-name and initials, I am >also curious in knowing how these name issues are planned to be >tackled ... Are there any thoughts in this direction ? Or is it >better to leave EntityName simply as a 'character string' with >no futher qualifications. > > My two cents are that in fact the system is good, you need qualifiers for automated processing, same problem as with OID. The case is, I am implementing it in a commercial product. These are only minor issues, but you run against them quick. I have no time to wait what will come out in years to follow. The questions I ask are so much at hand. In the first twenty lines of code, you run against a entityName, or a II-object. If I start interpreting the standard for my own needs, were or when must I end doing that. As a programmer, I am used to exact thinking, this byte is there and that is there. I am used to standards exactly telling me what or how to do something. Thinking should already have been done. I did not see one line of code written by someone else, that is implementing the CEN standard, and even if I did see that, how could I trust it, if there is so much confusion in minor issues. I am spoiled by open source communities were tons of source-code (often too much) are available. Anyway, thanks for your suggestions. Regards Bert Verhees >Bish > > >- >If you have any questions about using this list, >please send a message to d.lloyd at openehr.org > > > > - If you have any questions about using this list, please send a message to d.lloyd at openehr.org
