PKP Bugzilla – Bug 5938
Abstract displays original References List
Last modified: 2012-09-21 16:05:36 PDT
We are moving to Git Issues for bug tracking in future releases. During transition, content will be in both tools. If you'd like to file a new bug, please create an issue.
Florian, remember when I was talking about when/where the references list was displayed, but couldn't quite figure it out? It's only on the abstracts. There's a problem with this:
The Abstract view of an article displays the original reference list as submitted by the Author, regardless of whether or not the Citation Markup Assistant has been used. So incorrect references could be displayed with the abstract.
At this late point, I'm not entirely sure what should be done. Would it be possible to change the display to the list of approved citations, as is done in the Export view? Maybe have the system default to the original citation list; but display the approved citations if all citations have been approved. Othewise, I would suggest disabling this display for now, at least until the problem has been fixed.
I have seen this before but I personally didn't consider it a problem that the original citation list is being displayed as we're no longer talking about "citation improvement" but only about "citation mark-up". In other words: The citations posted by the author (and potentially corrected by the editor) are currently the best we have in "plain text". That's why I've left the abstract page alone. Do you think this is a big problem?
(In reply to comment #1)
> Hi James,
> I have seen this before but I personally didn't consider it a problem that the
> original citation list is being displayed as we're no longer talking about
> "citation improvement" but only about "citation mark-up". In other words: The
> citations posted by the author (and potentially corrected by the editor) are
> currently the best we have in "plain text". That's why I've left the abstract
> page alone. Do you think this is a big problem?
I think we'll get some questions. :D Mostly it's a discrepancy issue: if the Editor has gone through the citations and made changes, I think she'd wonder why the original references list was being displayed. I understand that we have moved away from emphatically "improving" citations, but I think in this case the authoritative, ie. edited and approved version should be displayed.
The parsed citations don't produce good plain text (i.e. citation style) results until we use a framework like citeproc (which doesn't have a PHP binding so far) for citation output and get better data from our databases. That's why we've dropped the "citation improvement" use case and marked all non-XML output as "experimental".
I see two possible solutions (both are easy to implement in less than 3 hours):
1) We can compile a list of the raw citations which can be edited during the citation editing process and use this to update the references field in the article meta-data.
2) We can add an extra setting to setup step 3 "use generated citation output in abstract (experimental)" and not display any citations in the abstract unless this is checked.
We can even combine the two solutions:
3) create a drop-down in the citation settins: "use raw citations in abstract" vs. "use generated citation output in abstract (experimental)" where the first option corresponds to 1) above and the second to 2)
Implementing 3) will also not take longer than max. 6 hours (probably much less).
What do you prefer?
James, your point about people wondering why they'd gone through the trouble of marking up citations is well taken. Tricky -- although of course the value of parsing citations is justified elsewhere.
I think in the long run a toggle would be the best thing -- maybe even per-article -- but of course this introduces new locale keys. Alternately, maybe some way of helping the editor or author round-trip the parsed citations back into the raw field.
I'd suggest leaving this as currently implemented for 2.3.3, as I can't see a better work-around that doesn't introduce new locale keys.
#1 can be done without additional locale keys. That might be the only solution available for 2.3.3 then. I'll implement that one but leave the bug report open (assigned to 2.3.4 to implement #3 later on.
I've implemented #1 (and inserted a FIXME to the code that points to this bugzilla entry). I'll defer the rest to 2.3.4 (see discussion above).