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

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

[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?

Rintze

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

@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

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.