refdb-users — List for RefDB users

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

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

Bruce D'Arcus writes:
 > I would never include a full "middle" name in a record, because I have=20=
 > 
 > never seen an academic uses anything but an initial.  So I would never,=20=
 > 
 > in fact, need to have such a thing initialized.
 > 

I'm sure we'll find that odd journal that spells out the middle names
if we really want it. I simply don't understand why it is so
intriguing to not use proper markup to separate and classify the name
parts. RIS can't do it any better, but XML can.

regards,
Markus

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

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

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

Justus H. Piater writes:
 > In general, I think that structure should be defined by markup and not
 > by string parsing conventions (that's what XML is for after all:
 > unambiguous definition of structure).

I strongly support this. The only problem we're facing currently is
that RefDB tries to stay compatible with RIS which does not allow this
unambiguous markup. This is only going to change when RefDB switches
to a different data model (most likely a variant of MODS). Then we'll
have a chance to get this right. I'm admittedly not too happy with the
way MODS deals with names. It essentially allows the same murky markup
that keeps all sorts of name parts in a single element.

 > On the other hand, multiple
 > names that belong together and should be treated equally may perhaps
 > be kept together, as it avoids tons of markup and is easily parsed by
 > spaces or hyphens.
 > 
 > Thus, I propose something like the following:
 > 
 > <personal>James</personal>
 > <given>C.</given>
 > <given>D.</given>
 > <family>Scott</family>
 > 
 > <personal>Raman</personal>
 > 
 > <given>F.</given>
 > <personal>John</personal>
 > <family>Smith</family>
 > 
 > <personal>Jean-Fran=E7ois</personal>
 > <family>Dubois</family>
 > 
 > <personal>Jos=E9 Antonio</personal>
 > <family>Garcia Fernandez</family>
 > 
 > I'd prefer to put each name into a separate element, but that would
 > require a surrounding element to group them together, along with a way
 > to specify the separator (space? dash?).
 > 

I don't think that dashes ever cause problems. In my understanding, a
name using a dash is an entity. Therefore the separator would always
be a space if one is required by the bibliography style.

Does anyone have real-life examples of names along the lines of
"F. John Smith" in a journal that uses full first and initialized
middle names? This would indeed be the best proof why first and middle
names (or whatever you call them) need to be distinguishable.

regards,
Markus

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

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

[Bruce D'A. <bd...@fa...>]

On Dec 11, 2003, at 3:51 AM, Justus H. Piater wrote:

> Thus, I propose something like the following:
>
> <personal>James</personal>
> <given>C.</given>
> <given>D.</given>
> <family>Scott</family>
>
> <personal>Raman</personal>
>
> <given>F.</given>
> <personal>John</personal>
> <family>Smith</family>
>
> <personal>Jean-Fran=E7ois</personal>
> <family>Dubois</family>
>
> <personal>Jos=E9 Antonio</personal>
> <family>Garcia Fernandez</family>

The personal element confuses things, particularly when you compare to=20=

mods, where you would have:

<name type=3D"personal">
	<namePart type=3D"given">Jean-Francois</namePart>
	<namePart type=3D"family">Garcia Fernandez</namePart>
</name>

Likewise, I see no problem with:

<name type=3D"personal">
	<namePart type=3D"given">F. John</namePart>
	<namePart type=3D"family"> Smith</namePart>
</name>

I would never include a full "middle" name in a record, because I have=20=

never seen an academic uses anything but an initial.  So I would never,=20=

in fact, need to have such a thing initialized.

Bruce=

[Refdb-users] multiple <middlename> ?

[Marc H. <mar...@en...>]

By the way, I noticed that the risx DTD=A0caters for several
<middlename>, but not the RIS syntax of the refdb manual, nor the
records in the (sqlite) database.

What is the exact status/future about this ? Thanks in advance.

Cheers,

Marc.

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

[Marc H. <mar...@en...>]

On Wed, 10 Dec 2003, Markus wrote:

>  > I am NOT=3DA0asking to remove the concept of <middlename> down to ev=
ery
>  > refdb line code: I am just suggesting to postpone this concept to th=
e
>  > rendering stage, so it does not spoil the data model.
>  >
>
> It does not spoil the data model to use a human brain for the parsing
> of names.

Right, except that using the RIS syntax imply using a buggy
_automated_ algorithm to do this parsing.


> An unparsed name string is spoilt data.

"unparsed" can obviously not be "spoilt"... but only "rough".


> Marc Herbert writes:
>  > Let me reformulate: "lack of detail is better than wrong details". N=
o
>  > information is lost by storing all "given" names in <firstname> and
>  > not parsing them.

> You lose the information that a human brain can put into parsing the
> name string, using cultural background information that is hard if not
> impossible to teach to a machine.

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


>  > A style sheet that mandates the use of "middlename" is, to put it
>  > mildly, "culture-specific". If it insists on this, then it should be
>  > able to extract this information _by itself_, and not spoils the
>  > global data model because of this peculiarity. It seems this is
>  > exactly how BibTeX's stylesheets work. References given in a previou=
s
>  > message seem to show that other formats do it the same way.

> Once again, go complain to the publishers of roughly 5000 journals in
> the life sciences.

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


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


>=A0This simply expresses your dislike of middle names.
                        ^^^^ !

Please go complain to the publishers of most of the truly
international journals (except life sciences), and to the designers of
all bibliographic formats I've seen (except risx).

I started to "dislike" middlenames, only after doing research and
understanding that almost no one use them.



>  > I think this *requirement* is more or less flawed. The more
>  > reformatting it requires, the more flawed it is, since the more
>  > (wrong) assumptions it will make concerning "name standardization"
>  > (i.e., that everybody should have a name that is american-english
>  > looking).  The worst assumption is of course the requirement of a
>  > <middlename>.  Assumptions about dots are also flawed, see for
>  > instance: <http://www.delorie.com/users/dj/>

> Once again, I didn't invent these requirements. I have to support them
> if I want to support the 5000+ journals in the life sciences.

>  > In any case, these dirty issues should not spoil the data model, the=
y
>  > should be (and can be!) postponed and solved by the stylesheets
>  > _themselves_. So mistakes appear only in some printings, and there
>  > are no irreversible mistakes in the data source.

> I don't think it is a brilliant idea to have each of 700+ stylesheets
> (if we consider only the life sciences for a moment) parse and munge
> the names by themselves. Code duplication and bloating would be
> inevitable. I'd rather have stupid simple stylesheets that use the
> preparsed names from the application.

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 rationale is here: if middlenames should be kept in the data mod=
el
>  > (sigh), have at least only simple, perfectly reversible data
>  > transformations in database operations. No dots that magically
>  > appear or disappear, no variable number of tokens, etc. It's always
>  > time to do this at the formatting step.

> That's too late as I pointed out elsewhere. You need the normalization
> when you enter the data into the database to have a consistent and
> reliable way to search names.

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.

It's just about where sits this "clever" code.


>  > ... and this normalization is too complex to be automated, since
>  > no program can correctly handle all particular cases, thus it should
>  > be manually carried out by operators.
>  > I guess this is already the way it goes in most real cases today?
>  >
>
> So if you want to import 100 references that a nice colleague just
> sent you, you start adding/removing spaces and dots from somewhere
> between 100 and 1000 author names? Problematic as it may be in border
> cases, this is a job that *asks* to be automated.

Yes, but as you said above:

> You lose the information that a human brain can put into parsing the
> name string, using cultural background information that is hard if not
> impossible to teach to a machine.

so maybe the conclusion is that it should be "computer-assisted",
instead of "fully automated" ?

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.


>=A0If it fails in too many cases, we have to improve the code.

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).



