Closed zzjl20 closed 5 years ago
Please try without parentheses. [M+CH3COOH-H]- will pass the validator. We have not implemented parentheses in PRECURSOR_TYPE.
Thank you so much! Would you mind to modify 2.5.1 Sutag
Thank you so much! Would you mind to modify 2.5.1 Sutag
Thank you. I fixed this.
Thank you for contribution. I would like to integrate your pull request. But because there were some issues i have forked your repo and fixed things there. I will give you a list with issues, so that you can adjust your release procedure for future contribution. -Please make sure that there are no tabs or aditional whitespaces in the peak list. We found that this breaks our RecordDisplay. Thats why we made the validator more strict. -Please check your InChI to have 'InChI=1S/' in the biginning, not just 'InChI=1/' -We do not support directory sturtures deeper than contributor/recordfile.txt. Thats why I merged the LQA and LQB subdirs
We also try to make our release procedure more robust at the moment and we constantly improve the validator to identify all known issues. Part of the new release procedure is to commit pull requests to a development branch only and to use the development branch of the validator for validation. I will adjust instructions on the README soon.
Re the InChIs, depending how they are generated, you will need to select the "standard InChI" option to generate with IS/ at the beginning, not 1/ ... Please also check that the InChIKeys are also the standard ones (SA-N at the end ...)
@meier-rene did you just substitute letters, or regenerate the entire InChIs and InChIKeys?
I fixed the InChI by substituting '1' with '1S' and regenerated the InChI-Key from the InChI.
After the modification of the InChIs the InChI-Keys didnt fit to the InChIs any more and the validator was marking them invalid. '1'->'1S' change did only change the last 2 letters of the InChI-Key.
It would be better to regenerate both standard InChI and InChIKey from the SMILES using the standard options. The “S” marks that the standard settings have been used, it’s dangerous to just substitute a letter and hope the rest matches … because there are a variety of options that can be used to create the non-standard forms …
I checked again for this PR that the InChIs are identical to regenerated InChIs from SMILES.
Thank you so much! Would you mind to modify 2.5.1 Sutag
I uploaded MSJ 63 records here. I found https://massbank.eu/MassBank/RecordIndex MSSJ have 177 records but GitHub here are 115 records now (May 8th.) There are some mistakes on massbank.eu. So how can I fix the mistake?
There is nothing you can do about that and it is not really a mistake. The 115 records are in the master branch. Your new records have been added to the dev branch. Apparently @tsufz has switched the datasource of MassBank.eu to dev branch. That's why your new records are visibl there. I didn't know about that. @tsufz: that means we need to merge dev of the webinterface to master soon and roll it out, Because I do not check compatibility of records in dev with code in master.
And now a little bit longer explanation: At the moment we try to make our release cycle a little bit more robust. Thats why we have introduced a dev branch for data. From now all new records will go first to dev and from there will be merged to master on a regular basis(maybe monthly but that iss open for discussion). Only master should be visible on MassBank.eu. If contributors of new data would like to have a view on there recent submission they can check out the dev server at https://msbi.ipb-halle.de/MassBank/RecordIndex. There you can find all 178 records of the MSSJ contributor. You might recognize that there is one record more on the dev server compared to MassBank.eu. Your contribution contained a new ionization technique SIMS for one record which is not supported on master. This record gets rejected. The dev code supports SIMS and this record is accepted to the database. I haven't updated the documentation to contain details about he procedures of the new release process because it is not completely finished. But there is one thing you can do to make things a little bit smoother: Please create your pull requests against dev branch in the future.
Hi, I suggest a revert of the commit to the master branch and a resubmission to the dev branch. I would like to avoid a mixup of the branches by now in order to keep everything clean.
Thanks for the explain. @meier-rene One of my new record author wants to show the MSSJ dataset on massban.eu in a lecture next week. He found the new record shows wrong author:
AUTHORS: , Masayo Sekimoto, Takemichi Nakamura, Molecular Structure Characterization Unit, RIKEN
I am pretty sure I uploaded correct records: (I can't find it on Github now, now I know that it is moved to dev branch)
ACCESSION: MSJ00076 RECORD_TITLE: (5R,11R)-5,11-dimethylpentacosane; GC-EI-TOF; MS; positive; EI DATE: 2019.01.25 AUTHORS: Masayo Sekimoto, Takemichi Nakamura, Molecular Structure Characterization Unit, RIKEN
I found not only my new added record but all MSSJ data shows "," before the the authors. @tsufz Can you please help to remove it?
You are right. The author list you submitted is correct. You can find your new record on the dev branch at this url https://github.com/MassBank/MassBank-data/blob/dev/MSSJ/MSJ00076.txt. At the top of the file list you can find a dropdown menu listing master by default. There you can switch to dev branch.
For the lecture next week I suggest that your colleague shows the record from our dev server or lives with the comma in front of the authors list. I know that there is an issue with in the processing of authors list at MassBank.eu. Unfortunately I can not fix the problem there instantly. Originally I didn't want to fix it on the old RecordDisplay because I'm preparing a new version of the RecordDisplay( preview: https://msbi.ipb-halle.de/MassBank/RecordDisplay2?id=MSJ00076) which is not finished yet. But I will try to fix this issue tomorrow on the dev server for you.
The comma is fixed on the dev server as promised: https://msbi.ipb-halle.de/MassBank/RecordDisplay.jsp?id=MSJ00076 . The real MassBank.eu server will have this fix after the next rollout.
@meier-rene Thank you so much!
I found that current validator maybe malfunction on 2.5.1 Subtag: PRECURSOR_TYPE: MS$FOCUSED_ION: PRECURSOR_TYPE [(M+CH3COOH)-H]- But other type (like [M+H]+ or [M-H]- ...) can pass the validator. Can somebody tell me what's wrong with my record?