search

RakipInitiative / ModelRepository

Joint project of EFSA, Federal Institute For Risk Assessment, DTU and ANSES to create a online model repository.
GNU General Public License v3.0
2 stars 0 forks source link

Editor vocabularies bug: wrong vocabularies for parameter #289

Open schuelet opened 3 years ago

schuelet commented 3 years ago

The parameter vocabularies should be ALL CAPS. Otherwise the editor cant deserialize the object.

image.png

image.png

miguelalba commented 3 years ago

This is an issue actually in the implementation and not the vocabularies. The parameter classification values are actually camel case and not uppercase. See https://docs.google.com/spreadsheets/d/1C6N4-YWX9OMmNStd2rYlSUaVys-aiJGLj00cD44aVc8/edit#gid=1206772622.

This is something we have to fix in the next schemas and I would just add a hot fix in the editor JS view to convert them to uppercase for now.

schuelet commented 3 years ago

I applied the hotfix to the test build.
When we change the implementation we have to make sure that older models are still operational, which probably means, to convert them in the Reader node.

miguelalba commented 3 years ago

See https://fasterxml.github.io/jackson-databind/javadoc/2.5/com/fasterxml/jackson/databind/MapperFeature.html#ACCEPT_CASE_INSENSITIVE_PROPERTIES

mfilter commented 3 years ago

I suggest yet another solution: as we do not restrict for all fields the use of a controlled vocabulary the user might for some metadata fields (e.g. hazard) provide its own freetext entry. This freetext entry should of course not be deleted by the editor just because it does not match any of the entries in the controlled vocabularies. Therefore -if possible- I suggest we should simply display the value that is provided in the metadata json from the model at the in-port of the FSK Editor, instead of display the "default" value of the controlled vocabulary. Of course this may create trouble further down the line, but I don't see a good alternative.

schuelet commented 3 years ago

@mfilter For the time being the parameter problem is fixed.

@miguelalba Correct me if I am wrong, but we differentiate between controlelled vocabularies, which are merely "suggestions" and actual relevant code that we need to work with ("Enums"). These enums are strict and can't just be overwritten by the user. On the other hand, we could in the future just not use enums and use vocabularies for everything, including the select-boxes.