[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] On family/given/first/last names
(Dave and Markus, this addresses both your comments, since they're quite closely related) > Geraint North wrote: >> Out of interest, what do people use the firstname/surname/lastname/ >> givenname distinction for? In Docbook, its main use is clearly to >> identify document authors visually on the page. > > Contributors? A group of authors? Sure, but that's still basically the same thing - document authors. It seems to me that within DocBook, the uses for names are much more constrained than a general-purpose ontology for a 'person' would need to be - that's what I was trying to understand. >> Given the variation in naming schemes internationally, I'd be >> very unlikely to perform any sort of search restricted to >> givenname or familyname, so what else could it be used for? > > I like the suggestion on James page (one of the respondents) to enable > 'search term' so that I could search on what the person wants rather > than what a non-local might use? The thing is, if I'm searching for a document author, I don't want to miss a result because I'm unfamiliar with the particular local characteristics of the person's name - the only sensible thing to me would seem to be for the XML to contain every component of their name, and for me to search on all of them. >> Perhaps the correct distinction is to list name components in >> printing-order, with semantic markup to identify the sort order? > Which might be your or my interpretation? If it's known (not always > the case I guess) then surely better to use that person (or their > locale specific usage if known) for search? And Markus's comment: > Naming conventions are a pet peeve for everyone involved in > generating citations and bibliographies for scholarly publications. > Scientific journals and publishers have fairly strict rules how to > display names of authors and editors. In order to do that, you need > to know the function of each part of the name. Assume the journal > wants the names displayed as "Last, First M.". A guy named Luis > Lopez Penabad would obviously be displayed as "Penabad, Luis L." > although this is all wrong. He is Spanish, has one firstname (Luis) > and two lastnames (Lopez Penabad), one from each of his parents. > The correct display form is therefore "Lopez Penabad, Luis". The > firstname/surname/lastname/givenname elements somewhat help to get > this right, although you still face lots of problems with non- > Western names, and even with some standard US names. E.g. if a > person goes by his second "firstname", like L. Clinton Webb, the > current DocBook markup has a hard time to catch this If publishers do have strict guidelines in this regard, it would be interesting to know _why_ they have these guidelines - I suspect that they are artefacts from a time when search would be performed on the printed document itself, which (as Markus showed in his example) has clear disadvantages. Obviously an impossible proposal, but if _I_ were King of the International Author Naming Committee, there seem to be only two things of interest: - How each author would like their name displayed - An unordered set of all the components of their name (including variants), for search purposes. e.g. <author> <displayas>L. Ron Hubbard</displayas> <namecomponent>Lafayette<namecomponent> <namecomponent>Ron<namecomponent> <namecomponent>Ronald<namecomponent> <namecomponent>Hubbard<namecomponent> </author> <author> <displayas>William Gates III</displayas> <namecomponent>William<namecomponent> <namecomponent>Bill<namecomponent> <namecomponent>Gates<namecomponent> </author> <author> <displayas>Luis Lopez Penabad</displayas> <namecomponent>Luis<namecomponent> <namecomponent>Lopez<namecomponent> <namecomponent>Penabad<namecomponent> </author> <author> <displayas>Geraint North</displayas> <namecomponent>Geraint<namecomponent> <namecomponent>Michael<namecomponent> <namecomponent>North<namecomponent> </author> Thanks, Geraint.