Inconsistencies in the masterdata

[JosePizarro3]

When exploring the main instance of openBIS, we realized some inconsistencies from the point of view of creating a generic Data Model:

• Some entities have the code defined to be inheriting from non-existing entities. Example: RAW_MATERIAL.ALUMINIUM, RAW_MATERIAL does not exist. SPECIMEN.FCG, SPECIMEN does not exist.
• There are repeated entities. Example: CONTROL.FREEZER and INSTRUMENT.FREEZER.
• There are repeated entities with different versioning. Example: STATION_LAYOUT.
• The propertyType INSTRUMENT are of dataType OBJECT, but they don't have an associate objectType
• The propertyType INSTRUMENT code can be conflicting with the objectType with the same code, same happens with PUBLICATION (both an assignment on COLLECTION: DEFAULT_EXPERIMENT and a property type of type MULTILINE_VARCHAR)
• Some property type definitions inherit have a code defined as if they were inheriting from somewhere. Example, DLS.ATTENUATOR. I think they actually mean "composition", i.e., there is an object/collection/dataset called DLS which has these properties.
• Some property type definitions are doubly defined or they are unclear. Example, PRODUCT.CATEGORY and PRODUCT_CATEGORY

[JosePizarro3]

Besides that, there are some important changes that the masterdata needs to do in order to be high-standard:

1. Some entities have a short name which is unnecessary (only acronyms could be used, otherwise, be verbose). Example: MatModel(DatasetType) (is it Material Model or Mathematical Model?) or MatSimStructure.
2. Are some entities useful or can be deleted? Example: CompEnv(DatasetType)
3. Double check the generated_code_prefix
4. If we transition to Python, can we delete most of the vocabulary types?