The following is a compilation of Public Comments on NISO RP-15-201x, Recommended
Practices for Online Supplemental Journal Article Materials, Part B: Technical
Recommendations, http://www.niso.org/apps/group_public/document.php?document_id=8880 and the TWG responses to those comments.
Summary license
Comment
I would recommend making the license (or waiver) a required element so that terms of reuse are explicit.
Response
At this time, the Working Group feels it is best to allow for making the terms of reuse specific, but will leave that element as optional.
Summary
OAI-ORE
Comment
The RDF-based OAI-ORE was specifically created to tie a resource and supporting resources together in a single metadata description. It is rather disappointing not to see it used/recommended in this specification. OAI-ORE is increasingly used in various einfrastructure/cyberinfrastructure projects (cf work of the U Manchester group; DataONE). It would be nice for this effort to have a closer look at its applicability in this realm.
Solution
Investigate the use of OAI-ORE for the purpose of creating a metadata description that ties the core resource and the supporting resources together. Note that the packaging approach that is described may not be feasible in many cases (e.g. resources too big; intellectual property issues prevent bundling materials together, ...). In these cases a pure metadata description that points at the various resources is beneficial. OAI-ORE was intended for this purpose.
Response
The following was added to the Recommendation as a footnote on page 1, section 1.2, bullet 1: Note that since the DTD is non-normative, other vocabularies could also be
Page 1 of 18

used to express the recommended metadata. For example, METS, OAI-ORE, and
DataCite are metadata vocabularies that are focused on environments that are complementary to journal article publications, or that focus on datasets. Insofar as these vocabularies cover the recommended metadata elements, they could be used to implement this recommendation. The DTD included in this recommendation corresponds most closely to the journal publishing environment.
Summary
Addition to DTD and Schema
Comment
If the supplemental material contains an actual file there is no way to say that all of the files in a group are meant for Windows or Mac OS. Instead you need to do this on a file-by-file basis.
Solution
<platform> should be kept where it is, at the individual file level but also added to
<supp_mat_descriptive>. Our company assigns platform information by groups of files and not at the individual file level.
Response
The DTD was modified to allow <file_metadata>, which includes <platform>, to apply to a group of supplemental material objects.
Summary
METS profile instead of non-normative DTD?
Comment
I'm surprised that you've chosen to define a DTD rather than specify a METS profile that people might use to describe a digital object containing the article, integral material, and supplemental material.
Solution
I recommend defining a METS profile because this is the standard in digital libraries for metadata relating files in a digital object.
Response
See response to comment 2 above.
Page 2 of 18

Summary reference to <oXygen/> XML Editor
Comment
You currently use the phrase "oXygen-generated diagrams and content models" without naming the program correctly. It's also syntactically ambiguous since it sounds like the content models were generated by <oXygen/> XML Editor as well, though I'm not sure you meant this.
Solution
I suggest rephrasing as "diagrams and content models generated by the <oXygen/> XML
Editor". If the content models aren't generated by this program, then the sentence should instead end with "as well as in the form of the Tag Library, diagrams generated by <oXygen/>
XML Editor, and content models".
Response
The highlighted sentence from section 2.2 was modified to read: The supporting documentation contains the non-normative representation of these metadata as a DTD, accompanied by the Tag Library.
Summary
Missing aspects related with experimental reproducibility
Comment
The current draft of the recommendation is a good step forward towards addressing the problem of supplemental materials for journal articles. However, its coverage seems to be partial. Little or no emphasis is made on the aspects related with the experimental methods enclosed in journal communications and how such methods are implemented and executed.
This is especially the case of computationally intensive disciplines, where the experiments upon which scientific progress is built are run in silico, usually in the form of scientific workflows.
Scientific communications would need to provide proof of their claims and, in this sense, supplemental materials should provide the means to reproduce experimental results. This is also the approach from the nanopublications community effort. However, the recommendation seems to focus on more basic aspects related to digital libraries and preservation, like identification e.g. by means of DOIs. Provenance is mentioned as a way to support credit and attribution, but it would also be of great importance to leverage provenance information in support of the reproducibility of scientific results, for example.
Page 3 of 18

