Just Launched: You can now import projects and releases from Google Code onto SourceForge

We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More

Close

primary sources pt 2: citation styles

2010-09-28
2013-05-28
  • I hope and think this is a more feasible request than the one suggested in my previous post. Let me use an example first. In books on e.g. medieval literature you may find a separate list of primary sources in a format such as the following:

    The Fortunes of Men,
    ed. G. P. Krapp and E. V. K. Dobbie, The Exeter Book. The Anglo-Saxon Poetic Records 3. New York: Columbia U. P., 1936. page numbers.
    tr. T. A. Shippey, Poems of wisdom and learning in Old English. Cambridge, 1976. 58-63.

    i.e.

    1. The Fortunes of Men (an anonymous Old English poem) = the primary text
    2. comma + ed. / ed. and tr. / tr.
    3. names of those who edited and/or translated the text (first name first), + publication (e.g. book article, journal or book)
    4. Note that this may be followed by a translation or yet another edition/translation or whatever (here the translation by Shippey)

    There's currently no way of adopting this method in refbase, but I was thinking of a relatively straightforward solution which does not require the creation of an additional citation type but which does require a couple of modifications to the citation style / output:

    * for all citation types, add an extra field for primary author (though unnecessary in the example above) and primary text
    * in the citation (output) style, make sure that these come first when specified, followed by ed./tr./ed. and tr. and the name(s) of the editor(s)/translator(s) in the proper order – first name, then last name.
    * when there is more than one edition/translation for a single text, create a new entry for the modern publication but with the same text. In the citation (output) style, treat the combination of primary author and primary text in the same way as you would modern authors/editors: i.e. so that the repetition of a title produces a string of dashes instead (not otherwise implemented as far as I’m aware though).
    * preferably, in the citation (output) style, include “notes” at the end of the reference

    Regards,
    contrafibularity

     
  • I'd like to separate questions of what would need to change at the database level from those that would need to change on the citation-generation level.

    For the database level: there is presently no accomodation of title (or other field) translations.  We're not unique in this limitations.  Some people denote this manually.  There is presently no way to denote a translator contributor type.  There is also no semantic way to relate multiple records.  It seems like these would be the most sensible improvements to make.  Regarding your suggestion:

    for all citation types, add an extra field for primary author (though unnecessary in the example above) and primary text

    I disagree, as these would not be used by most records.  The changes I enumerated are better & using a pre-existing field (such as just "title", which is what nearly all flat reference managers use) to convey primary source information can already be an immediate work-around with no code changes & apparently few disadvantages compared to your suggestion.

    The citation processor that refbase uses (and citeproc-php, a CSL processor that we may eventually migrate to) already allows the reordering of fields and the use of the notes field.  You just need to write your custom style.  I don't know if we have support to replace redundant information, but I think that citeproc might.  This particular change would probably not be that difficult, assuming the database changes above (which are a bit more difficult).

     
  • Thanks again.

    Are you saying that whether the contributor(s) - to use a general expression - is editor, translator, both editor and translator or none of the above, is or should be a database issue? In Endnote, I‘ve worked around its limitations by adapting one of the unused fields and manually add “ed.”, “tr.” or “ed. and tr.”, but your approach sounds better: (1) no extra (unsupported) fields, just two check boxes (?), and (2) citation styles can still render the same bit differently (e.g. “X, ed. and tr. Y” or “X, edited and translated by Y” or “Y (ed. and tr.), X”). A minor trifle: what if one contributor has edited the text, while the other was responsible for the modern translation?

    More generally speaking, limitations in terms of the number of database fields available and their purpose are indeed quite common across the current range of reference managers. Endnote appears to offer more database fields than BibTex and also allows for the possibility to adapt/rename both pre-existing and custom fields for a specific citation style (under 'preferences'; not sure if that’s still database-level though). But if your aim is to provide support for multiple exports such as BibTex records, which must be difficult enough as it is, then no doubt those extraneous or remapped but vital fields are going to be a pain in the neck. Or they are simply not generated.

    Oh, and any improvements when it comes to relating records would be a net plus, absolutely.

    As for using "title" to denote the primary source instead: I've previously thought of using that system elsewhere, but one would have to shift all contributor/contribution information to different fields, one level up as it were. To convert pre-existing entries would require a lot of work and it won’t solve the problem of missing fields I’m afraid. Take the example of a book article:
    * The author of the work (primary source) would become the "author" of "title"
    * The editor(s) and/or translator(s) responsible for the article would become the "editor" of the "publication"
    * the editor of the book would become the "series editor" of the "series title"
    * the actual series editor, series title and series volume are simply out of luck. There are no 'quartary' categories as far as I'm aware.

    That's why - instead of creating custom fields for this fourth category - I would still prefer to use and rename any of the redundant fields, such as "corporate author", "address" or "expedition", for primary sources and incorporate them in a custom citation style. If the consequence is that BibTex can’t accommodate this information (properly or not all), then so be it. The decision whether or not to work within the confines of supported formats would perhaps be the responsibility of the institution/person using Refbase on his website.
    (The underlying problem here is that there’s no permanent solution supported by all current formats, so whatever we do it will be a workaround anyway. )

     
  • Are you saying that whether the contributor(s) - to use a general expression - is editor, translator, both editor and translator or none of the above, is or should be a database issue?

    Yes (albeit a very common one, as you point out).  The type of contribution can be denoted in some export formats & does matter for some citation styles.  That isn't to say I'd expect it to be addressed in refbase in the near future; just that it is a known issue.

    Endnote appears to offer more database fields than BibTex and also allows for the possibility to adapt/rename both pre-existing and custom fields for a specific citation style

    Quite the contrary, actually:  BibTeX is extensible & allows for an almost limitless number of custom fields.  As with EndNote, it might be difficult to share such customizations.  There are some that are more common than others ('translator' is certainly not an uncommon BibTeX field, but it isn't "standard").

    But if your aim is to provide support for multiple exports such as BibTex records

    Yes, I think sharing references with other tools (both import & export) is one of refbase's greatest strengths (due, in no small part, to the excellent 'bibutils').

    That's why - instead of creating custom fields for this fourth category - I would still prefer to use and rename any of the redundant fields, such as "corporate author", "address" or "expedition", for primary sources and incorporate them in a custom citation style.

    Presently, if you wanted to reclaim an already-existing field for some other purpose, you'd really only need to change the MODS XML exporter in refbase.  Your changes would not be reflected in future releases of refbase.  Development is slow enough that you will most likely be able to just run 'diff' & apply a patch to subsequent releases in the foreseeable future.  This should not be too difficult, but feel free to solicit more help if you get stuck.

    -Rick

     
http://sourceforge.net/p/refbase/discussion/351913/thread/39159f77/
sourceforge.net
crawl=CC-MAIN-2014-10
44418
application/http; msgtype=response
sha1:BOTVW6F22EHYAMN4OMXK6YRI46CYIJNT
<urn:uuid:f6d1b9d5-a826-4dad-b2e2-de3508be24f7>
2014-03-10T22:06:48Z
216.34.181.60
sha1:VRA7OX7TYZ3M6RYBCP6ZS5A27J2ILCZZ
<urn:uuid:a318c04e-813d-49c9-9f8d-20f5fddaa753>
http://sourceforge.net/p/refbase/discussion/351913/thread/39159f77/
response
<urn:uuid:479bd52d-26ea-401b-b4fa-de440ef9f149>
robots: classic
hostname: ip-10-183-142-35.ec2.internal
software: Nutch 1.6 (CC)/CC WarcExport 1.0
isPartOf: CC-MAIN-2014-10
operator: CommonCrawl Admin
description: Wide crawl of the web with URLs provided by Blekko for March 2014
publisher: CommonCrawl
format: WARC File Format 1.0
conformsTo: http://bibnum.bnf.fr/WARC/WARC_ISO_28500_version1_latestdraft.pdf