Separate fields for Title and Subtitle

2»
  • And I'm still opposed to this, in part for a few reasons I didn't earlier state, which can be summed up with this question: if we split titles into separate data structures, how will we support multiple titles in different languages (transliterations, translations, etc.)?

    Right now, it's easy to extend the current RDF import/export support to cover this:

    <http://example.org/1>; a bibo:Book ;
    dc:title "Un Titulo: Y Un Subtitilo"@es ;
    dc:title "A Title: And a Subtitle"@en .


    If we were going to split the titles, it would probably require completely different, more complex, modeling (in RDF, a title would become a discrete subject/class; in a relational database, it'd be modeled in its own table, etc., etc.); complexity whose benefit is simply not worth the cost in my view.

    On:
    The punctuation and spacing separating title from subtitle are elements of metapunctuation; they are not intristic to the titles themselves.
    Well, not always true. Consider a title, which is unfortunately fairly common in my field, like:

    Let's ask a question? And then we have the subttile
    So in this case, the '?' is "intrinsic" to the title.

    That TEI (and MODS) does this is not really a compelling argument to me.

    All this aside, I don't have any formal authority in this project. But I do in the design of CSL, and I have no intention of changing things anytime soon.
  • Bruce,

    What do you say to Dan's suggestion above? The title field can contain both elements, shortTitle can be used to identify the primary title segment, and the remainder of the field can be taken as subtitle, accessible via a virtual field, along the same lines as currently done for page-first. This would not require any change to input data, and would satisfy the need for discrete formatting of subtitles in some language domains. All that would be required is the recognition of a subtitle variable in CSL; the processors can do the rest.
  • That might be an option IF we establish the use case for separate subtitle styling.
  • Perhaps some German users can offer links to relevant style guides.
  • Not being a programmer, I can't comment on the issue of complexity.

    The question-mark example, however, plays in my favor. Consider sentences such as "I bought stock in Yahoo!" and "Would you try that search in Yahoo!" In both examples two punctuation marks should theoretically end each sentence. But the stronger exclamation mark overwhelms the period in the first example and the question mark in the second. Why? Because when two punctuation marks coincide modern English speakers tend to prefer to keep only the stronger one, with the second one understood. This is punctuation crasis at work.

    Thus, in the title What—Me Worry? Life in the Fast Lane with Alfred E. Neumann there is an understood "?:" that is elided to "?" But some presses choose to avoid the crasis and use something of a punctuation diphthong. It's most commonly seen in the construction ?, to separate a title from subsequent citation data. Some publishers and groups (including Zotero) use the punctuation diphthong, contra CMS. Do I agree with this convention? No. CMS makes sense here. But I think it's a user's right to decide whether or not crasis should occur. The best way to give freedom in this area is to move the punctuation distinguishing title from subtitle and subtitle from sub-subtitle into the realm of metapunctuation.

    To this question...
    if we split titles into separate data structures, how will we support multiple titles in different languages (transliterations, translations, etc.)
    ...I would in turn ask how it's been done with personal names. After all a name, like a title, is broken up into surname and first name, with the latter somehow subservient to the former (just like the subtitle is to the title). Why couldn't the components of a title be modeled on the personal name and its components?

    One more advantage to creating the sub/title distinction is that it would allow presses who as a rule drop sub-subtitles from their references do so quickly and easily.

    I predict that as more people from the humanities start to use Zotero you'll see the issue revisited, and more voices added to this thread in favor of felwert and me. Why do such refinements have to happen "now or never"? This seems a bit short-sighted. (My greetings to readers fifty, one hundred, and two hundred years from now reading this thread, probably in amusement.)
  • Not being a programmer, I can't comment on the issue of complexity.
    Fair enough. But it does have very practical implications for all manner of details in how the software practically works.
    ...I would in turn ask how it's been done with personal names. After all a name, like a title, is broken up into surname and first name, with the latter somehow subservient to the former (just like the subtitle is to the title). Why couldn't the components of a title be modeled on the personal name and its components?
    To go back to my "complexity" point earlier, complexity has costs. Treating personal names as discrete components tends to be critical for really basic things like sorting a bibliographic list. So we deal with some added complexity (in the UI, and in the data layer, for example) because it's necessary.

    The case for splitting title and subtitles is simply less clear, and so the justification for the added complexity is also unclear.
    I predict that as more people from the humanities start to use Zotero you'll see the issue revisited, and more voices added to this thread in favor of felwert and me. Why do such refinements have to happen "now or never"? This seems a bit short-sighted. (My greetings to readers fifty, one hundred, and two hundred years from now reading this thread, probably in amusement.)
    A few things:

    First, many people responsible for the existing design are from the humanities. In my case, I'm a publishing scholar who works at the borders of the social sciences and humanities. And the project was started by historians.

    Second, Zotero has been in use for five years now, with hundreds of thousands of users, a large percentage of which (I don't know how large) come from the humanities. So I would think if there were going to be such a chorus of voices expressing frustration over this design feature, they would have materialized already.

    Third, of course any ideas presented can be for future consideration. I'm just giving my position on this, as someone trying to maintain and develop a key piece of technology Zotero uses (CSL) in ways that aren't limited to Zotero. This means having to balance a lot of different interests, including the need for a certain manner of stability.

    I would just conclude by saying that it would be helpful to document the requirements you see for this in utterly concrete ways ("in this style, we need to format a bibliography in X way and doing so with the current system is completely impossible for Y and Z reasons" and so forth).
  • And by no means are people completely happy with the current model for names. Names are more complicated than one or two fields can reasonably hold-- Zotero, like much software, makes some assumptions about name structure that don't hold internationally.

    I think we can find a solution here-- but I'm not sure yet what. We really need more examples of how subtitles and punctuation are handled in various national traditions.
  • I'm currently making the Zotero format for the Pontifical Biblical Institute. They require that a book title be formatted in italics, while the book subtitle be formatted in regular type. Both fields are considered required.

    Documentation of the style used at the Pontifical Biblical Institute can be found in "A Guide to Biblical Research" by Stanislaw Bazylinski (http://www.biblico.it/pubblicazioni/sb36_bazylinski_engl.htm).

    Any suggestions of how I can make this happen, or workarounds if Zotero does not yet support this? Thanks.
  • edited November 2, 2011
    @Devin Roza
    I can suggest a (strange) workaround. If there is a field that you never use, you can put the information of the subtitle in that field and adapt your Style to add that information in the place and the format that you need.
    I'm currently using the field "Archive" for that, and get the output with the code: <text variable="archive"/>
    An obvious warning: you can't use that field for its original purpose, all the items without subtitle must have the field empty. In any case, that only applies to the items you are actually using in your work.
  • I'm currently making the Zotero format for the Pontifical Biblical Institute. They require that a book title be formatted in italics, while the book subtitle be formatted in regular type. Both fields are considered required.
    Hmm ... to my request above for concrete examples, this is a good one.

    There's no way to accommodate this without less-than-ideal and awkward hacks (javimat's is one example; another is to wait until you're completely finished with your document, create a copy, strip fields, and edit the subtitles manually).
  • Thanks for the suggestions. I think I will try the awkward hack that javimat suggested for the moment (THANKS!), as I need to get this field working.

    Here is a link to partial online instructions for the Pontifical Biblical Institutes scientific journal "Biblica". It includes a reference to the subtitle requirement for "Colleted Works and Festschriften", and an example or two as well (cf. page 3 of the PDF file). http://www.bsw.org/statics/Biblica_EICr7.pdf

    The complete manual I made reference to in the message above (A Guide to Biblical Research by Bazylinksi), which is the official guide for students of the institute and for their journal, states that apart from Colleted Works and Festschriften it is also necessary to include it for Books and Journal Articles as well. In general for books they require the title in Italics and the Subtitle in normal text, while for Journal Articles they just ask for a period between the Title and Subtitle, all in normal text in quotes.
Sign In or Register to comment.