>  > But searching for :AU:=3D3D"Miller,A.*M.*" will give a pretty good r=
esult,
>  > and reveal to the operator the manual normalization work that must b=
e
>  > completed.
>  >
>
> This is what a reference manager should avoid at all costs. Why on
> earth should a user be forced to use regular expressions just to find
> references by author names? If this is necessary the data model is
> flawed.

I made a discovery: the real-world data model for international names
is flawed, at least beyond the "family" and "given" name distinction.
Some people even make this more fuzzy by not signing with precisely
the same character strings each time. And worst of all: different
databases try to "standardize" this naming mess... in different ways!

Should we also "normalize" the reality for the please of
bibliographers? I prefer not to wait this long, live with it, and
learn to use jokers while doing name searches; I guess that's what
everyone is already doing today.

Cheers,

--=20
Marc A.Yves Herbert :-)

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

[<Jus...@UL...>]

Hi,

I've followed the discussion with interest. Let me try to complicate
things even further:

- Some people have more than two given names.

- Some people with more than one given name do not use their first
  given name in daily life ("F. John Smith"), effectively reversing
  the roles of first and middle names.

- While we're at it, we might want to include double names in the
  discussion (Jean-Fran=E7ois =3D J.-F., Anne-Marie =3D A.-M.).

- There are people who treat their given names equally, even without a
  dash; this is quite common in Latin America.

- In some cultures, people have more than one family name, and they
  should be treated equally (also Latin America).

In general, I think that structure should be defined by markup and not
by string parsing conventions (that's what XML is for after all:
unambiguous definition of structure). On the other hand, multiple
names that belong together and should be treated equally may perhaps
be kept together, as it avoids tons of markup and is easily parsed by
spaces or hyphens.

Thus, I propose something like the following:

<personal>James</personal>
<given>C.</given>
<given>D.</given>
<family>Scott</family>

<personal>Raman</personal>

<given>F.</given>
<personal>John</personal>
<family>Smith</family>

<personal>Jean-Fran=E7ois</personal>
<family>Dubois</family>

<personal>Jos=E9 Antonio</personal>
<family>Garcia Fernandez</family>

I'd prefer to put each name into a separate element, but that would
require a surrounding element to group them together, along with a way
to specify the separator (space? dash?).

Comments?

Justus H. (grin)

--=20
Justus H. Piater, Ph.D.         http://www.montefiore.ulg.ac.be/~piater/
Institut Montefiore, B28        Phone: +32-4-366-2279
Universit=E9 de Li=E8ge, Belgium    Fax:   +32-4-366-2620

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

[<Jus...@UL...>]

Hi,

I've followed the discussion with interest. Let me try to complicate
things even further:

- Some people have more than two given names.

- Some people with more than one given name do not use their first
  given name in daily life ("F. John Smith"), effectively reversing
  the roles of first and middle names.

- While we're at it, we might want to include double names in the
  discussion (Jean-Fran=E7ois =3D J.-F., Anne-Marie =3D A.-M.).

- There are people who treat their given names equally, even without a
  dash; this is quite common in Latin America.

- In some cultures, people have more than one family name, and they
  should be treated equally (also Latin America).

In general, I think that structure should be defined by markup and not
by string parsing conventions (that's what XML is for after all:
unambiguous definition of structure). On the other hand, multiple
names that belong together and should be treated equally may perhaps
be kept together, as it avoids tons of markup and is easily parsed by
spaces or hyphens.

Thus, I propose something like the following:

<personal>James</personal>
<given>C.</given>
<given>D.</given>
<family>Scott</family>

<personal>Raman</personal>

<given>F.</given>
<personal>John</personal>
<family>Smith</family>

<personal>Jean-Fran=E7ois</personal>
<family>Dubois</family>

<personal>Jos=E9 Antonio</personal>
<family>Garcia Fernandez</family>

I'd prefer to put each name into a separate element, but that would
require a surrounding element to group them together, along with a way
to specify the separator (space? dash?).

Comments?

Justus H. (grin)

--=20
Justus H. Piater, Ph.D.         http://www.montefiore.ulg.ac.be/~piater/
Institut Montefiore, B28        Phone: +32-4-366-2279
Universit=E9 de Li=E8ge, Belgium    Fax:   +32-4-366-2620

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

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

Bruce D'Arcus writes:
 > But do they actually explicitly say anything about "middle names"?  =
If
 > I go to the author info page for the J. of Biological Chemistry, I s=
ee
 > this:
 >=20
 > > References
 > >
 > > =B7        cited in text by number rather than author and date
 > >
 > > =B7        numbered consecutively in the order of appearance in th=
e
 > > manuscript
 > >
 > > =B7        References for journals and books should be in the foll=
