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

metadata template is unclear #99

Open
sbenthall opened this issue Feb 2, 2021 · 8 comments
Open

metadata template is unclear #99

sbenthall opened this issue Feb 2, 2021 · 8 comments
Assignees
Labels

Comments

@sbenthall
Copy link
Contributor

  • 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
Copy link
Contributor Author

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 sbenthall self-assigned this Mar 5, 2021
@sbenthall
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Collaborator

llorracc commented Mar 9, 2021

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants