Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Article categories #1342

Open
fred-atherden opened this issue Jul 12, 2019 · 1 comment
Open

Article categories #1342

fred-atherden opened this issue Jul 12, 2019 · 1 comment
Assignees
Labels
feature-request A formal Texture feature specification

Comments

@fred-atherden
Copy link
Collaborator

fred-atherden commented Jul 12, 2019

Description

An article may be assigned to one or more categories for indexing purposes. These can include subject areas, human-readable article types, collection names and so on.

User Stories

Author

  1. As an author, I want to see the categories applied to my article so that I can confirm this is correct.

Production staff

  1. As production staff, I want to be able to change the article categories so that I can correct any errors.
  2. As production staff, I want to be able to add custom categories to an article so that I can compile ad-hoc collections or search terms.
  3. As production staff, I want to be able to add categories in multiple languages so that I can include translated subject areas, article types etc.

But what if . . . ?

  • a publisher has specific display requirements for a category? Should this be reflected in the proof?

Considerations

  • This is covering terms applied at the article heading level. Keywords, which can be applied at the article level or on a more granular level throughout the article are covered in Fix CaptionConverter crash with caption titles #23. These are distinct in JATS and tend to get referred to as separate entities.
  • Categories can include preset lists of terms (e.g. the major subject areas a journal is organised into, the list of article types it publishes etc).
  • At eLife, one or two major subject areas are allowed per research-type article. Non-research content does not need to have an MSA, but can have one.
  • Éruidt needs support for multiple levels of categories, up to a maximum of 3 levels.
  • Beyond subject areas, eLife sorts articles into types. E.g. Research article, Tools and resources, Short report, Editorial, Insight etc. These are human-readable types and do not always reflect the NLM article-type value included in article. For example, Research article, Tools and resources, Short report, Registered report, Replication study and Research communication all share the 'research-article' value for @article-type.
  • eLife also supports an additional 'subsection' category that is used to prefix the title in non-research content. This is currently captured in <subj-group subj-group-type="sub-display-channel"> within the <article-categories> group; however this is a legacy of our previous hosting platform. Allowing this is a requirement, but we are open to changing how it is captured. The published display of this 'subsection' label looks like:

Screen Shot 2019-06-07 at 13 09 17

  • Érudit and other publishers need to support categories in multiple languages.

XML requirements

Major subject areas at eLife are captured as <subject> elements in a <subj-group subj-group-type="heading"> element. They are captured as children of article-categories. 0-2 subjects allowed in eLife articles

<article-categories>
     <subj-group subj-group-type="heading">
          <subject>Epidemiology and Global Health</subject>
          <subject>Human Biology and Medicine</subject>
     </subj-group>
</article-categories>
<article-categories>
    <subj-group subj-group-type="heading">
        <subject>Articles</subject>
        <subj-group subj-group-type="heading">
            <subject>Review Articles</subject>
            <subj-group subj-group-type="heading">
                <subject>Report</subject>
            </subj-group>
        </subj-group>
    </subj-group>
    <subj-group subj-group-type="heading" xml:lang="en">
        <subject>Articles english</subject>
        <subj-group subj-group-type="heading" xml:lang="en">
            <subject>Review Articles english</subject>
            <subj-group subj-group-type="heading" xml:lang="en">
                <subject>Report english</subject>
            </subj-group>
        </subj-group>
    </subj-group>
</article-categories>

eLife are not wedded to the @subj-group-type value given.

@xml:lang can be used on the subj-group element if needed.

Subjects and keywords are currently under JATS4R public review

eLife defines article type as a subject in front/article-meta/article-categories

<article-categories>
        ...
        <subj-group subj-group-type="display-channel">
                <subject>Research Article</subject>
        </subj-group>
</article-categories>

Example of article-categories for an article with sub-display-channel (as mentioned in the considerations):

<article-categories>
    <subj-group subj-group-type="display-channel">
        <subject>Insight</subject>
    </subj-group>
    <subj-group subj-group-type="heading">
        <subject>Cancer Biology</subject>
    </subj-group>
    <subj-group subj-group-type="sub-display-channel">
        <subject>Biomarkers</subject>
    </subj-group>
</article-categories>

Érudit need the ability to allow multi-language subj-groups:

<article-categories>
    <subj-group subj-group-type="heading" xml:lang="en">
        <subject>Front Matter</subject>
    </subj-group>
    <subj-group subj-group-type="heading" xml:lang="fr">
        <subject>Liminaire</subject>
    </subj-group>
</article-categories>

Mock ups

Proposal

@fred-atherden fred-atherden added the feature-request A formal Texture feature specification label Jul 12, 2019
@fred-atherden
Copy link
Collaborator Author

Note - this was raised before receiving feedback from SciELO.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A formal Texture feature specification
Projects
None yet
Development

No branches or pull requests

4 participants