metadata template is unclear

[sbenthall]

• What is cff-version
• do we need a field for commit if we have a field for version that points to a tag?
• should explain the difference beween remark-name and title
• papers are often published with a year but not a day or even a month. how should the date-published-original-paper field be filled in these cases?
• are the authors listed the authors of the original paper, or of the REMARK?

[sbenthall]

It is believed that the metadata files in the REMARK directory are CFF compatible documents.
We should confirm this.
It's possible that the metadata are partitioned and CFF is only part of it?

• cff-version : for any particular cff entry, what version of cff it was verified to be compatible with.

Should the file extension be .cff?

• require a version field, reject the `commit field.

remark-name is a CamelCase(?) filename or code for the paper.
title is a phrase.

authors in the top-level section refers to authors of the REMARK.

Metadata should have a reference subsection, with the reference(s) to the original paper(s).

• within this section title is if it replicates a particular.
• Change date-published-original-paper to year and optional month, etc. in this section.
• authors in this section refers unambiguously to the paper authors

[sbenthall]

Following up on this:

• It looks like CFF is specifically a citation format for software. It has a required version field that is software specific. So it is not possible to include CFF for a paper reference without associated software as an internal part of the REMARK metadata.
• There is a part of CFF that is dedicated to references within the CFF file. We should be using this for the reference to the original paper: https://github.com/citation-file-format/citation-file-format/blob/master/README.md#notable-reference-keys I'm not sure how complete this specification is yet...
• CFF is appropriate for the REMARK repository metadata itself. But in that case, it should have a .cff file extension. This can then be validated with CFF's automatic validator.

For additional guidance/comparison, the closest thing to a YAML-only academic reference format is this proposal for citeproc YAML that may have support from pandoc: https://blog.martinfenner.org/posts/citeproc-yaml-for-bibliographies This format mirrors Bibtex as much as possible

[sbenthall]

The expectation of file name CITATION.cff conflicts with our use of this metadata as embedded in a .md file.

I wonder what motivates the use of an .md file for this YAML metadata.

[sbenthall]

If we use CITATION.cff, it would make more sense to require these in the repository itself, rather than the REMARK repository.

However, I'm not clear on the mechanics of how this REMARK repository feeds into the website.

It's possible that we should be decoupling the website configuration from the providing of citation information. The former would be better suited as part of the editorial function, see #105, than as part of the REMARK standard.

[llorracc]

A bit of background on this discussion: The origin of the md files for metadata was that they were created by Andrij (I think in collaboration with Mridul) as an ad-hoc way of keeping track of the info needed to construct the econ-ark.org launch page. But my strong preference is never to invent some half-baked and ever-evolving way of doing something if there is some existing standard that can be adopted instead, so I asked them to see whether we could use the cff standard to give some structure and standardization to our practices. The idea was to borrow from cff specs whatever elements are already part of that standard and that we also need, and only invent new fields for things that are not already standardized in cff. As you have noticed, that is more of a goal that I have set than it is something that we have already achieved. But I think you sympathize with the spirit.

[sbenthall]

Yes, got it. I do sympathize with the spirit. I think with a little more thought about processes we can achieve something even further along those lines.

[sbenthall]

Approved:

• Put the CFF file in the repository
• Look into how to automate the creation of the website configuration file as a step that's outside the REMARK standard but part of the "editorial" process

[sbenthall]

Keep an eye out for additional metadata needed for the website, like PDF of paper file URL.