owing
 > > styles:
 > >
 > > 1. MacDonald, G. M., Steenhuis, J. J., and Barry, B. A. (1995) J.
 > > Biol. Chem. 270, 8420-8428
 > >
 > > 2. Sambrook, J., Fritsch, E. F., and Maniatis, T. (1989) Molecular=

 > > Cloning: A Laboratory Manual, 2nd Ed., Cold Spring HarborLaborator=
y,
 > > Cold Spring Harbor, NY
 >=20
 > All this tells me is that given names -- all of them -- ought to be
 > initialized, with a period, and separated by a space.  There is no
 > distinction between first and middle.
 >=20

This is an example where the distinction does not come into
play. Other styles require the full first name and initialized middle
name(s). In this case it should be apparent that first and middle names=

need to be distinguishable.

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

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

[Bruce D'A. <bd...@fa...>]

On Dec 10, 2003, at 5:31 PM, Markus Hoenicka wrote:

> I am not trying to convince you that middle names are a good thing per
> se or that the Chicago Manual should adopt them. They are used in the
> bibliography styles of journals in the life sciences, and all of these
> journals do have pretty strict rules that do or don't comply with the
> Chicago Manual.

But do they actually explicitly say anything about "middle names"?  If=20=

I go to the author info page for the J. of Biological Chemistry, I see=20=

this:

> References
>
> =B7=A0=A0=A0=A0=A0=A0=A0 cited in text by number rather than author =
and date
>
> =B7=A0=A0=A0=A0=A0=A0=A0 numbered consecutively in the order of =
appearance in the=20
> manuscript
>
> =B7=A0=A0=A0=A0=A0=A0=A0 References for journals and books should be =
in the following=20
> styles:
>
> 1. MacDonald, G. M., Steenhuis, J. J., and Barry, B. A. (1995) J.=20
> Biol. Chem. 270, 8420-8428
>
> 2. Sambrook, J., Fritsch, E. F., and Maniatis, T. (1989) Molecular=20
> Cloning: A Laboratory Manual, 2nd Ed., Cold Spring HarborLaboratory,=20=

> Cold Spring Harbor, NY

All this tells me is that given names -- all of them -- ought to be=20
initialized, with a period, and separated by a space.  There is no=20
distinction between first and middle.

Bruce

[Refdb-users] Fwd: [MODS] MODS version 3.0

[Bruce D'A. <bd...@fa...>]

The LoC has finally released v3 final of MODS. This adds some crucial 
citation-oriented features.  I've put up a RelaxNG version at:

	http://www.users.muohio.edu/darcusb/files/mods-3-0.rnc

Bruce

Begin forwarded message:

> From: "Rebecca S. Guenther" <rg...@lo...>
> Date: December 10, 2003 3:50:51 PM EST
> To: MO...@su...
> Subject: [MODS] MODS version 3.0
> Reply-To: Metadata Object Description Schema List <MO...@lo...>
>
> Announcement: MODS Version 3.0 Available for Use
>
> The revised MODS schema version 3.0 is now available online
> at: www.loc.gov/mods/v3/mods-3-0.xsd. Mappings in both directions 
> between
> MARCXML and MODS as well as the Outline of elements and attributes also
> reflect version 3.0.
>
> Changes from the previous version 2.0 are documented
> at: http://www.loc.gov/mods/changes-3-0-final.html.
>
> The MARCXML to MODS stylesheet, guidelines, and examples will be 
> revised
> to reflect the new schema shortly. A stylesheet to convert MODS records
> using the 2.0 schema to 3.0 will also be available shortly.
>
> The revision is based on input from implementors and from others who 
> have
> participated in this list. Thank you all for contributing.
>
> For questions or comments, please email the Network Development and 
> MARC
> Standards Office at nd...@lo...
>
> The LC MODS Team
> December 10, 2003

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

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

Marc Herbert writes:
 > Let me reformulate: "lack of detail is better than wrong details". No
 > information is lost by storing all "given" names in <firstname> and
 > not parsing them.
 > 

You lose the information that a human brain can put into parsing the
name string, using cultural background information that is hard if not
impossible to teach to a machine.

 > A style sheet that mandates the use of "middlename" is, to put it
 > mildly, "culture-specific". If it insists on this, then it should be
 > able to extract this information _by itself_, and not spoils the
 > global data model because of this peculiarity. It seems this is
 > exactly how BibTeX's stylesheets work. References given in a previous
 > message seem to show that other formats do it the same way.
 > 

Once again, go complain to the publishers of roughly 5000 journals in
the life sciences. I 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. This simply
expresses your dislike of middle names.

 > I think this *requirement* is more or less flawed. The more
 > reformatting it requires, the more flawed it is, since the more
 > (wrong) assumptions it will make concerning "name standardization"
 > (i.e., that everybody should have a name that is american-english
 > looking).  The worst assumption is of course the requirement of a
 > <middlename>.  Assumptions about dots are also flawed, see for
 > instance: <http://www.delorie.com/users/dj/>
 > 

Once again, I didn't invent these requirements. I have to support them
if I want to support the 5000+ journals in the life sciences.

 > In any case, these dirty issues should not spoil the data model, they
 > should be (and can be!) postponed and solved by the stylesheets
 > _themselves_. So mistakes appear only in some printings, and there
 > are no irreversible mistakes in the data source.
 > 

I don't think it is a brilliant idea to have each of 700+ stylesheets
(if we consider only the life sciences for a moment) parse and munge
the names by themselves. Code duplication and bloating would be
inevitable. I'd rather have stupid simple stylesheets that use the
preparsed names from the application.

 > The rationale is here: if middlenames should be kept in the data model
 > (sigh), have at least only simple, perfectly reversible data
 > transformations in database operations. No dots that magically
 > appear or disappear, no variable number of tokens, etc. It's always
 > time to do this at the formatting step.
 > 

That's too late as I pointed out elsewhere. You need the normalization
when you enter the data into the database to have a consistent and
reliable way to search names.

 > ... and this normalization is too complex to be automated, since
 > no program can correctly handle all particular cases, thus it should
 > be manually carried out by operators.
 > I guess this is already the way it goes in most real cases today?
 > 

So if you want to import 100 references that a nice colleague just
sent you, you start adding/removing spaces and dots from somewhere
between 100 and 1000 author names? Problematic as it may be in border
cases, this is a job that *asks* to be automated. If it fails in too
many cases, we have to improve the code.

 > But searching for :AU:=3D"Miller,A.*M.*" will give a pretty good result,
 > and reveal to the operator the manual normalization work that must be
 > completed.
 > 

This is what a reference manager should avoid at all costs. Why on
earth should a user be forced to use regular expressions just to find
references by author names? If this is necessary the data model is
flawed.

regards,
Markus

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

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

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

Marc Herbert writes:
 > Thanks for supporting my argument with this excellent exemple ! :-)

My pleasure. But don't forget that this argument does not turn against
me as I'm not asking for middle names (I don't have one myself). It's
the publishers that ask for it.

 > I am NOT=A0asking to remove the concept of <middlename> down to every
 > refdb line code: I am just suggesting to postpone this concept to the
 > rendering stage, so it does not spoil the data model.
 > 