Solution
This may be a matter of scoping. If the issues commented above are not in the spirit of this recommendation, it should be said upfron in the beginning of the document.
Response
Reproducibility is an important concept in scientific research, and is emerging as an important aspect in computational studies. However, the requirements for reproducibility vary according to the discipline and the specific experiments. The documentation associated with reproducibility can be included as a supplemental material object, and metadata should be added in accordance with this recommendation. No special mention is needed for this type of object.
Page 4 of 18

Summary
Response from DataCite Metadata Working Group. The comments apply to the overall document and to several specific sections.
Comment
DataCite is an international DOI registration organization with a focus on supporting access, citation, and re-use of data. The Metadata Working Group is composed of member representatives and staff, and has developed the DataCite Metadata Schema, now in version
2.2.
The Working Group has reviewed the Technical Recommendations from the perspectives both as metadata stewards and also as providers of DOI registration services to data centres and repositories across the globe. In these capacities, we observe that our two metadata schemas have distinct purposes: the NISO/NFAIS Metadata for Supplemental Material schema is naturally aimed at describing objects at the point of publication and in relation to a particular scholarly article, when both the supplemental material and the article are known. By contrast, the DataCite Metadata Schema addresses a larger set of use cases; in many, the decision to obtain a DOI may be made completely independent of—and/or precedent to—any traditional publication activity. For this reason, the DataCite Schema’s required properties establish a basic set of citation components for the registered object itself. For example, the DataCite schema requires identification of a creator of the registered object (“supplementary material”), whereas this information is optional in the NISO scheme, and at a group level, if we understand it correctly.
We have created a mapping (Table 1 below) between our two schemas in order to illustrate their correspondence, based upon our understanding. We hope this will achieve two aims: first, it should inform you as to how well your documentation has been understood; and second, it will advise you as to what metadata will be available to you for the growing number of supplementary materials with pre-existing DOIs from DataCite.
Lastly, here are some specific comments and recommendations.
Comment
Page 1, Section 1.2
We note the statement “The intent, however, is that an organization could implement these best practice Recommendations without referring to the supporting documents.” and suggest that this goal has not been met. We found it absolutely necessary to refer to the supporting documents in order to understand Table 1: Quick Reference. Therefore, we recommend providing persistent links to the supporting documentation within the document itself. Access
Page 5 of 18

to these materials was not sufficiently prominent, in our view, and they were required to understand Table 1: Quick Reference.
Response
The table has been modified to organize the rows by their relationship to each other rather than by whether they are required or optional. In addition, indentation of the elements better indicates the relationship of the elements. Links are not added from the tag/attribute names in the table to the elements and attributes in the DTD, since the
DTD is non-normative.
Comment
Page 4- Table 1
We found the metadata element names to be insufficiently distinct. The table in general was difficult to scan and required the use of the supporting documentation. It was not, as promised, a “quick reference.”
Response
The table has been modified to allow better understanding of the elements and attributes and their relationship to each other.
Comment
Page 8, Section 3.1
As mentioned above, DataCite is a growing worldwide presence, and we propose the first sentence of the third paragraph be changed as follows:
“Increasingly, datasets associated with an article may have been registered with DataCite...”
Response
Datacite is mentioned in Part A of the Recommendation. In addition, section 3.1 was modified as follows: Publishers should be aware that datasets associated with an article may have been registered with DataCite, a registration agency focused on research data. If that is the case, the publisher should not re-register the dataset through
CrossRef, but simply link to the DOI already assigned to the dataset. Publishers should encourage authors to include DataCite DOIs in their article if they have registered the dataset.
Page 6 of 18

Comment
Page 10, Section 4
We note the absence of any mention of academic domain specific repositories or data centres as a recommended preservation solution. We believe this is a serious oversight, because these organizations and institutions have rich and well-developed metadata standards for their fields.
We would like to see a recommendation to authors that they deposit their supplementary materials in these data centres whenever possible and appropriate.
Response
Institutional repositories are referenced in Part A of the Recommendation.
Comment
Page 12, Section 5
We agree with this statement: “The contents of a package are described with a manifest. The manifest is a list of all of the files present in the article package and should also include some basic information about the package and about each file.” However, we believe it should be extended to include information about how the package was produced. We propose the following:
“The manifest is a list of all of the files present in the article package and should also include some basic information about the package, tool and version, as well as about each file.”
Response
The sentence is replaced with: “The manifest is a list of all of the files present in the article package and should also include some basic information about the package, such as the tool and version used to create the package, as well as basic information about each file.
Page 7 of 18

