Open sbenthall opened 3 years ago
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?
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).
title
is if it replicates a particular.date-published-original-paper
to year
and optional month
, etc. in this section.Following up on this:
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..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
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.
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.
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.
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.
Approved:
Keep an eye out for additional metadata needed for the website, like PDF of paper file URL.
cff-version
commit
if we have a field forversion
that points to a tag?date-published-original-paper
field be filled in these cases?authors
listed the authors of the original paper, or of the REMARK?