[Refdb-users] is a period information?

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

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.
 >=20

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.

 >=20
 > > An initial is a capital letter by definition.
 >=20
 > 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 initi=
al
 > by definition.
 > See: <http://www.cogs.susx.ac.uk/local/doc/punctuation/node28.html>
 >=20

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:

FM Last
F.M.Last

The dots (or the lack of dots) are the formatting, the capital letter
is the data.

 > See: DJ=A0Delorie

This name is handled gracefully by RefDB. It is not mangled in any
way.

 > This period says: "this letter before stands for an abbreviation".
 > It's formatting, carrying an information. Some stylesheets may not
 > care about this information, prefering esthetics, while some others
 > stylesheets may care. But a database or a format should better stay
 > _neutral_ and postpone the decision, so to please _everyone_, not ju=
st
 > one side.

This is not the point. The RIS format cannot make the distinction. An
XML format specifically designed for this purpose will be able to.

 > The reasons why I do not want to use the RIS middlenames period-base=
d
 > syntax are quite obvious above. Periods carry some information, and
 > middlenames are culture-specific.
 >=20

Fine, so let's wait until the MODS-based data model materializes.

 >=20
 > > I'm surprised that this seems new to you.
 >=20
 > Well, I must admit that I found the period-based RIS syntax a bit
 > weird when discovering it at first in refdb's manual, but
 > I=A0unfortunately overlooked the potential implications at this time=
.
 > Especially since I did not see it later anywhere else. By the way, d=
o
 > you have pointers to some other "official" RIS=A0specification? Are
 > others' definition strictly identical?
 >=20

To the best of my knowledge there is no other official spec except the
help files, the PDF manual, and the example databases that they ship
with the program. In addition it is helpful to see what the
individual styles do to the data upon output. So it's rather reverse
engineering than a useful spec.

 > BTW, how do you avoid false duplicates in this case? By asking every=

 > bibliographer to use the real, original cyrillic spelling?

No, by asking them to settle on one transliteration. Using MODS,
however, the cyrillic spelling is an option too as it has some means
to carry the transliteration.

 > >=A0And again, RefDB will not support names that can't be expressed =
in
 > > RIS syntax until a MODS-based data format is implemented.
 >=20
 > Well... my patched version tries to support them :-> It is its main
 > purpose.
 >=20

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.

You basically try to send a program written in Perl through a C
compiler. You notice that the C parser can't handle the Perl code, so
you decide to disable the parser and hope that the compiler will be
able to figure out the grammar all by itself. This is not going to
work. The only fix is to rewrite the program in C syntax.

 > Wow... this is becoming harder and harder to understand (I mean:
 > authorinfo.c r1.4, lines 70s) Could you document this new "hyphenate=
d
 > double initials" format carefully please? Is the hyphen mandatory? I=
s
 > "H.K."  now legal input? Or just "H-K" is? Is this RISX output legal=

 > RISX input? etc.

There is not much to document. A firstname and a middlename are
abbreviated without a hyphen because there is none in the first place:

Franklin Delano -> F.D. (RIS)
<firstname>F</firstname><middlename>D</middlename> (RISX)

A hyphenated double name retains the hyphen in the initialized form
because there is a hyphen in the first place:

Karl-Heinz -> K.-H. (RIS)
<firstname>K-H</firstname> (RISX)

That's all.

regards,
Markus

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