Comment
Table 1: Mapping from DataCite Metadata Schema 2.2 to NISO/NFAIS Metadata for
Supplemental Material
ID DataCite-Property NISO Description
1 Identifier** Supplemental Material DOI*
Non-normative DTD name
<supp_mat_identifier>
2 Creator**
2.1 creatorName**
2.2 nameIdentifier
2.2.1 nameIdentifierSch eme
3 Title**
Supplemental Material Authors
Supplemental Material Authors
Supplemental Material Title
Note: DataCite may provide support for other identifiers in addition to DOIs at some point in the future.
<contrib_group>
<contrib_group>
<title>
4
5
3.1 titleType
Publisher**
PublicationYear**
Supplemental Material Publisher <publisher>
Supplemental Material Dates
<pub_date>
Note: DataCite only captures
Year.
Supplemental Material Keywords <subject_descriptor> 6 Subject
6.1 subjectScheme
7 Contributor
7.1 contributorType
7.2 contributorName
7.3 nameIdentifier
<subject_descriptor_group>
Page 8 of 18

ID DataCite-Property NISO Description
7.3.1 nameIdentifierSch eme
8 Date
8.1 dateType
Supplemental Material Dates
9 Language Supplemental Material Language
Supplemental Material
Descriptive Metadata
Non-normative DTD name
<pub_date>
<language>
(not in printed draft but in online
Tag List – ‘may be contained in
<supp_mat_descriptive>’)
10 ResourceType
10.1 resourceTypeGene ral
11 AlternateIdentifier
11.1 alternateIdentifier
Type
12 RelatedIdentifier Article DOI* <article_identifier>
12.1 relatedIdentifierTy pe
12.2 relationType
(isSupplementTo)
Relationship of Supplemental
Material to the Article*
Note: Insert default value of
‘DOI’
@supp-mat-type
Page 9 of 18

ID DataCite-Property NISO Description
13 Size Supplemental Material Physical
Metadata and/or
14
15
16
Format
Version
Rights
Non-normative DTD name
<supp_mat_physical>
<file_metadata>
Supplemental Material File
Information (not in printed draft but in online Tag List – ‘may be contained in
<supp_mat_physical>’)
Supplemental Material Physical
Metadata and/or
<size>
<supp_mat_physical>
<file_metadata>
Supplemental Material File
Information (not in printed draft but in online Tag List – ‘may be contained in
<supp_mat_physical>’)
<format>
Note: perhaps use repeated datacite:format element for both <supp_mat_physical> and
<format>?
Supplemental Material Versions @original
Supplemental Material License <license>
17 Description (ToC or Other)
Supplemental Material
Description*
<supp_mat_descriptive>
Supplemental Material Summary <summary>
17 Description
(Abstract)
Not present in
DataCite Schema
Article Metadata* <article_metadata>
Note: links to the article
Page 10 of 18

ID DataCite-Property NISO Description
RelatedIdentifier
/RelatedIdentifier
Type
/RelationType
/hasPart
Not present in
DataCite Schema
Not present in
DataCite Schema
Supplemental Material Object
Metadata*
Not present in
DataCite Schema
Not present in
DataCite Schema
Supplemental Material Source
Supplemental Material
Preservation
Not present in
DataCite Schema, but
RelatedIdentifier is
DataCite approach
Relationship between
Supplemental Material Objects
Non-normative DTD name
<supp_mat_object_metadata>
Note: Correspondence is not equivalent because the DataCite
‘hasPart’ relationship is only available in an optional DataCite property.
<label> Supplemental Material Label
Note: Distinction between Label and Caption is unclear.
Recommend that document provide usage guidelines, not just examples.
Supplemental Material Caption <caption>
Note: See above.
<provenance>
<preservation>
@relationship-of-objects
Note: DataCite supports a rich description of relationships between objects, but it is different from the NISO approach.
Page 11 of 18

