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

Key-value pair types? #1

Open
meowcat opened this issue Apr 3, 2019 · 4 comments
Open

Key-value pair types? #1

meowcat opened this issue Apr 3, 2019 · 4 comments

Comments

@meowcat
Copy link
Owner

meowcat commented Apr 3, 2019

Hi @michaelwitting @Treutler,
What do you think of allowing "key-value pair" / "named-array" types in the schemas?
Examples

  • COMMENT, in MassBank, is a field with free key-value associations e.g.
COMMENT UCHEM_ID 2323
COMMENT CONFIDENCE standard compound
  • CH$LINK is much easier stored as a key-value pair rather than specifying every possible link type separately. (And if you want to do an SQL database, I would recommend you do it relationally there too.)
@meowcat
Copy link
Owner Author

meowcat commented Apr 4, 2019

But now I am doubting this again, since the database id names are different between different spectral formats, so they need to be translated...

@meowcat
Copy link
Owner Author

meowcat commented Apr 4, 2019

I think this can be solved in a "hybrid" way if the deep mapping will work correctly. There might not be a need for hierarchy in the fields definitions themselves. But I would still consider an optional "parent" specification. (For my current way to specify the fields, see fields.yaml. This can change in the future)

@sneumann
Copy link
Contributor

Hi, are we aware of an "athoritative" comparison / mapping between flavours ?
I was thinking about a google doc spreadsheet with corresponding field names.
Did we start something like that at some stage ? Yours, Steffen

@michaelwitting
Copy link
Collaborator

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

No branches or pull requests

3 participants