It does not spoil the data model to use a human brain for the parsing
of names. An unparsed name string is spoilt data.

regards,
Markus

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

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

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

Bruce D'Arcus writes:
 > 
 > First, a suggestion Markus: can you change the reply-to behavior to 
 > point to the list?
 > 

mailman allows to do this, but as Marc has pointed out, this behaviour
is not without problems. I personally hit reply-to-all and remove the
poster's address manually. This isn't elegant but you get used to it.

 > Let's consider examples:
 > 
 > James C. Scott
 > 
 > So we could have:
 > 
 > 1)
 > 
 > <first>James</first>
 > <middle>C.</middle>
 > <last>Scott</last>
 > 
 > 2)
 > 
 > <first>James</first>
 > <middle>C</middle>
 > <last>Scott</last>
 > 
 > 3)
 > 
 > <first>James C.</first>
 > <last>Scott</last>
 > 
 > 4)
 > 
 > <given>James C.</given>
 > <family>Scott</family>
 > 
 > 5)
 > 
 > <given>James</given>
 > <given>C.</given>
 > <family>Scott</family>
 > 
 > I find all of them problematic, frankly, because we don't have a way to 
 > know whether a name is initialized or not.  But I wonder if 5 wouldn't 
 > be a solution.  I personally would code it as 4 and expect the software 
 > and to figure out how to format it on output.
 > 

From my point of view 1, 2, and 5 would work. The latter will also be
the only way to deal with names in MODS, although it does allow to put
just about everything into one <given> element. My argument against 4
is that a stupid piece of software should not have to do much
guesswork as it will inevitably fail in some cases. Separating the
names instead of hoping that the users will enter them in a useful way
results in cleaner data.

regards,
Markus

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

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

[Bruce D'A. <bd...@fa...>]

OK, I just pulled out the Bible of citations: the Chicago Manual of 
Style.

Nowhere does it make any distinction between first and middle and last 
names.  Where it discusses names, it uses family and given, even when 
discussing styles in the life sciences.  To quote:

"In a reference list, especially in the life sciences, initials rather 
than full given names are often given...."

I guess I'm just not seeing the problem Markus.  If you have style that 
does not require initialization of given names, then it's irrelevant 
whether you have:

<given>James Christopher</given>
<family>Scott</family>

or ...

<given>James C.</given>
<family>Scott</family>

or...

<given>James</given>
<middle>Christopher</middle>
<family>Scott</family>

They would be formatted as complete strings.

Likewise, if your style requires initials, then you get the same output:

Scott, J. C.

If different styles require different spacing between the given name 
initials, or different punctuation, then it applies to all the given 
names, including the so-called "middle."

Right?

Bruce

Re: [Refdb-users] Reply-to Munging Considered Harmful

[Marc H. <mar...@en...>]

On Wed, 10 Dec 2003, Bruce D'Arcus wrote:

> > This guy argues that this is a bad idea.
> >
> >  <http://www.unicom.com/pw/reply-to-harmful.html>
> >
> > I mostly agree.
>
> I've had this argument pointed out to me. I just don't buy the user
> argument.  Yes, I can do the reply-to-all (as I am now), but the result
> is the recipient gets two copies of the same email.

... unless you delete it by hand. Whether you do it or not, I find the
inconvenience minor, compared to the damage of munging.

Question of taste ?

Re: [Refdb-users] Reply-to Munging Considered Harmful

[Bruce D'A. <bd...@fa...>]

On Wednesday, December 10, 2003, at 07:03  AM, Marc Herbert wrote:

>> From: Bruce D'Arcus <bd...@fa...>
>> Subject: Re: [Refdb-users] The case against <middlename>
>> Date: Tue, 9 Dec 2003 20:39:15 -0500
>
>> First, a suggestion Markus: can you change the reply-to behavior to
>> point to the list?
>
>
> This guy argues that this is a bad idea.
>
>  <http://www.unicom.com/pw/reply-to-harmful.html>
>
> I mostly agree.

I've had this argument pointed out to me. I just don't buy the user 
argument.  Yes, I can do the reply-to-all (as I am now), but the result 
is the recipient gets two copies of the same email.

Bruce

[Refdb-users] Reply-to Munging Considered Harmful

[Marc H. <mar...@en...>]

> From: Bruce D'Arcus <bd...@fa...>
> Subject: Re: [Refdb-users] The case against <middlename>
> Date: Tue, 9 Dec 2003 20:39:15 -0500

> First, a suggestion Markus: can you change the reply-to behavior to
> point to the list?


This guy argues that this is a bad idea.

 <http://www.unicom.com/pw/reply-to-harmful.html>

I mostly agree.



PS: I must admit I misused the Reply-To: header in one of my previous
messages.

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

[Marc H. <mar...@en...>]

On Tue, 9 Dec 2003, Markus wrote:

> However, the discussion about middlename forgets one fact that we
> can't simply ignore. While it might be desirable to drop middlename in
> order to make the markup more culture-agnostic, the main purpose of
> RefDB is to format bibliographies according to publisher's
> specifications. If you don't like middle names or middle initials,
> you'll have to file a motion with the publishers of scientific
> journals to remove these. In the life sciences approx. 99% of all
> journals use middle names or middle initials regardless of the
> cultural background of the authors. I've mentioned it previously that
> my friend Raman (who insists that this is his full name) appears as
> C.S. Raman on his papers for the sole purpose of having two initials.

Thanks for supporting my argument with this excellent exemple ! :-)


> RefDB must support middle names if it wants to be useful in the life
> sciences.

Sure.


On Tue, 9 Dec 2003, Bruce wrote:

> 4)
>
> <given>James C.</given>
> <family>Scott</family>
>


