Unwanted [Available at:] and [Accessed date] information in reference list

2»
  • bdarcus
    @fbennett:
    So if there is a date inside the child group, that triggers rendering of the entire macro. To produce the expected behavior, the outer group should be replaced with a wrapper.
    Wouldn't a more appropriate fix be to de-nest the groups?

    <group>
    <text value="Available at:" suffix=" "/>
    <text variable="URL"/>
    </group>
    <group prefix=" [" suffix="]">
    <text term="accessed" text-case="capitalize-first" suffix=" "/>
    <date variable="accessed">
    <date-part name="month" suffix=" "/>
    <date-part name="day" suffix=", "/>
    <date-part name="year"/>
    </date>
    </group>
  • fbennett
    edited April 3, 2011
    [content elided -- I mistook the gist of Bruce's comment on first reading]

    They could be denested, I suppose, but that would have required more typing.

    Actually, maybe I didn't misread. Are you suggesting that a choose statement isn't required?
  • RintzeRintze
    Accessed dates are usually only include for webpages, right? In which case there would be a URL. So I think Frank's use of a conditional is the way to go.
  • fbennett
    That's what everyone was complaining about, anyway.
  • bdarcus
    edited April 3, 2011
    @rtinze: The problem is, what's a "webpage" in 2011? A journal or newspaper article that's published on the web is a webpage as well, and should include a URL and access date if present. This is why I think styles should be liberal on this matter, and that the translators should be smarter.

    @fbennet: yes, I'm suggesting it's not needed, and that it's more consistent with the intent of the original code to use two groups.
  • fbennett
    edited April 3, 2011
    So what does an orphaned "accessed" date refer to? (Bearing in mind that the original code relied on the fact that a nested group in which a nil value on the top-level element [the URL] would produce exactly the result achieved by a straight conditional -- people were upset because the output changed between 2.0.9 and 2.1.)
  • adamsmith
    I completely agree with Frank - I'm aware of no style that wants an access date when there is no URL - thus testing for a URL is absolutely the right approach.
    A "webpage" in this sense is not a particular item type, but any item for which a URL is displayed, which can include a blogpost, a report posted online, a book posted full-text online etc. The practice of saving URLs for journal articles but not printing them where page numbers are present has proven very useful and I see no reason to change that.
    Overall, I think the current mix of styles and translators do an excellent job of accounting for the the various hybrid forms of on and offline publication and I really don't see any reason to change things around.
  • bdarcus
    @fbennett:
    So what does an orphaned "accessed" date refer to?
    I go to the "garbage in garbage out" principle: bad data yields incoherent results. Not a style's job to be fixing these sorts of problems.

    But I don't feel that strongly on this particular issue (about the solution to the nested group problem). I just meant to flag it as a possibility.

    @adamsmith:
    I completely agree with Frank - I'm aware of no style that wants an access date when there is no URL - thus testing for a URL is absolutely the right approach.
    A "webpage" in this sense is not a particular item type, but any item for which a URL is displayed, which can include a blogpost, a report posted online, a book posted full-text online etc. The practice of saving URLs for journal articles but not printing them where page numbers are present has proven very useful and I see no reason to change that.
    Overall, I think the current mix of styles and translators do an excellent job of accounting for the the various hybrid forms of on and offline publication and I really don't see any reason to change things around.
    So why do I still have a lot of records that have URLs that don't belong there (should be links)? It might be that they're just old, and that relevant translators have since been updated. But certainly at least for a very long time, we had a problem here, and I don't think we should be writing styles, or core software, to work around translator bugs.
  • adamsmith
    could you be more specific? There were some old examples where URLs where erroneously written, e.g. from library catalogues. But for journal articles I just think I disagree with you - I do think those should have URLs - and when they don't have page numbers (nor dois) those URLs should be cited.
  • ajlyon
    I try to be vigilant about not saving non-canonical URLs for items when I do translator reviews. I'm sure there are plenty of translators that get it wrong, but that'll only get better if people point out the problems. I don't plan on going through the 300+ existing translators to pick this out myself.
  • bdarcus
    When I get a chance, I'll spend some time trying to track down specific translators. But one quick example is stuff pulled from jstor.
  • ajlyon
    Please go to http://github.com/ajlyon/zotero-bits/raw/master/JSTOR.js and save the file to the translators directory of your Zotero data directory (http://www.zotero.org/support/zotero_data). It should handle the URLs correctly. Here, we were simply following the guidance of the RIS that JSTOR gives us-- so it was a stealth setting of the URL field.

    Please post additional translators of concern in a separate thread or to zotero-dev, since this thread already has plenty of confusion with the CSL updates.

This is an old discussion that has not been active in a long time. Instead of commenting here, you should start a new discussion. If you think the content of this discussion is still relevant, you can link to it from your new discussion.