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

Support ORCID in MTD secition #202

Open
sneumann opened this issue Oct 31, 2021 · 4 comments
Open

Support ORCID in MTD secition #202

sneumann opened this issue Oct 31, 2021 · 4 comments

Comments

@sneumann
Copy link
Member

sneumann commented Oct 31, 2021

Hi,
in addition to the name and eMail, the MTD section should support the ORCID as an optional persistent identifier for people
somewhere near:

https://github.com/HUPO-PSI/mzTab/blob/master/specification_document-releases/2_0-Metabolomics-Release/mzTab_format_specification_2_0-M_release.adoc#6215-contact1-n-email

[[contact1-n-orcid]]
==== contact[1-n]-orcid

[cols=",",]
|===================================================
|*Description* |The contact’s Open Researcher Contributor Identifier (ORCID).
|*Type* |String
|*Mandatory* |False
|*Example* a|
....
MTD contact[1]-email 0000-0002-1825-0097
…
MTD contact[2]-email 0000-0002-9079-593X
....
|===================================================

This applies to multiple mzTab-*, and could go in at the earliest convenience of the respective standards. Please don't close the issue upon adding to one of the standards, instead remove the label e.g. proteomics-part since it'll need to still be added to the next metabolomics (point ?) release.

Yours,
Steffen

@nilshoffmann
Copy link
Member

Seems like a good idea. I would propose to use the orcid suffix. An orcid consists of four four number blocks, separated by a hyphen.

MTD contact[1]-orcid 0000-0001-5000-0007

See https://support.orcid.org/hc/en-us/articles/360006897674-Structure-of-the-ORCID-Identifier for the ORCID identifier structure.

nilshoffmann added a commit to lifs-tools/jmzTab-m that referenced this issue Nov 26, 2021
@nilshoffmann
Copy link
Member

@andrewrobertjones @sneumann Do we have an instruction manual on how to proceed with incremental version changes of spec docs? I would like to bump the version to 2.0.1 when I incorporate this change, since it is an additional element and should be transparent to older version readers and writers. The element will be optional. Current document version is 2.0.0-Final March 2019 (RELEASE). Should we open an official merge window of a few weeks / months to gather feedback or additions?

@nilshoffmann nilshoffmann added this to the mzTab-M 2.0.1 milestone May 4, 2022
@nilshoffmann
Copy link
Member

Proposed change to the spec doc is in #209

@sneumann
Copy link
Member Author

Are there other changes pending that could be suggested as 2.0.1 and decided en-bloc
at the PSI Spring Meeting 2023 ? Yours, Steffen

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

No branches or pull requests

2 participants