> I find all of them problematic, frankly, because we don't have a way to
> know whether a name is initialized or not.  But I wonder if 5 wouldn't
> be a solution.  I personally would code it as 4 and expect the software
> and to figure out how to format it on output.

That's exactly what I am suggesting.

I am NOT=A0asking to remove the concept of <middlename> down to every
refdb line code: I am just suggesting to postpone this concept to the
rendering stage, so it does not spoil the data model.

Cheers,

Marc.


PS: Markus, please do not let ugly bibliographers "standardize" our
names! :-( At least not up to databases.

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

[Marc H. <mar...@en...>]

On Tue, 9 Dec 2003, Markus wrote:

> In American English, where the middle initial is probably used most
> widely, the initial can also derive from the mothers maiden name or
> any other family name. You can't treat this as part of the first name.

Native americans in the office next door to mine treat it like this.
They just do not care where this middlename comes from: it is still a
"given" name. I think this formal definition:

 <familyname(s)> : universally defined by law
 <givenname(s)>  : parents (or similar) freely choose them, possibly
                   according to one local tradition or the other.

suits your example above.


>  > This is the apparent drawback. Suppressing an element means providin=
 g
>  > less information to subsequent tools. However, I think lack of
>  > information is better than incomplete/imprecise information. IMHO,
>
> I beg to differ. No information can't be better than partial
> information. If that were true, we should stop doing research and
> settle with the fact that we'll never know everything precisely.

Let me reformulate: "lack of detail is better than wrong details". No
information is lost by storing all "given" names in <firstname> and
not parsing them.


> At least in life sciences were not free to choose a stylesheet of our
> liking. If I want to publish in J.Biol.Chem., I'll have to follow the
> citation and bibliography rules of that journal. And if these rules
> tell me to format author names like "Last FM" (last name in full,
> first name and middle name, if available, as initials), then I must be
> able to pull a last, a first and a middle name from the stored data.

A style sheet that mandates the use of "middlename" is, to put it
mildly, "culture-specific". If it insists on this, then it should be
able to extract this information _by itself_, and not spoils the
global data model because of this peculiarity. It seems this is
exactly how BibTeX's stylesheets work. References given in a previous
message seem to show that other formats do it the same way.


> This entirely ignores that bibliography styles *require* to rearrange
> and reformat the name parts. Sticking with your example, journals
> might request:
>
> D Knuth
> D.Knuth
> D. Knuth
> DE Knuth
> D.E. Knuth
> Knuth D
> Knuth, D
> Knuth, D.
> Knuth DE
> Knuth D.E.
> Knuth, DE
> Knuth, D.E.
>
> and maybe another couple of permutations that I forgot. How Mr. Knuth
> would like to read his name is unfortunately irrelevant for the
> purposes of citing and creating bibliographies.

I think this *requirement* is more or less flawed. The more
reformatting it requires, the more flawed it is, since the more
(wrong) assumptions it will make concerning "name standardization"
(i.e., that everybody should have a name that is american-english
looking).  The worst assumption is of course the requirement of a
<middlename>.  Assumptions about dots are also flawed, see for
instance: <http://www.delorie.com/users/dj/>

However, simple transformations like : Donald ->=A0D. seem sensible (I
mean: not so flawed), and would allow most of your examples above.

In any case, these dirty issues should not spoil the data model, they
should be (and can be!) postponed and solved by the stylesheets
_themselves_. So mistakes appear only in some printings, and there
are no irreversible mistakes in the data source.



>  > Still want to hold on <middlename>s and make as little changes as
>  > possible? Then twist the original user input as least as possible, a=
nd
>  > do only perfectly reversible transformations: name parsing/splitting
>
>  > it based _only_ on spaces (I know no language where the size of spac=
e
>  > is meaningful), the output always gives those spaces back, and there
>
>  > is no "clever" parsing using dots, dashes or any other sign (can
>  > someone affirm that the dot "." is the universal abbreviation sign, =
in any
>  > language?)


> Spaces do not help to distinguish between family and other names.

Agreed! (even if BibTeX has a complex algorithm to do this, but let's
forget it...)

I was thinking of a 2-steps parsing:

1) separate given and family names using _comma_, just like it is
   today
2) then further parse each one using _only spaces_

The rationale is here: if middlenames should be kept in the data model
(sigh), have at least only simple, perfectly reversible data
transformations in database operations. No dots that magically
appear or disappear, no variable number of tokens, etc. It's always
time to do this at the formatting step.


>  > Users are generally not upset by a software that does NOT add a dot
>  > that they forgot, but they get angry when they do not understand
>  > at all how and why the software modifies their data, and then they
>  > write long emails :-) Moreover, complexity brings bugs; simplicity
>  > brings reliability.

> The process is called normalization. If you provide one entry as
> "Miller,AM" and the next one as "Miller,A.M.", these will show up as
> two different authors in the database. Normalization will result in
> "Miller,A.M." in both cases and will map the entries correctly to the
> same author.

... and this normalization is too complex to be automated, since
no program can correctly handle all particular cases, thus it should
be manually carried out by operators.
I guess this is already the way it goes in most real cases today?


> That is, searching for :AU:=3D"Miller,A.M." will not drop
> half of the available entries.

But searching for :AU:=3D"Miller,A.*M.*" will give a pretty good result,
and reveal to the operator the manual normalization work that must be
completed.


Cheers,

Marc.

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

[Bruce D'A. <bd...@fa...>]

First, a suggestion Markus: can you change the reply-to behavior to 
point to the list?

On Dec 9, 2003, at 8:08 PM, Markus Hoenicka wrote:

> However, the discussion about middlename forgets one fact that we
> can't simply ignore. While it might be desirable to drop middlename in
> order to make the markup more culture-agnostic, the main purpose of
> RefDB is to format bibliographies according to publisher's
> specifications. If you don't like middle names or middle initials,
> you'll have to file a motion with the publishers of scientific
> journals to remove these.

Let's consider examples:

James C. Scott

So we could have:

1)

