Abbreviate author "Philip" into "Ph."

How would you do to have the first name of an author named "Philip Something" abbreviated into "Ph. Something" (rather than "P. Something"). How to tell Zotero to consider Ph as a single-letter when using abbreviated author styles?

I am coming from the BibTeX world where this could be done with a dummy command like author = {\singleletter{Ph}ilippe Something} where \singleletter does nothing else than outputting its argument but let BibTeX thinks that the whole \singleletter{Ph} is the 1st letter of the word. In this way, both the full name and the abbreviated name can be correctly generated by the style.

This may seem a bit futile in the case of Philip but:
- I know a Philip whose personal preference is to have "Ph." and I think this should be respected.
- Case like Philip St. John Russell pose a different problem since you certainly don't want St. abbreviated as S. But maybe entering a multiple letter initial like St. in a first name field tells Zotero to keep it that way (haven't tried). But for the Philip guy, sometimes I want the full name.

Any idea? Is that a feature request?
  • I don't know how this is handled in current Zotero, but in a new CSL processor that is now under development, enteriing the name as "PHillip" in the database will produce the correct full form (Philip) and the correct abbreviated form (Ph.).

    Frank Bennett
  • in a new CSL processor that is now under development, enteriing the name as "PHillip" in the database will produce the correct full form (Philip) and the correct abbreviated form (Ph.).
    Wait, was this discussed on XBib? We wouldn't support this method of abbreviation in Zotero, at least as far as values stored in the database are concerned. (Data exchange, etc.) If it's just the interface to the processor, that might be OK, though it seems a little kludgy.
  • True. It's in the test suites, but it hasn't been explicitly discussed, and I think when it is put on the table there will be similar objections. But the use case does come up. The Mongolian name Tsurdendordjiin (a common patronymic that serves the role of a "first name") is abbreviated "Ts." I should hold comment here until the way to handle the use case has been fully settled.
  • Yeah, I dislike the idea of mangling the data this way just to get something like an output initial. If people care about this, it should be stored separately it seems to me.

    A more troublesome (and practical) issue is proper nouns in titles.
  • A more troublesome (and practical) issue is proper nouns in titles.
    That one leads back to our ongoing discussion of flip-flops and semantic markup.
  • edited April 23, 2009
    If I understand correctly, there is currently no way of handling this, right? And there is no consensus on how to handle this in the future, but it is somewhere on the table. Am I correct? Any idea on how this might evolve, and over which timeframe? Any discussion I could participate to? Would it be part of the 1.5 release?

    [ it should be stored separately it seems to me. ]

    And what do you mean by the above? [And how do you quote things from the forum with a nice dashed box??]

    The last comment on proper nouns in titles is indeed a similar issue (protecting capital), like "Stimulated Raman scattering".

    I must add that it is not just capitals that need to be protected. Units in titles should be somehow protected as well. "A 720 nm laser" should NOT be title-cased in "A 720 Nm laser". Here "nm" stands for "nanometer" whereas "Nm" would be "Newton times meter", which is a torque (I am a physicist, sorry). I haven't seen any discussion on this yet. Some case would be ok. I guess both "km" and "Km" are accepted.

    I would support something simple and common to handle all those cases. Like putting things in between curly braces, e.g. (idea from BibTeX of course, but you might have other things in mind). Then we could have

    {Ph}ilip Something
    Stimulated {Raman} scattering
    A 720 {nm} laser

    You may say it looks ugly but then what else could we have? Mouse-Select a part, right-click, context menu "Protect case" or whatever seems a little bit cumbersome for me. I would prefer some mark-up. And the mark-up could actually only show up when you click on the field to edit it, but be otherwise invisible.

    Finally, I have seen some case where a paper is authored by D. Knuth (and written as is in abbreviated form on the paper), but then you know that the guy is actually Donald Knuth, so BibTeX recommends encoding "D[onald] Knuth" so the system knows that the author was abbreviated on the paper. Some styles insist that you should write the authors as on the paper, sometimes abbreviated, sometimes in full, in the same reference list, depending on what was on the paper. But then some other style might need to be sure that D. Knuth and Donald Knuth are the same person.

    Anything like that in the thought basket? Note that I am not much concerned about that case. It's just related to the Ph. problem so I thought I would put it here for completeness.
  • edited April 23, 2009
    for quotes, using the Html option

    <BlockQUOTE>quoted text</BlockQUOTE>
  • [ it should be stored separately it seems to me. ]

    And what do you mean by the above?
    An (optional) "initials" field for contributors. This has the advantage that it could be extended for organizations as well.
    I would support something simple and common to handle all those cases. Like putting things in between curly braces, e.g. (idea from BibTeX of course, but you might have other things in mind).
    This is exactly the solution I was objecting to.

    ...
    You may say it looks ugly but then what else could we have? Mouse-Select a part, right-click, context menu "Protect case" or whatever seems a little bit cumbersome for me.
    This is just a UI question. I'm concerned with the cleanness of the data behind it. There are many ways to deal with the user input, and perhaps a distinction between the wiki-like markup and the contextual-menu approach, where both yield more-or-less equivalent results internally, is the right approach.

    ...
    Finally, I have seen some case where a paper is authored by D. Knuth (and written as is in abbreviated form on the paper), but then you know that the guy is actually Donald Knuth, so BibTeX recommends encoding "D[onald] Knuth" so the system knows that the author was abbreviated on the paper. Some styles insist that you should write the authors as on the paper, sometimes abbreviated, sometimes in full, in the same reference list, depending on what was on the paper. But then some other style might need to be sure that D. Knuth and Donald Knuth are the same person.
    To me this stuff is just silly. An author is an author, and how their name should be output is a product of the output style. As a practical matter, contributors should be treated as full data and UI objects, not as strings. This allows them to be referenced, and for additional data (addresses, affiliations, etc.) to be attached to them.

    This isn't BibTeX, and that's a good thing.
  • edited April 23, 2009
    I can understand your point regarding the cleanness of the internal representation, but in my original post I was actually just thinking about how to input things. You may dislike curly braces because of their BibTeX origin, but using curly braces or a wiki like mark-up seems the same to me. It's just a different input syntax. As far as user input is concerned, the lighter, easier to type, easier to remember, the better. I am open, I was just using curly braces as an example of mark-up. If after that the internal representation becomes <firstname initial="Ph">Philip</firstname>, fine, it's just that I don't want to type that stuff.

    To be honest, I think Zotero is a fantastic product. It has really changed my life as far as collecting refs in journals is concerned. I certainly don't want to impose all the BibTeX idiosyncrasies on Zotero and I totally understand the will of the development team to keep it as general as possible and to not focus on any particular system, whether LaTeX or others.

    However, despite all the oldness and limitations of BibTeX, it nevertheless constitutes a system that through many years (2 decades?) has been able to handle all sort of complicated and tricky cases with relative simplicity and pretty much without evolution, and yes, even silly requirements of publishers. There is certainly some good ideas in there that could be borrowed and adapted for Zotero somehow. You may think of the D[onald] example as silly, but if a journal comes with such requirement, you will have to find a way to do it. Manual editing the final ref list is always a possibility, but you want to keep that to a minimum.

    You will never think of all what the users could have or will have in mind, and how they will try to use Zotero for unplanned purposes. So the system should stay open-minded.
  • You may think of the D[onald] example as silly, but if a journal comes with such requirement, you will have to find a way to do it.
    Really? How many styles have this requirement? Of those styles, how many of their copy editors will actually check how the name was input on the original article, and then insist you fix this?

    In my experience, there's more flexibility on these issues than people assume, and that as a general rule, it's never wrong to put in more information than is strictly required.
    You will never think of all what the users could have or will have in mind, and how they will try to use Zotero for unplanned purposes. So the system should stay open-minded.
    Not if it causes other problems elsewhere. This is a perfect example. Treating contributors as dumb strings has other costs.

    BTW, I'm not a Zotero developer exactly; am the author of the citation style language it uses for formatting configuration.

    I'm also a publishing scholar, and a former BibTeX user who found it inadequate ;-)
  • For the Ph. case, I like the idea of a separate field, to handle this issue plus abbreviated institutional names. It will complicate things behind the scenes (since it would then have to apply differently to different name types) but it's the processor's job to absorb that variety of pain. I hope we can discuss this in xbib before CSL 1.0 is cleared.

    For the other sub-field formatting issues, I hope that an accommodation can be reached about in-field wiki markup for use in Zotero. Unless there is a more robust and visually appealing solution on the stocks that I haven't heard about, it seems the only way to address some very common user concerns in the short to mid term.
  • It is on our todo list.

    I'm concerned with a solution that works not just for low-level output, but for data storage and import/export, search, display (particularly on the web), etc. It seems logical that (X)HTML is an important part of that picture, since it has more low-level formatting structures, but also has higher level semantics (the class attribute, and more recently the ability to embed RDF triples via RDFa).

    But that doesn't mean a wiki markup shouldn't be one way to achieve this sort of micro-formatting.
Sign In or Register to comment.