ID DataCite-Property NISO Description
Not present in
DataCite Schema, but
RelatedIdentifier is
DataCite approach
Not present in
DataCite Schema
Not present in
DataCite Schema
Reference from Supplemental
Material to an Object in the
Article
Non-normative DTD name
<article_component_metadata>
Note: DataCite supports a rich description of relationships between objects, but it is different from the NISO approach.
Supplemental Material File
Validity
<validity>
Supplemental Material File Fixity <fixity>
Not present in
DataCite Schema
Applications to Create/Render
Supplemental Materials
<creating_application>,
<rendering_application>
** DataCite required property
* NISO/NFAIS required property
Response
This is a nice table comparing DataCite and NISO/NFAIS. We suggest that DataCite include the table on their site, and link to the NISO/NFAIS recommendation once it is approved.
Page 12 of 18

Summary
Suggestions from ACS
Comment
At a high level, a designation of the format might not be specific enough. For example, a movie might be in mp3 format, but could be stored with a variety of different CODECs. The detailed specification of the format should be included.
Response
A format can be described with as much specificity as desired. The CODEC is simply a modifier on the mp3 format and can be included in the format element as is. No change is needed.
Comment
Please check the sample DTD tagging in Table 1 for the following:
Make the use of underscore vs. hyphen more consistent, e.g., <article_metadata> vs. @suppmat-type
Response
Underscores in element and attribute names have been converted to hyphens.
Comment
The prefix "supp_mat_" (or "sup-mat-") is used some places but not in others. Consider using this prefix for the top level elements only, including the root element and the primary
“supplement material object metadata” container element.
Response
Underscores in element and attribute names have been converted to hyphens, and instances of “supp-” have been changed to “sup-”.
Comment
Because of the nestedness of supplemental materials, many elements appear on multiple levels. It is not always possible to separate top level elements from others.
Response
Elements can appear on multiple levels because they can apply to single supplemental material objects or to groups of objects.
Comment
<supp_mat_physical> - it might be nice to include “metadata” in the element name.
Page 13 of 18

Should this be done for <supp_mat_descriptive> as well? See also comment 3 about renaming top-level metadata element.
Response
The element and attribute names are intended to be expressive but not overly long. In this case, the TWG feels that the balance is maintained with the current names.
Comment
The NLM DTD (a.k.a. JATS) uses hyphens; it would be nice to be synchronous with that tagset at least in the format of tag names, in anticipation of them being used together or even merged someday as you suggested. ? Overall, it would be great to align the element/attribute names and design principals to that of JATS since there is a high degree of likely overlap between the two sets of implementers/users.
Response
The underscores in element names have been converted to hyphens.
Comment
On page 11, Consider PDF-A be explicitly mentioned as a recommended archival format.
Response
The Recommendation does not endorse any particular format; rather it suggests the use of established format registries and leaves it to the individual publishers to decide on the acceptable formats within their communities. While PDF-A is designed to be an archival format, caution should be used in adopting/converting to the format. Some valid content could be modified or lost during the conversion process. The TWG prefers not to include it as a recommended format, although there is not prohibition either.
Comment
On page 12, consider that "encoded as plain ASCII text" be changed to UTF-8. Plain ASCII might be too limiting for handling file names from non-English authors.
Response
The Recommendation has been modified to make the change, also noting that ASCII is a subset of UTF-8, so file names without extended characters will be unaffected.
Page 14 of 18

