Add support for supplementary-material in back

[JGilbert-eLife]

eLife allows the following <supplementary-material> in a section labelled "Additional files" within the back matter. It should be possible to cite these in the text as, e.g. <xref ref-type="supplementary-material" rid="supp1">Supplementary file 1</xref>.

Supplementary files:

<supplementary-material id="supp1">   
                <object-id pub-id-type="doi">10.7554/eLife.00666.019</object-id>
                <label>Supplementary file 1.</label>
                <caption>
                    <title>This is the title of the supplementary file 1.</title>
                    <p>A file containing underlying data.</p>
                    </caption>
                <media mimetype="application" mime-subtype="csv" xlink:href="elife-00666-supp1.csv"/>
            </supplementary-material>

Source data:

<supplementary-material id="sdata1">   
                <object-id pub-id-type="doi">10.7554/eLife.00666.020</object-id>
                <label>Source data 1.</label>
                <caption>
                    <title>This is the title of the source data that is not attached to a specific figure, but to the article as a whole.</title>
                </caption>
                <media mimetype="application" mime-subtype="xlsx" xlink:href="elife-00666-data1.xlsx"/>
            </supplementary-material>

Source code:

<supplementary-material id="scode1">   
                <object-id pub-id-type="doi">10.7554/eLife.00666.021</object-id>
                <label>Source code 1.</label>
                <caption>
                    <title>This is the title of the source code that is not attached to a specific figure, but to the article as a whole.</title>
                </caption>
                <media mimetype="application" mime-subtype="xml" xlink:href="elife-00666-code1.xml"/>
            </supplementary-material>

Reporting standards document:

<supplementary-material id="repstand1">
                <object-id pub-id-type="doi">10.7554/eLife.00666.034</object-id>
                <label>Consort checklist and flow diagram.</label>
                <media mimetype="application" mime-subtype="pdf" xlink:href="elife-00666-repstand1.pdf"/>
            </supplementary-material>

Transparent reporting form:

<supplementary-material id="transrepform">
                <object-id pub-id-type="doi">10.7554/eLife.00666.022</object-id>
                <label>Transparent reporting form.</label>
                 <media mimetype="application" mime-subtype="pdf" xlink:href="elife-00666-transrepform.pdf"/>
            </supplementary-material>

[michael]

@JGilbert-eLife Are DOI's for individual supplementary-material objects still a thing? If I remember correctly you wanted to stop adding individual DOI's for Figures, Tables etc.

[JGilbert-eLife]

Yep, still a thing. We've not made a final decision on dropping 'sub-DOIs' throughout the article yet.

@Melissa37 for confirmation.

[Melissa37]

We've not made a final decision on dropping 'sub-DOIs' throughout the article yet.

This is not an easy and quick decision. Sorry! However, I think we can ignore component DOIs at this point and add into phase 2 as necessary. @michael does that work for you?

[michael]

For articles created in Texture, we have generated ID's for all sub-content anyways. So that would allow you to create URL's that take you to the piece of content.

10.7554/eLife.00666#sdata1

@Melissa37 not a problem adding that DOI field, just wanted to check if it is still a requirement. As it could save some time in production leaving those out and instead use urls that navigate 'into' the Dar.

[michael]

@Melissa37 @JGilbert-eLife Would you support specifying a type (using predefined list of type names). That would allow us to generate the labels automatically. E.g. we could have:

• sourcedata: Dataset or Source Data (CSV, XLS, ...)
• sourcecode: Source Code (text file)
• repstand: Reporting Standards Document (PDF, ...)
• transrepform: Transparent Reporting Form (PDF,...)

Thoughts?

[michael]

Furthermore we could more tightly include Datasets (if those are CSV files of reasonable size, and view as a spreadsheet), so they are not 'just attached files'. I'm also thinking of the Embo/SourceData usecases here, where we want accessible source data available per figure panel.

Generally we would love to support additional files on the Dar level. That means you can drop any file on a Dar project and it will be stored inside the Dar and becomes available as a tab in Texture. If the file type is supported (e.g. CSV) we can preview right in Texture Editor or Texture Reader.

[JGilbert-eLife]

@michael - just to be clear, when we are talking about Datasets in context of the Data availability section (#557), we mean something that has been stored in a database/repository completely separate from the article itself. These datasets will never be part of the article files.

Source data is the term for any 'dataset' files that are included within the article; these are usually much smaller than the externally archived datasets and will most often be the data directly used to create the figures or tables in the article.

When you say specify a type, what exactly do you mean here? You can see examples of the ids eLife uses for these file types in the XML samples above. In terms of the actual file extensions, I don't know how well we can tie this to the file type.

Transparent reporting forms can be docx or PDFs, Reporting standards can be PDFs, doc, docx, xls, xlsx . . .

Source code can be .mat, .py, .txt, I think we've even had PDFs in some very unusual cases. Source data can be .csv, .xls, .pdf, even image formats (we've had some cases where a graph is the source data for a table, for example).

Supplementary files can be pretty much anything.

[michael]

@JGilbert-eLife I understand that only internal datasets are stored with the publication (e.g. as CSV). I just wanted to propose to come up with a predefined list of types which we can use for automatic label generation ("Dataset 1", "Source Code 1" etc.). However we have a means to reason about the type of the attached content by providing an explicit type. I'd not restrict what file type to associate. You can attach anything.

[JGilbert-eLife]

@michael - OK, that makes sense. Though, to be clear, eLife would not at the moment use the label 'Dataset 1' in any context (other publishers, of course, may!).

It feels like there's be a UX question here - would the user upload a file then select what kind of file it is, or pick the kind of item they want to introduce (e.g. Source data) then attach a file to it?

No strong feelings either way, just wondering what makes most sense from a design perspective.

Back to what is hopefully your original point, we have a pre-determined list for file types and ID values:

Source data X/sdataX Source code X/scodeX Supplementary file X/suppX Reporting standard X/repstandX Transparent reporting form/transrepform [currently only one per article]

Citations of these items in the XML then take the form

<xref ref-type="supplementary-material" rid="supp1">Supplementary file 1</xref> 
<xref ref-type="supplementary-material" rid="sdata1">Source data 1</xref>

etc.

Am I completely missing what you are talking about here?

[michael]

Am I completely missing what you are talking about here?

Not at all. Here's an updated requirements description according to your comments. Thoughts?

[Melissa37]

HI there

Sounds good, I think. But I'd want to discuss the UI a bit more.

Also, don't want this to be lost: Source data and source code can also be a child of another asset (for example figure 3 - Source data 1). They could be an asset to the whole article (like the supplementary file, reporting standard or transparent reporting form), but they can also be a child (not the same source data file, but we could for instance have multiple source data files, one is to the article as a whole and the others are all attached to different figures, respectively).

[JGilbert-eLife]

Related ticket for figure and table specific files: #1016

[obuchtala]

Done.