<first>James</first>
<middle>C.</middle>
<last>Scott</last>

2)

<first>James</first>
<middle>C</middle>
<last>Scott</last>

3)

<first>James C.</first>
<last>Scott</last>

4)

<given>James C.</given>
<family>Scott</family>

5)

<given>James</given>
<given>C.</given>
<family>Scott</family>

I find all of them problematic, frankly, because we don't have a way to 
know whether a name is initialized or not.  But I wonder if 5 wouldn't 
be a solution.  I personally would code it as 4 and expect the software 
and to figure out how to format it on output.

I note that Peter's bibliofile DTD does not include middle names.  
Maybe this is worth exploring some more?

<!ELEMENT author (prefix?,name,name,name,suffix?)>
<!ELEMENT editor (prefix?,name,name,name,suffix?)>
<!ELEMENT name (prefix?,(%names;)*,suffix?)>
<!ELEMENT forename (prefix?,default?,suffix?)>
<!ELEMENT surname (prefix?,default?,suffix?)>
<!ELEMENT namelink (prefix?,default?,suffix?)>
<!ELEMENT genname (prefix?,default?,suffix?)>
<!ELEMENT rolename (prefix?,default?,suffix?)>
<!ELEMENT addname (prefix?,default?,suffix?)>
<!ELEMENT orgname (prefix?,default?,suffix?)>
<!ELEMENT placename (prefix?,default?,suffix?)>
<!ATTLIST author %format;>
<!ATTLIST editor %format;>
<!ATTLIST name %format;>
<!ATTLIST forename %format;>
<!ATTLIST surname %format;>
<!ATTLIST namelink %format;>
<!ATTLIST genname %format;>
<!ATTLIST rolename %format;>
<!ATTLIST addname %format;>
<!ATTLIST orgname %format;>
<!ATTLIST placename %format;>

Bruce

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

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

Bruce D'Arcus writes:
 >  From my understanding, it makes sense to remove middlename from risx, 
 > and change first and last to family and given, to allow for later 
 > internationalization (think xml:lang) and MODS.  This took my awhile to 

As I've pointed out occasionally, I'm not religious about element
names. Changing first and last to family and given might be more
intuitive, given that "first" and "last" do not appear in this order
in some cultures.

However, the discussion about middlename forgets one fact that we
can't simply ignore. While it might be desirable to drop middlename in
order to make the markup more culture-agnostic, the main purpose of
RefDB is to format bibliographies according to publisher's
specifications. If you don't like middle names or middle initials,
you'll have to file a motion with the publishers of scientific
journals to remove these. In the life sciences approx. 99% of all
journals use middle names or middle initials regardless of the
cultural background of the authors. I've mentioned it previously that
my friend Raman (who insists that this is his full name) appears as
C.S. Raman on his papers for the sole purpose of having two initials.
RefDB must support middle names if it wants to be useful in the life
sciences.

regards,
Markus

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

[Refdb-users] The case against <middlename>

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

Marc Herbert writes:
 > Whereas the distinction between <firstname> and <lastname>, is quite=

 > shared across different cultures, since it can easily and formally
 > defined as "given" name and "family" name, the notion of <middlename=
>
 > seems very culture-specific, and its inclusion in RISX brings more
 > issues than benefits. I suggest its suppression from the RISX DTD an=
d
 > the refdb databases (just like in other similar formats)
 >=20

Up-front: This is not going to happen.

 > In english, the middle name is a "second firstname", mainly used as
 > disambiguator.  It is more an extension of the <firstname> than a
 > first order part of the whole <author>. It may be only a nickname.
 >=20

In American English, where the middle initial is probably used most
widely, the initial can also derive from the mothers maiden name or
any other family name. You can't treat this as part of the first name.

 > * RIS (!) does not have it
 > <http://www.refman.com/support/risformat_tags_02.asp>
 >=20

They show a couple of middle initials and middle names in their example=
s.

 > * Formatting/sorting/... issues for subsequent operations
 >=20
 > This is the apparent drawback. Suppressing an element means providin=
g
 > less information to subsequent tools. However, I think lack of
 > information is better than incomplete/imprecise information. IMHO,

I beg to differ. No information can't be better than partial
information. If that were true, we should stop doing research and
settle with the fact that we'll never know everything precisely.

 > <middlename> carries a refinement that belongs only to a very detail=
ed
 > level of name representation (at least as detailed as the TEI=A0mode=
l).
 > Using <middlename> together with <firstname> and <lastname> is only =
a
 > halfhearted (and thus imprecise) attempt to more deeply parse the
 > name. And as shown above, the RIS input syntax is not ready for that=
,
 > (I mean: AU - Lastname[,(F.|First)[(M.|Middle)[,Suffix]]] is not
 > "clean"), and the RISX input is buggy.

Then let's fix it.

 > - About formatting
 >=20
 > LaTeX/BibTeX for instance performs a second stage parsing
 > (part=A0->=A0tokens) that relies on spaces, capitals and dots. It al=
lows
 > automated abbreviations among others.  The user can use a "hack"
 > (escape braces {} inlined in the data) to prevent any "too clever"
 > formatting. The need for this hack proves that the automated
 > formatting may fail to address specific cases. But at least the data=

 > model is simple and thus can't be wrong: all tokens of the complete
 > given name are stored together in the same string; if one stylesheet=

 > does the formatting wrong, another one may do it right.
 > <http://nwalsh.com/tex/texhelp/bibtx-23.html>
 >=20

At least in life sciences were not free to choose a stylesheet of our
liking. If I want to publish in J.Biol.Chem., I'll have to follow the
citation and bibliography rules of that journal. And if these rules
tell me to format author names like "Last FM" (last name in full,
first name and middle name, if available, as initials), then I must be
able to pull a last, a first and a middle name from the stored data.

 >=20
 > - About sorting
 >=20
 > The question is here: what do we do with:
 > "Donald Knuth", "Donald E. Knuth", "Don Knuth" (without dot!), "D. E=
. Knuth",...
 >=20
 > 1) I think the best answer is: nothing. The tradition in the BibTeX
 > world is:
 >   But an author's complete name may be "Donald E. Knuth" or even
 >   "J. P. Morgan"; you should type it the way the author would like i=
