Whatever the particulars that end up getting decided upon, will there be any way to override? Whether through specifying in the CSL file, since not all styles have the same rules, or through the format of the name itself in the database? I'm thinking of BibTex, which allows you to put {Curly Brackets} around things you don't want changed, for example. I'd like to see a system that allows for maximum flexibility so that we can tailor the citations and bibliography to what a publishing venue asks for.

Pardon my ignorance, but what is the benefit of the new system over the old "dropping with the given name, non-dropping with the family name" system?

The librarians have very specific rules about how to normalize a name. There might be other variants, which nowadays with search engines can be found as well, however in times with card catalogues that was different.

My knowledge here is limited, but I can give you some insight about the German system RAK-WB:

Main rule: the normalization depends on the nationality of the author. E.g.

• the French mathematician Alembert, Jean Le Rond d'


• the Italian D'Annunzio, Gabriellino


• the (old) Italian Afflitto, Matteo d'


• the American D'Arcus, Bruce

There are a lot of other examples with different prefixes and more languages, see § 314a.

Prefixes/suffixes that are representing relations (e.g. Abu, Ibn, Bar, Neto, Uly) are always belonging to the family name, see § 316.


Question: Can you really deal with all that cases in one list? Or how would we like to define the standard here?

I don't think this should be part of citeproc (in an ideal scenario). It's up to the front end (Zotero) to provide the means for the user to indicate dropping/non-dropping parts or do the parsing automatically and pass the separate parts to citeproc.

Citeproc-js could provide a convenience function that could help automate the parsing and help unify behavior across different front ends. Though in the mean time, while all the details are figured out, I don't see a problem with just incorporating this in the main pipeline.

(I think "Wernher von Braun" is seen as an American and not German and therefore it is Von Braun, Wernher.)