Summary
Role of DataCite
Comment
The description of the role of DataCite is very weak: In some cases, datasets associated with an article may have been registered via DataCite, a registration agency focused on research data. If that is the case, the publisher should not re-register the dataset through CrossRef, but simply link to the DOI already assigned to the dataset. There is a joint statement between STM
Association and DataCite (and CrossRef signed it as well): http://datacite.org/node/65 In the self-image of DataCite it says: Assigning persistent identifiers to datasets
By working with data centres to assign persistent identifiers to datasets, we are developing an infrastructure that supports simple and effective methods of data citation, discovery, and access. Citable datasets become legitimate contributions to scholarly communication, paving the way for new metrics and publication models that recognise and reward data sharing.
Supporting file: http://www.niso.org/apps/group_public/download.php/9504/2012_06_14_STM_DataCite_Join t_Statement.pdf
Solution
DataCite is a non-commercial registration agency for datasets and datasets should be registered by DataCite. DataCite and CrossRef make the linking between articles and research data possible.
Response
The recommendation already states in the 3 rd paragraph of section 3.1 that if a DataCite
DOI exists, the supplemental material should not be re-registered. On page 4, the table entry on Supplemental Material DOI also references the DataCite DOI.
Also, as described in the response to a separate comment form DataCite, section 3.1 was modified as follows: Publishers should be aware that datasets associated with an article may have been registered with DataCite, a registration agency focused on research data. If that is the case, the publisher should not re-register the dataset through CrossRef, but simply link to the DOI already assigned to the dataset. Publishers should encourage authors to include DataCite DOIs in their article if they have registered the dataset.
Page 15 of 18

General:
 [p. 4, 5 th bullet] Even if the same set of Supplemental Materials is used for more than one article, it is either copied and added as Supplemental Material to an article, or referred to from an article – the same physical file is not really supplemental to multiple articles. Only external objects can be “shared” by multiple articles – through references.
Response
This point in the Recommendation has been removed.

Shouldn’t there be recommendation for: o allowed updates to Supplementary Materials metadata elements post-finalpublications, e.g. in case of errors; I can imagine that some metadata elements will be allowed to be updated and others not
Response
The BWG has offered the following response: There is a possibility of two kinds of error in the metadata:
• A typo or an error in transcription—in this case the preferred approach is to correct the error without an erratum notice. Nonetheless, the good archivist will record the changes in the metadata kept internally.
• Wrong content, such as the wrong file name, an incorrect description, or an error in the file size—in this case the preferred approach is to correct the error and issue an erratum.
Note: The question was interpreted to mean an error only in metadata elements, not in the content itself. If there is an error in the Supplemental Materials, issuing an erratum fits the recommended practice. o retractions or removals of supplemental materials, esp. partial ones – i.e. one or more supplemental materials, associated to one article, need to be retracted/removed, but not the article itself;
Response
The BWG has offered the following response: The recommended practice is to avoid removing content whenever at all possible; instead the content should be watermarked
“Retracted” and a retraction notice issued. If legal or ethical issues absolutely require removal, a “tombstone” should be left in place.
The original metadata would not change; however, the package would now include another file: the retraction notice. Consequently, there would be another metadata element.
Page 16 of 18

Metadata elements:

Article Metadata o should be specified in details; o can this be optional, when an article DOI is present?
Response
The <article-metadata> element is required, but is a container element. The <articleidentifier>, where the DOI would be given, is the only required content within
<article-metadata>. Therefore, the only way the <article-identifier> could be given is when <article-metadata> is also present. No other <article-metdata> is required.
Optional article metadata could be included at the publisher's discretion.

Supplemental Material File Metadata o this seems to (partially) overlap with the next element “Supplemental Material
Formats”; either this element can also include “file format” or a separate element “Formats” is needed.

Supplemental Material Formats o see above
Response
This was due to confusion between containers and elements in the initial way the table was presented. The new table representation makes the relationship clearer.
 Supplemental Material Title and Caption o it is not sufficiently clear what the difference is and why/when two different elements would be needed; if they are needed, adding more details and an example for “Title” will be useful.
Response
The description of Supplemental Material Title is changed from "A title, if any, for the Supplemental Material." to "If the Supplemental Material object has been given a title, this element contains that title". Supplemental Material can contain a variety of different types of content. It may include a supplemental figure, which could have a caption. It could contain a PDF file which contains paragraphs of text, and which has its own title. A simple example for a title might be "Supplemental Material for
ARTICLE-TITLE".
 Supplemental Material Label and Caption:
Page 17 of 18

o it is not sufficiently clear why these are flagged as “optional” and not “required”; they are a great help to improved discoverability.
Response
They are optional because not all supplemental materials have those elements.
Page 18 of 18