t to
 >   appear, if that's known.
 >=20
 > I think it is the responsibility of the author to "standardize" the
 > way his name is written across articles, and not the role of databas=
es
 > to try to make "clever" but very error-prone merges. Again, lack of
 > information is better than wrong information. Is it such a big
 > deal that the names above are seen as different? After all, they
 > will be sorted just one after the other and match together
 > fuzzy queries. And automated merges are still possible, but as an
 > _ultimate_ step, not corrupting the data and losing information in t=
he
 > first place.
 >=20

This entirely ignores that bibliography styles *require* to rearrange
and reformat the name parts. Sticking with your example, journals
might request:

D Knuth
D.Knuth
D. Knuth
DE Knuth
D.E. Knuth
Knuth D
Knuth, D
Knuth, D.
Knuth DE
Knuth D.E.
Knuth, DE
Knuth, D.E.

and maybe another couple of permutations that I forgot. How Mr. Knuth
would like to read his name is unfortunately irrelevant for the
purposes of citing and creating bibliographies.

 > Still want to hold on <middlename>s and make as little changes as
 > possible? Then twist the original user input as least as possible, a=
nd
 > do only perfectly reversible transformations: name parsing/splitting=

 > it based _only_ on spaces (I know no language where the size of spac=
e
 > is meaningful), the output always gives those spaces back, and there=

 > is no "clever" parsing using dots, dashes or any other sign (can
 > someone affirm that the dot "." is the universal abbreviation sign, =
in any
 > language?)
 >=20

Spaces do not help to distinguish between family and other names. Think=

of authors with double family names. Does "Luis Lopez Penabad" turn
into "Penabad, Luis L" or "Lopez Penabad, Luis" (the
latter). Providing the name as "Lopez Penabad, Luis" removes these
ambiguities (just as using the correct markup in XML does).

 > Users are generally not upset by a software that does NOT add a dot
 > that they forgot, but they get angry when they do not understand
 > at all how and why the software modifies their data, and then they
 > write long emails :-) Moreover, complexity brings bugs; simplicity
 > brings reliability.
 >=20

The process is called normalization. If you provide one entry as
"Miller,AM" and the next one as "Miller,A.M.", these will show up as
two different authors in the database. Normalization will result in
"Miller,A.M." in both cases and will map the entries correctly to the
same author. That is, searching for :AU:=3D"Miller,A.M." will not drop
half of the available entries.

regards,
Markus

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

[Refdb-users] compile problems

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

Bruce D'Arcus writes:
 > What does this mean?
 > 
 > checking for Perl module Text::Iconv... ./configure: line 5224: 17210 
 > Trace/BPT trap          $myperl -e 'use Text::Iconv;' >/dev/null 2>&1
 > configure: WARNING: Perl module Text::Iconv is required for some scripts
 > 
 > It -- along with problems compiling xml::parser -- seems to be majorly 
 > tripping up compilation of refdb on my laptop.
 > 

No, the missing Text::Iconv module does not influence the compilation
of RefDB. It is explained in some detail at the end of the configure
output. In brief, if you don't have Text::Iconv handy, some Perl
scripts that rely on this module will fail to run (and they will tell
you so).

 > # make
[...]
 > refdbd.c:40:54: dbi/dbi.h: No such file or directory

This is the real problem that screws up your compilation. Most likely
the include files end up in a directory which is not in the default
search path of your compiler. Setting the CFLAGS variable on the
configure command line appropriately might fix the problem, like in:

./configure <your options> CFLAGS="-I/usr/local/include"

regards,
Markus

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

[Refdb-users] compile problems

