[Refdb-users] Re: The case against <middlename>

[Markus H. <mar...@mh...>]

Marc Herbert writes:
 > I am glad to hear this! Then fix the _automated_ RIS parsing/syntax by
 > adding a comma to it?
 > 

Where would you like to have an additional comma? I'd be reluctant to
do this anyway as this would break data import from RefMan and
EndNote, but the RIS syntax uses two commas anyway. One to separate
the last name from the rest, and one to separate the suffix from the
rest.

 > I did not know publishers of 5000 life sciences journals where so
 > english-centric and ignorant of foreign cultures.  This bug is quite
 > amazing.
 > 

It's sad but I don't see it as my job to change this.

 > 
 > >=A0I also believe that your argument is moot that if a
 > > style requires the concept of middle names it should be able to
 > > retrieve the middle name by itself. With the same argument you could
 > > dump entirely unparsed strings in any order onto a bib software and
 > > expect it to figure out how to parse it, as it requires to disginguish
 > > between given and family names, titles and suffixes.
 > 
 > If I remember well, this discussion is about the right level of detail
 > to adopt and where. So I find "With the same argument you could dump
 > entirely unparsed strings" not very constructive.
 > 

I just wanted to point out that it does not make much sense to me to
code half-parsed strings in XML when you have to parse anyway. Why not
go the extra inch and do it right?

 > This life-science-specific "middlename parsing" could be factorized
 > without being put down to the database. So refdb could be used
 > internationally without bugs and hassles: just by working around it.
 > Why not adding a "-[no]middlename" option for outputs ?
 > 
 > Same thing for the "clever" abbreviating code.
 > 

The middlename handling and abbreviating stuff is not at your
discretion. If a style requires these modifications it does not make
any sense to add a switch that will produce incorrect data.

 > No it's not too late: you can also play the same game with dots and
 > spaces later at search/formatting time, without subtly and silently
 > modifying the data that the user intently input; that is losing
 > information really.
 > 

That is, re-parse the name string each time a query comes in? It
couldn't come any worse.

 > Please do never silently and subtly modify user data. At least ask for
 > confirmation! The real world is too complex for any "clever" names
 > standardization algorithm.

I'll be happy to add a section to the docs in all caps and a red box
around it stating that author names will be normalized for the sake of
consistency.

 > OK: I suggest one *extremely* simple improvement to this code: the
 > ability to disable it, at least at configure time (I will code this
 > for myself in any case).
 > 

This does not make sense as it breaks consistent searching and the
bibliography formatting. Otherwise this is an example of the beauty of
free software. If you code this for yourself, everyone can have it his
way.


regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de