validator

[jcolomb]

@frederik @xldrkp should look into this. We will get a json intermediate for the validation.

@jcolomb will write some documentation for entries when we will require specific entries (CREDIT and PID for instance).

[frederik]

Just a quick dump of knowledge of what I've found to work:

In our project (MIT) we currently use typescript-json-schema to generate a JSON schema from a TypeScript definition. [Examples are for templates but you get the idea].

I am sure this exists in other languages as well, but nodejs is generally widely supported.

Schemas could then be integrated into development (e.g. VS Code in yaml.schemas) or directly into an online instance of Monaco YAML or be used to generate a generic UI like JSON Editor.

In the long run - I am convinced - these will not be enough to get the typical MS Word users to enter data like that because it is still too technical - but it could be a dynamic start for people to experience the format without having to do a setup.

[xldrkp]

@frederik I agree with your assessment of the situation. The closest approach to enter meta data for non-tech-savvy authors is the tenzing project. What if we wrote a mapper from the spreadsheets to the schema and put a validator in the middle?

[jcolomb]

That is the plan for the tenzing project: spreadsheet -> text works quite good at the moment, but future version would like to do spreadsheet -> JAMS -> all different outputs we can think of (text, jatsxml, bioarchiv spreadsheet, gin yaml, .cff, zenodo.json, manubot yaml, ...).

Another point is to do orcid -> jams -> spreadsheet to initialise the spreadsheet (user friendly, easy to share)...

[xldrkp]

What stack is this written in? R?

[jcolomb]

It is in R and RShiny, but the plan is to move it to JS I think @marton-balazs-kovacs ?

[xldrkp]

Then I'd be in. What about leaving G**** behind and give https://baserow.io/ a try?

[marton-balazs-kovacs]

I am thinking of rewriting tenzing by using a MEVN stack. I have two goals, to make managing contributor information easy on the researchers and nudge them to keep their ORCID updated. The new app would take a slightly different approach than using tables.

[marton-balazs-kovacs]

So my plan is to create a frontend for tenzing with authentication and table editing within the app. All the contributors' tables (the table that stores the contributors' information for a project) would be stored in JAMS format in the backend. For this, it would be great if we could create a standalone API that takes the information from the table and validates it first, then transforms it into the JAMS schema. This API could be used by the frontend to communicate with the backend upon table editing. What I am not sure about is that should we send only the changed info through the API on each edit or should we send the whole table each time an edit happens.

[mjaquiery]

PR #52 includes documentation about validating the JSON schema with an onlin jsonvalidator. YAML is a superset of JSON, so the JSON will work just fine here.