(there's a long and unresolved tussenvoegsel discussion here. Rather untractable:
https://forums.zotero.org/discussion/27822/2/von-van-de-in-authors-name-appear-as-von-van-de/ )
I think aurimas and nickbart are right on principle -- it'd be much better to properly handle this in the reference manager and don't require parsing from citeproc that, it appears, may just not always be possible. But we also have to deal with the current situation, so we might as well get this as right as possible in citepro-js.

For the original list, "des" as part of a German name is incredibly rare. You can just disregard that case.

So now you see why I opened this thread - this is what my mail queue on this subject has looked like.

Keep the comments coming, this is all very useful. I won't respond on policy issues, but when I have code that threads the needle as best may be, I'll post again.

(Re first/last allotment: Yep.)

Okay, trial versions of citeproc-js with the new particle parser are up now in the processor patch plugin and the uppercase gadget.

Not much detail to report. You can see the list of particles (with lots of numeric parameter clutter, sorry about that) here. At the user end, it's enough to know that particles are "more sticky" if placed at the start of the last-name field, and "less sticky" if placed at the end of the first-name field.

On parsing behaviour, particles at the end of the first-name field must either be all lowercase, or must be separated by a comma. It's done that way to avoid false positives on initialized names.

Particles at the front of the last-name field can be uppercase or lowercase, it doesn't matter to the parser.

Particles that the parser thinks are always dropping or always non-dropping are always set that way, no matter how they are entered. So "de la" will always set "de" as dropping, and "la" as non-dropping.

Particles that the parser thinks might be dropping or non-dropping are set according to the field in which they occur (i.e. last-name = non-dropping, first-name = dropping), if there is an exact match (ignoring case as described above). If there is not an exact match in both positions (possible with two-element particles), the parser will choose what it thinks is the most likely assignment.

The one case that this will not handle is names that have a particle-like element that is actually part of the last name ("De Quincy"). There isn't much I can do about that, unfortunately.

Some more prefixes for your list:
* "af", e.g. Geijerstam, Gustaf af
* "aus der", e.g. Au, Otto aus der
* "in der", e.g. Gand, Hanns in der
* "auf der", e.g. Maur, Paul auf der
* "von und zu", e.g. Urff, Georg Ludwig von und zu
* "vom und zum", e.g. Stein, Karl vom und zum
* "aus'm", e.g. Aus'm Weerth, Ernst
* "dall", e.g. Dall'Ongaro, Francesco
* "de'", e.g. Medici, Lorenzo de'
* "degli", e.g. Uberti, Fazio degli
* "dei" and "de li"
* "'s-", e.g. Gravesande, Goverdus 's-
* "'t", e.g. Hoen, Pieter 't
* "z" and "ze", e.g. Zerotina, Karel ze

I started testing the new processor gadget. A big thank you, fbennett, but (of course) also a few questions and suggestions:

First, is there any reason why Zotero could not copy the new parsing mechanisms, and output parsed names by default itself?

Second, unexpected behaviour of the new gadget:

Particles as part of the family name

From http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#particles-as-part-of-the-last-name:

“To suppress parsing and treat such particles as part of the family name field, enclose the family name field content in double-quotes:”

{ "author" : [
    { "family" : "\"van der Vlist\"",
      "given" : "Eric",
      "parse-names" : "true"
    }
  ]
}

Is this still expected to work? (Currently, with the new processor gadget, it does not seem to.)

My suggestion would be to (1) keep this double quotes convention, and (2) introduce a new option to use a non-breaking space between family names parts to keep them together if needed, e.g., between ‘De’ and ‘Quincey’ (highly unobtrusive, but also not very obvious; still, I'd prefer this very much …).

al-

‘al-Hakim’/‘Tawiq’ in Zotero’s surname/firstname fields is rendered as ‘Hakim, Tawiq al-’ (using chicago-author-date.csl); ‘Hakim’/‘Tawiq al-’ yields the same result. With ‘al-’ at the start of the surname field, I would have expected ‘al-Hakim, Tawiq’ (which is also what CMoS 16, 8.14, wants).

Assimilated forms of ‘al-’, such as ‘at-’, ‘an-’, ‘ash-’ (which were reported to be working before; https://forums.zotero.org/discussion/28457/arabic-names-with-the-particle-al/) do not seem to be parsed properly either; neither do forms with diacritics, such as ‘aṭ-Ṭūsī’.

van / Van

‘van Gogh’/‘Vincent’ (using chicago-author-date.csl): ‘Van’ is capitalised in the reference list (‘Van Gogh, Vincent. 1983. …’) but not in the in-text citation (‘(van Gogh 1983)’). CMoS 16, 8.10, seems to suggest that ‘van’ should always be capitalised unless preceded by a first name.

Third, a suggestion for Zotero:

parse-names flag

http://gsl-nagoya-u.net/http/pub/citeproc-doc.html#id28 says that simple two-field entries should be parsed (to identify particles and suffixes) only when a ‘parse-names’ flag is present, as in:

{ "author" : [
    { "family" : "van Gogh",
      "given" : "Vincent",
      "parse-names" : "true"
    }
  ]
}

I would strongly suggest that Zotero should add this ‘"parse-names" : "true"’ flag to all unparsed two-field name elements (but not to ‘literal’ names, of course) when exporting to CSL JSON. (As soon as Zotero starts exporting parsed names, this could of course be removed again.)

In particular, this is essential for pandoc-citeproc, since pandoc-citeproc needs to be able to distinguish unparsed CSL JSON (e.g., obtained from Zotero) from already parsed CSL JSON (e.g., created from bibtex/biblatex via ‘pandoc-citeproc --bib2json’.

Fourth, documentation. Do we have anything already? (‘Names’ in https://www.zotero.org/support/getting_stuff_into_your_library doesn’t have anything on particles.) What's most important? (The first item on my list would be pointing out that names such as ‘De Quincey’ and ‘Van Rompuy’ (which do not contain particles, and should always be sorted under ‘D’ and ‘V’) must be protected, at least in the current setup.)

@nickbart: Thanks very much for this feedback. On the input and field markup details, could you repost to the xbiblio-devel list? I'm trying to get out of the ad hoc hackery game at this point - if the CSL group arrives at a set of preferences for how name formatting hints should be delivered in the input, I'll be happy to implement the recommendations in the processor.

(On the quotes issue, I'm not sure; I may have removed it after complaints about the design [or lack thereof].)

In France, main rule: the normalization depends on the nationality of the author. As for French names, only « d' » and « de » are dropping-particles.

http://www.culture.gouv.fr/culture/inventai/extranetIGPC/normes/constit_normesbiblio.pdf => p. 41 (Ministry of Culture, France, extracted from an AFNOR standard)

I'm a bit sceptical, but I will test the gadget, and look at the results with the different values of demote-non-dropping-particle…

Edit: just "for fun", an old (1998) article on this subject.

Frank: I had posted it before but this might be of interest (not OCR'ed unfortunately):
Names of Persons. National Usages for Entry in Catalogues. 4th rev. and enl. edition. München : K. G. Saur, 1996. ISBN 3-598-11342-0

Thanks, that might be handy to have- so long as I'm not the only one with a copy. As I wrote in response to @nickbart's post above, I'm trying to get out of the ad hoc hackery game at this point. Names handling is important, but it really needs to be driven by parameters set in CSL. The new processor code is a step toward allowing that to happen, so that processor implementers (myself included) can take comfort in sticking to the requirements.

You can see the list of particles (with lots of numeric parameter clutter, sorry about that) here.

Particles that the parser thinks are always dropping or always non-dropping are always set that way, no matter how they are entered.

I'd like to understand the logic here and it's difficult with these numeric paramaters indeed :-) Could you provide a list of the particles which should have a consistent behaviour (i.e. which are always dropping or non-dropping for the parser) please?

On parsing behaviour, particles at the end of the first-name field must either be all lowercase, or must be separated by a comma.

e.g. : "Jean, De" ? (it is just an example)

The one case that this will not handle is names that have a particle-like element that is actually part of the last name ("De Quincy").

I don't follow. What's the problem with "De Quincey"? Sorting?