Website citation via Harvard style

Hi there

I’m looking for a “Havard” style were Author-less websites get cited sensibly.

At the moment I’m using the style [“University of South Australia 2013 (Harvard)]”(http://www.zotero.org/styles/university-of-south-australia-harvard–2013). With the following reference (shown in BibTeX format)
 @misc{twitter_using_2013,
type = {Documentation},
title = {Using the Twitter Search {API}},
url = {https://dev.twitter.com/docs/using-search},
urldate = {2013-09-21},
journal = {Using the Twitter Search {API} {\textbar} Twitter Developers},
month = aug,
year = {2013},
}
I get in text as citation
('Using the Twitter Search API' 2013) 
and as reference
'Using the Twitter Search API' 2013, 'Using the Twitter Search API', (ed.), 
viewed 21 September 2013, <https://dev.twitter.com/docs/using-search>.
This doesn’t make sense to me. More inline with Harvard would be a reference like
Using the Twitter Search API 2013, 'Using the Twitter Search API', [WWW], viewed...
Additionally in the citation I think the brackets are particularly strange.

Any idea what’s a better “Harvard” style for author-less references? Or do I have to fix up the metadata in zotero? But which metadata would give better results?

Many thanks, Leo
  • are you using Zotero or something else to produce the citations?
    APA or Chicago author date are good Harvard variants when you don't care about specifics
  • edited September 21, 2013
    Thanks for your reply.

    I use pandoc/bibtex/latex to create the bibliography from the bibtex export via the mentioned CSL file.

    When I use zotero to create the citation in the clipboard it is much better:
    Using the Twitter Search API 2013, Documentation, Using the Twitter Search API | Twitter 
    Developers, viewed 21 September 2013, <https://dev.twitter.com/docs/using-search>.
    So why does pandoc/bibtex/latex creates such a different output? Afterall it uses the bibtex file from zotero and the same CSL? (I know that is not the right question for this forum, but it does puzzle me…)
  • The problem isn't actually that pandoc does something wrong, but it's an issue of "lost in translation". You export to bibtex, and then pandoc converts that bibtex to MODS and then uses that for citations. I think the issue is actually the conversion to bibtex, the problem being that there simply isn't a good, standard item type in bibtex for webpages (and @misc is the smallest common denominator).
    I'm not sure if there is a good solution here, though you could try to figure out if pandoc does convert one of the other possible item types for webpages correctly. @online is probably the most commonly used.
  • Great suggestion! So I change manually @misc to @online in the bibtex file - but the reference still doesn't have the URL in it (with Elsivier).

    Also, do I need another bibtex exporter, which exports webpages properly? Is there exporter repository like the CSL style repository?
  • I can't help you further with the URL then - we do Zotero and CSL support here and the Zotero and CSL handle this correctly. You'll need to find out from pandoc what type of input they need to correctly generate webpage citations.

    As for bibtex export - no, there is no translator repository, there is only one bibtex translator, though you can modify that if you know basic javascript (it's in the translator folder of your zotero data directory: http://www.zotero.org/support/zotero_data ). And as I say, the problem is that there is no "properly" for exporting webpages in bibtex.
  • edited September 22, 2013
    @adamsmith and the Zotero export filter developers:

    You are right that there is no "properly" for exporting webpages in bibtex.

    However, bibtex is so limited anyway that by rights it should not be used any longer and should be replaced by biblatex instead.

    In biblatex, there *is* a "properly" for exporting webpages:

    @online{key1,
    author = {Author, Al},
    title = {Title},
    date = {2011-09-14}
    url = {http://webpage.url},
    urldate = {2012-12-30},
    }

    In fact, biblatex, as opposed to bibtex, is the only database format on a par, in terms of sophistication, with the CSL database model.

    biblatex is also what pandoc uses as a default if the biblio database file has a .bib extension. You can use the bibtex database format but have to indicate this by using the .bibtex extension for the database file.

    The output of Zotero's "BibTeX" export filter, such as

    @misc{twitter_using_2013,
    type = {Documentation},
    title = {Using the Twitter Search {API}},
    url = {https://dev.twitter.com/docs/using-search},
    urldate = {2013-09-21},
    journal = {Using the Twitter Search {API} {\textbar} Twitter Developers},
    month = aug,
    year = {2013},
    }

    is broken in any case, and will, even with @misc changed to @online, neither work with bibtex (which won't understand url and urldate) nor with biblatex (which won't understand month=aug; should be month={8}).

    The only half-decent way of getting online material properly formatted in bibtex, AFAIK, is to use the @misc type, put the URL in howpublished={\url{http://foo.bar}}, and, of course, load url.sty in your latex document. Still, accomodating an accessed date in bibtex is next to impossible (if you don't want to resort to the kludge of adding this to the howpublished field, that is).

    What I'd recommend for Zotero is to add a working biblatex export filter, and also to fix the existing bibtex export filter to use only constructs that can actually be parsed within a bibtex environment, and to clearly point out the differences between the two export filters as well as the limitations of bibtex in the documentation.

    @halloleo:

    Using your biblio data, with "@misc" changed to "@online" and "month = aug" to "month = {8}", in test.bib and issuing the command

    echo @twitter_using_2013 | pandoc --filter pandoc-citeproc --biblio=test.bib --csl=university-of-south-australia-harvard-2013.csl -t markdown-citations

    pandoc version being 1.12.0.1, I get:

    (2013)

    <div class="references">

    2013, Documentation, viewed 21 September 2013,
    \<<https://dev.twitter.com/docs/using-search>\>.

    </div>

    which, though it does contain your URL, is obviously broken.

    However, using the chicago-author-date style instead,

    echo @twitter_using_2013 | pandoc --filter pandoc-citeproc --biblio=test.bib --csl=chicago-author-date.csl -t markdown-citations

    I get:

    (“Using the Twitter Search API” 2013)

    <div class="references">

    “Using the Twitter Search API.” 2013. Documentation. August.
    <https://dev.twitter.com/docs/using-search>.

    </div>

    which looks more or less ok, so I'm inclined to assume that there's also an issue with university-of-south-australia-harvard-2013.csl that should be further diagnosed and fixed.
  • we'll add biblatex export soon-ish, but we certainly won't replace bibtex - claims about its death are _way_ premature, given that most .bsts for journals are still bibtex.
    There already is a custom biblatex translator available on the forum, easy to find&install.

    There is no one bibtex and some implementations do understand url (e.g. natbib). We made the judgment call to prefer that over howpublished on export. IIRC there are also packages that do recognize urldate, but not sure off the top of my head. We mainly decided to include it because it can't hurt and it's nice to have if you're using bibtex as a data exchange format.

    The UniSA style works fine in Zotero (see above), which suggests the problem occurs somewhere on the way - either in translator or because of a citeproc-hs bug - but also both Chicago and UniSA give URLs for any item type, so given that the OP doesn't get a URL in Elsevier Harvard - even when using @online - the webpage item type does seem to get lost somewhere on the way.
  • with bibtex (which won't understand url and urldate)
    As adamsmith notes, many BSTs do make use of these (opcit and the babelbib libraries are examples that support the latter). Bibutils (used by citepros-hs) recognizes the URL field.
    fix the existing bibtex export filter to use only constructs that can actually be parsed within a bibtex environment
    BibTeX is expandable because it ignores fields not used in a BST. The downside is that people have therefore used multiple different ways to "hack" features into BibTeX. Zotero's export picks constructs that are well-documented or well-embraced (by best-of-class products like bibutils and jabref or by many BST styles).

    If you're using pandoc+citeproc-hs (CSL) for your authoring, why not export to MODS XML instead of Bib(La)TeX?

  • If you're using pandoc+citeproc-hs (CSL) for your authoring, why not export to MODS XML instead of Bib(La)TeX?
    because afaik there is nothing like a citekey in MODS (certainly not in Zotero's MODS export), but that's needed for citing in pandoc.
  • MODS can have record IDs:<?xml version="1.0" encoding="UTF-8"?>
    <modsCollection xmlns="http://www.loc.gov/mods/v3">
    <mods ID="MY_RECORD_ID">
    <titleInfo>
    as well as special identifiers like this:<identifier type="citekey">ref1</identifier>. When Zotero has a separate local identifier field, we should export things like this. Until then, we may want to use the mods ID anyway. And people contemplating modifying translators for pandoc may want to start with MODS, which is used natively & should export many kinds of references in a less...ambiguous?/more complete way than BibTeX.
  • When Zotero has a separate local identifier field, we should export things like this. Until then, we may want to use the mods ID anyway. And people contemplating modifying translators for pandoc may want to start with MODS, which is used natively & should export many kinds of references in a less...ambiguous?/more complete way than BibTeX.
    agree on both of these. Didn't know about identifiers in mods, thanks for that.
  • Just to follow up:

    John MacFarlane's tip to upgrade to the brand-spanking new version pandoc 1.12.0.1 made all the difference: Now pandoc has an output very similar to zotero!

    Thanks for all your help!
Sign In or Register to comment.