On Sat, 10 Jan 2004, Markus Hoenicka wrote:
> Marc Herbert writes:
> > In "Harry S Truman", the S is not an abbreviation. There has been a
> > debate whether it should nevertheless be written "S." "for the sake
> > of consistency", at the price of some (admittedly harmless)
> > information loss. See google.
> Citing from the Truman Presidential Museum and Library
> (http://www.trumanlibrary.org/speriod.htm):
>
> "In recent years the question of whether to use a period after the "S"
> in Harry S. Truman's name has become a subject of controversy,
> especially among editors. The evidence provided by Mr. Truman's own
> practice argues strongly for the use of the period. While, as many
> people do, Mr. Truman often ran the letters in his signature together
> in a single stroke, the archives of the Harry S. Truman Library has
> numerous examples of the signature written at various times throughout
> Mr. Truman's lifetime where his use of a period after the "S" is very
> obvious."
> This doesn't mean there can't be other examples of non-abbreviated
> single-letter middlenames, but Truman apparently is not one of them.
I suggest you go on reading the same page, just a couple of lines
further:
"In explanation he said that the "S" did not stand for any name"
And a bit later:
"According to The Chicago Manual of Style all initials given with a
name should "for convenience and consistency" be followed by a
period even if they are not abbreviations of names."
This last sentence says a bunch of interesting things:
- stylesheets that "normalize" on "no-periods" are neither
"convenient" nor "consistent" according to this manual (Uh?)
- the last line shows that the Chicago Manual knows enough cases of
single-letter in names, besides Truman's, to have considered this
issue. That answers one of your questions.
- the need for this justification for the "all-periods" policy shows
that it was not obvious and that there has been a debate; please
tell about what, if not loss of information?
And finally, it's a recommandation made by a manual of *style*, and
not a recommandation about the design of bibliographic databases.
> >
> > > An initial is a capital letter by definition.
> >
> > But the reverse is wrong. A capital letter is not an initial by
> > definition. It just may be. A capital letter + a period is an initial
> > by definition.
> > See: <http://www.cogs.susx.ac.uk/local/doc/punctuation/node28.html>
> I disagree. It's an initial followed by an indicator that the previous
> letter is an abbreviation of something else. The difference should be
> apparent if we think of an initial as data and what an output format
> is supposed to do with it. Format (1) outputs initials as they are,
> format (2) renders them using dots:
> (1) DJ Last
> (2) D.J.Last
... which clearly shows that format (1) lost the information that 'D'
and 'J' are abbreviations. You have to guess it. Easy for 99% of
names. And the remaing 1% does not matter: these people should
probably better get a life and normalize their names anyway...
By the way, I am wondering what "uppercase" means in unicode.
> > See: DJ Delorie
>
> This name is handled gracefully by RefDB. It is not mangled in any
> way.
Sure! But the topic here was "is a period information?" (see the
Subject:). This example just demonstrates the issue with stylesheets
that think period are just formatting and suppress them, losing
information. They can not make the difference between:
DJ Delorie -> DJ Delorie (OK)
and
Dorothy J. Delorie -> DJ Delorie (loss of periods/information)
I obviously never asked you to correct these stylesheets! In fact, I
even gave up asking you to change _anything_ in refdb about this since
quite a time (excepted some added words in the documentation). I just
recently sent on the list a patch not to lose the information in
advance in the database, with admitted and documented short-comings.
Then you felt complied to demonstrate this patch is the apocalypse,
giving to it probably more attention and publicity that it deserves.
> > > And again, RefDB will not support names that can't be expressed in
> > > RIS syntax until a MODS-based data format is implemented.
> >
> > Well... my patched version tries to support them :-> It is its main
> > purpose.
> No, it does not support them. The patch prevents that RefDB
> understands the names. Instead you dumb down the application to a
> state that it returns the same string that you sent in. However, in
> order to do anything useful with the names, RefDB must be able to
> parse them. The patch effectively prevents creating formatted
> bibliographies and export to all data formats that distinguish name
> parts.
At least half of this is plain wrong.
My patch only prevents RefDB to parse the GIVEN NAME, and only FROM
RIS INPUT. I suggest you read this page:
<http://marc.herbert.free.fr/refdb/reversible/> that describes the
patch with decent accuracy, contrary to your paragraph above. Reading
it may be useful if you want to make comments (but you don't have to
make comments).
Cheers,
Marc
-------------------------------------------------------
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
|
