References not showing all fields saved

[lpanebr]

I was playing with the demo and noticed this while editing references.

The following fields are saved but are not shown in the reference list:

• issue
• year
• month
• day
• page range
• e-location id

[michael]

Thank you! We need to revise that renderer (see #430). I just did a very basic initial implementation. What publication type were you using?

[lpanebr]

OK. I was editing a journal reference. I also tried adding a new one and it's the same.

I see now that the renderer implementation mentioned in #430 is limited..

I just noticed that the year is also missing. In the eLife the year should be added after the article title:

[michael]

Right! We need to go through all pub types and consider all different cases (assuming all fields are optional).

@zuphilip, @lpanebr could one of you two work on that (#430) and submit a Pull Request? :)

[lpanebr]

I much as I would love to code I am not currently with free dev time..

I can however try to help with some testing and algorithm/style rules definition if that helps.

[michael]

@lpanebr can you try out latest master, and see if your problem has been solved?

[zuphilip]

• issue: should show up for journal article :heavy_check_mark:
• year: should show up on all publication types :heavy_check_mark:
• month, day: only used for webpage (:heavy_check_mark: )
• page range: not used, because there seems to be the same information with firstpage and lastpage :question:
• e-location id: not yet used, because I don't understand what this information is :question:

[lpanebr]

• issue: OK
• year: OK
• month, day: should also show in other reference types. In journal articles the month is particularly frequent in the 3-letter abbreviated form.[1][2]
• page range: is used for discontinuous page numbers[3]. In terms of algorithm I think that if page-range present is it SHOULD render replacing the pair fpage-lpage BUT in the exported XML all 3 elements MUST appear.[4]
• e-location id: replaces the tradicional pagination in online-only journals and thus MUST be used replacing the fpage-lpage elements.[4][5]

While making all fields optional gives flexibility it also requires a lot of responsibility from the users. I've no idea how much validation you're willing to put in the application, but the references need them. This raises an issue because validation, specially in this domain, touches a lot of UI and UX.

[1] https://www.ncbi.nlm.nih.gov/books/NBK7282/#A32680 [2] https://www.ncbi.nlm.nih.gov/books/NBK7282/box/A34056/?report=objectonly [3] https://www.ncbi.nlm.nih.gov/books/NBK7282/box/A33679/?report=objectonly [4] https://jats.nlm.nih.gov/publishing/tag-library/1.1/element/page-range.html [5] https://jats.nlm.nih.gov/publishing/tag-library/1.1/element/elocation-id.html

[zuphilip]

Thank you for your feedback. This is helpful! I hope to find time to work on these issues. Moreover, I guess you want also that the PubMED ID shows up in the references, see #447.

I could imagine that the UI has only one field for entering the pages or article id. From the content it should be possible to decide whether this is a page range, discontinuous page range or a e-location id. Moreover, for the first two one could also calculate the first and last page in the background.

[michael]

That's a good idea, and will simplify usability! We just need to make sure the content can always be parsed.

As a data model we could use:

• contentLocation (page range or elocationid)
• contentLocationType ('print' or 'electronic')

I'd need to make some changes to the model and converters. Before I do, do we all agree that what we just proposed will work? @fabiobatalha

[fabiobatalha]

@michael

It seems to work.

If I understand, Texture will deal with the parsing of these fields to output the correct XML.

Example 1 Input: contentLocation: 12-23 contentLocationType: print

Output:

<element-citation>
    ...
    <fpage>12</fpage>
    <lpage>23</lpage>
    ...
<element-citation>

Example 2 Input: contentLocation: 12-23; 25-26; 28 contentLocationType: print

Output:

<element-citation>
    ...
    <fpage>12</fpage>
    <lpage>28</lpage>
    <page-range>12-23; 25-26; 28</page-range>
    ...
<element-citation>

Example 3 Input: contentLocation: e212810 contentLocationType: electronic

Output:

<element-citation>
    ...
    <e-location>e212810</e-location>
    ...
<element-citation>

[zuphilip]

A page range can contain numbers, dashes, semi-colons and spaces. Everything else would be an article id (e-location). But a single number, e.g. 98 could be the page range of a one-page paper or the article id. Thus, we need a second parameter as you suggested.

There are electronic articles with a page range. Therefore, we may want to use other labels than print and electronic for the differentiation?

The data model would then not allow to have an article with a page range AND a e-location, but I guess this cannot occur anyways...

[fabiobatalha]

Yes @zuphilip That is it.

Maybe the contentLocationType could be: (pages, elocation)

[michael]

Currently in JATS you can either have a pages OR an elocation-id, not both.

(((fpage, lpage?)?, page-range?) | elocation-id)?

@zuphilip do you have an example for an electronic article with pages? Ideally we would need to display just one field for the user and solve everything using a convention that can be parsed.

Is there a spec somewhere that defines how an elocation id must look like? I only saw ones with a prefixed "e" so far.

[fabiobatalha]

@michael

as far as I know there is no patterns for elocation ids. The "e" preceding anything is only a not mandatory convention.

[Melissa37]

Yup, the elocation ID should not be restricted in anyway as the publisher chooses their way to define it. e1234 is an eLife-specific. eg BMJ uses something else: http://www.bmj.com/content/360/bmj.k1270. It's a bit like DOI format - publisher specific. BMJ is an interesting one, they publish longer format online and short in a print product. I don't know whether they have eLocation ID for the longer form and pages for the shorter form and they are different content... I suspect it is if they cannot have an elocation and pages in the same XML file!

[zuphilip]

• e-journal with page numbers: https://www.transacl.org/ojs/index.php/tacl/issue/view/14 which is AFAIK e-only, but I think there are much more.
• Examples for article ids:
  • P1.2 in http://www.combinatorics.org/ojs/index.php/eljc/article/view/v25i1p2
  • D17-1005 in https://aclanthology.coli.uni-saarland.de/papers/D17-1005/d17-1005
  • 1760011 in https://www.worldscientific.com/doi/abs/10.1142/S0218213017600119

[lpanebr]

I like the proposed solution using parsing.

I believe the two biggest parsing challenges will be:

1. Detecting and expanding compressed last pages: 121-9, 131-42 witch should yeld:

   121 142 121-9, 131-42

2. Deciding or asking the user when a single integer is provided. Since 1234 could equally be a fpage or an e-location

For the first is just parsing carefully, but for the second I don't see how to decide without asking the user..

[fabiobatalha]

I don't know if it is still usual, but have in mind as well that some journals use the roman numbers to identify pages.

[lpanebr]

Great catch Fábio! This should add an additional layer in the parsing processing challenge for the devs. ;-)

att. Luciano Panepucci

[lpanebr]

This reminded me that some journals also have prefixed pages like s123-s129...

Possibilities that come to mind:

1. we can all agree that those cases are less frequent and "forget" them for now

2. Detect those awkward scenarios and then present the user with an extended form

3. Deal with it

[michael]

Okay, then we may want to solve it with an explicit Radio button to display either the field for page-range or e-location id. Here's sketches:

[michael]

Alternatively to save space we could make Page-Range a dropdown (to switch to e-location ID when necessary)

[lpanebr]

I don't think that collecting the medium is important as it does not necessarily relate with the location type (page or e-location). Adding the medium will most likely confuse the user I think.

I was very happy with the single input for the page/e-location.

What if we stick to the single input but let the user know that for Article ID they MUST use a prefix like eid:

[michael]

Jeah that would also work. We just need to make sure, the input is easily parsable/serialisable.

[lpanebr]

I think nothing will ever be "sure" when dealing with user input. But we can try limiting input options, restricting allowed characters.

Maybe a middle ground would be having only 2 inputs and only allowing one to filled (filling one clear the other no questions asked):

This way we could restrict allowed characters differently in each field:

• Pages:
  • regular space
  • semicolon
  • dash, ndash, mdash
  • letters
  • numbers
• Article ID
  • anything but spaces

What do you think?

[michael]

I like your first proposal better. Regarding validating user input I thought that we allow any text input but run a linter on it. If we don't recognise our defined patterns we would color the field yellow and add a warning message.

[lpanebr]

Perfect. I like the single input also. I just got worried with requesting the user to add a fixed prefix in the elocation for I know users suck at reading, understanding and following instructions..

With the single input approach the key then is making it utterly evident how the user needs to enter the elocation. Is it possible to add a little colored question mark besides the field label which open a box with examples when the user mouses over it?

[michael]

Worked on drafting a UI for inline-editing of references (without the need for a popup). See #452

[lpanebr]

This is freaking awesome. I love it!

[Melissa37]

Echo that!

[michael]

Thank you!

I tried the same with author editing. See last post in #451 .

[lpanebr]

It looks equally great. I just find it a bit awkward having the email between first and last names.

Maybe it makes sense to deal with #447 now?

[michael]

Group says:

• We use one field for both elocation-id and pagerange, but we store the structured info in the XML
• We need just one page range, until there's someone complaining

[obuchtala]

Regarding rendering, we might want to move to Citeproc at some point. Don't know yet how e.g. elocation-id is considered there.