[Bruce D'A. <bd...@fa...>]

What does this mean?

checking for Perl module Text::Iconv... ./configure: line 5224: 17210 
Trace/BPT trap          $myperl -e 'use Text::Iconv;' >/dev/null 2>&1
configure: WARNING: Perl module Text::Iconv is required for some scripts

It -- along with problems compiling xml::parser -- seems to be majorly 
tripping up compilation of refdb on my laptop.

# make
Making all in src
source='refdbd.c' object='refdbd.o' libtool=no \
depfile='.deps/refdbd.Po' tmpdepfile='.deps/refdbd.TPo' \
depmode=none /bin/sh .././conf/depcomp \
gcc -DPACKAGE_NAME=\"\" -DPACKAGE_TARNAME=\"\" -DPACKAGE_VERSION=\"\" 
-DPACKAGE_STRING=\"\" -DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"refdb\" 
-DVERSION=\"0.9.4-pre2\" -DREADLINE42=1 -DSTDC_HEADERS=1 
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 
-DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 
-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 
-DHAVE_FCNTL_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_FILE_H=1 
-DHAVE_SYS_TIME_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_SYSLOG_H=1 
-DHAVE_UNISTD_H=1 -DTIME_WITH_SYS_TIME=1 -DRETSIGTYPE=void 
-DHAVE_STRFTIME=1 -DHAVE_MKFIFO=1 -DHAVE_GETHOSTNAME=1 -DHAVE_SELECT=1 
-DHAVE_SOCKET=1 -DHAVE_STRCSPN=1 -DHAVE_STRSTR=1 -DHAVE_STRTOLL=1 
-DHAVE_ATOLL=1  -I. -I.  -DSYSCONFDIR=\"/usr/local/etc/refdb\" 
-DULLSPEC=\"%qu\"   -L/sw/lib -L/sw/lib/libdbi.0.0.5.dylib 
-L/sw/lib/libexpat.dylab -c `test -f refdbd.c || echo './'`refdbd.c
refdbd.c:40:54: dbi/dbi.h: No such file or directory
In file included from refdbd.c:49:
backend.h:57: error: parse error before "dbi_result"
backend.h:57: warning: no semicolon at end of struct or union
backend.h:72: error: parse error before '}' token
backend.h:94: error: parse error before "dbires"
backend.h:95: error: parse error before "dbires"
backend.h:96: error: parse error before "dbires"
backend.h:97: error: parse error before "dbires"
backend.h:98: error: parse error before "request_notes_by_ref"
backend.h:98: error: parse error before "conn"
backend.h:98: warning: data definition has no type or storage class
backend.h:99: error: parse error before "conn"
backend.h:100: error: parse error before "request_links"
backend.h:100: error: parse error before "conn"
backend.h:100: warning: data definition has no type or storage class
backend.h:101: error: parse error before "dbires"
backend.h:102: error: parse error before "dbires"
backend.h:103: error: parse error before "dbires"
backend.h:104: error: parse error before "dbires"
backend.h:105: error: parse error before "dbires"
backend.h:106: error: parse error before "dbires"
backend.h:107: error: parse error before "dbires"
backend.h:108: error: parse error before "dbires"
backend.h:109: error: parse error before "dbires"
backend.h:110: error: parse error before "dbires"
backend.h:111: error: parse error before "dbires"
backend.h:112: error: parse error before "dbires"
backend.h:113: error: parse error before "dbires"
backend.h:114: error: parse error before "dbires"
backend.h:115: error: parse error before "dbires"
backend.h:116: error: parse error before "dbires"
backend.h:117: error: parse error before "dbires"
backend.h:118: error: parse error before "dbires"
backend.h:119: error: parse error before "dbires"
backend.h:120: error: parse error before "dbires"
backend.h:121: error: parse error before "dbires"
backend.h:122: error: parse error before "dbires"
backend.h:123: error: parse error before "dbires"
backend.h:124: error: parse error before "dbires"
backend.h:125: error: parse error before "dbires"
backend.h:126: error: parse error before "dbires"
backend.h:127: error: parse error before "dbires"
backend.h:128: error: parse error before "dbires"
backend.h:129: error: parse error before "dbires"
backend.h:130: error: parse error before "dbires"
backend.h:131: error: parse error before "dbires"
backend.h:132: error: parse error before "conn"
backend.h:133: error: parse error before "request_authors"
backend.h:133: error: parse error before "conn"
backend.h:133: warning: data definition has no type or storage class
backend.h:134: error: parse error before "dbires"
backend.h:135: error: parse error before "dbires"
backend.h:136: error: parse error before "request_users"
backend.h:136: error: parse error before "conn"
backend.h:136: warning: data definition has no type or storage class
backend.h:137: error: parse error before "dbires"
backend.h:138: error: parse error before "request_keywords"
backend.h:138: error: parse error before "conn"
backend.h:138: warning: data definition has no type or storage class
backend.h:139: error: parse error before "dbires"
backend.h:140: error: parse error before "dbires"
backend.h:141: error: parse error before "dbires"
backend.h:142: error: parse error before "Result"
backend.h:143: error: parse error before "Result"
backend.h:144: error: parse error before "Result"
backend.h:145: error: parse error before "dbires"
backend.h:146: error: parse error before "dbires"
backend.h:147: error: parse error before "driver"
backend.h:148: error: parse error before "dbires"
backend.h:150: error: parse error before "load_style"
backend.h:150: error: parse error before "dbi_conn"
backend.h:150: warning: data definition has no type or storage class
In file included from refdbd.c:50:
refdbd.h:23:19: expat.h: No such file or directory
In file included from refdbd.c:50:
refdbd.h:96: error: parse error before "connect_to_db"
refdbd.h:96: warning: data definition has no type or storage class
refdbd.h:118: error: parse error before "conn"
refdbd.h:119: error: parse error before "XML_Parser"
In file included from refdbd.c:55:
risdb.h:32: error: parse error before "dbi_conn"
risdb.h:34: error: parse error before "conn"
risdb.h:35: error: parse error before "dbi_conn"
risdb.h:36: error: parse error before "dbi_conn"
risdb.h:37: error: parse error before "dbi_conn"
risdb.h:38: error: parse error before "dbi_conn"
risdb.h:40: error: parse error before "dbi_conn"
risdb.h:41: error: parse error before "dbi_conn"
risdb.h:42: error: parse error before "dbi_conn"
risdb.h:43: error: parse error before "dbi_conn"
risdb.h:44: error: parse error before "dbi_conn"
risdb.h:45: error: parse error before "dbi_conn"
risdb.h:46: error: parse error before "dbi_conn"
risdb.h:47: error: parse error before "dbi_conn"
In file included from refdbd.c:58:
dbfncs.h:43: error: parse error before "conn"
dbfncs.h:44: error: parse error before "conn"
dbfncs.h:45: error: parse error before "conn"
dbfncs.h:46: error: parse error before "conn"
dbfncs.h:47: error: parse error before "conn"
dbfncs.h:48: error: parse error before "driver"
dbfncs.h:49: error: parse error before "conn"
dbfncs.h:50: error: parse error before "conn"
dbfncs.h:51: error: parse error before "conn"
dbfncs.h:52: error: parse error before "conn"
dbfncs.h:53: error: parse error before "conn"
dbfncs.h:54: error: parse error before "conn"
dbfncs.h:55: error: parse error before "conn"
dbfncs.h:56: error: parse error before "driver"
dbfncs.h:57: error: parse error before "dbires"
dbfncs.h:58: error: parse error before "dbires"
dbfncs.h:59: error: parse error before "conn"
refdbd.c:132: error: parse error before "dbi_style_res"
refdbd.c:132: warning: data definition has no type or storage class
refdbd.c: In function `main':
refdbd.c:173: error: `dbi_driver' undeclared (first use in this 
function)
refdbd.c:173: error: (Each undeclared identifier is reported only once
refdbd.c:173: error: for each function it appears in.)
refdbd.c:173: error: parse error before "driver"
refdbd.c:459: error: `driver' undeclared (first use in this function)
refdbd.c:463: warning: passing arg 2 of `log_print' makes pointer from 
integer without a cast
make[1]: *** [refdbd.o] Error 1
make: *** [all-recursive] Error 1

Bruce

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

[Bruce D'A. <bd...@fa...>]

On Dec 9, 2003, at 12:23 PM, Marc Herbert wrote:

> 1) I think the best answer is: nothing. The tradition in the BibTeX
> world is:
>   But an author's complete name may be "Donald E. Knuth" or even
>   "J. P. Morgan"; you should type it the way the author would like it 
> to
>   appear, if that's known.

But this is complicated by the fact that presentation of names is style 
specific.  It becomes a huge PITA, actually, because generally Donald 
E. Knuth becomes "Knuth, D. E." in a bib entry, or just "Knuth, D."  
I've actually gone to some length to track down full first names for my 
DB.

Bruce