Right now, BAM's masterdata contain the locations as controlled vocabularies. This produces some problems:
- it can only handle rooms and parents and not things like outdoor areas
- extension to other classes would require changes to a lot of object types
- vocabularies are handled as masterdata (publication problem), leading to very large vocabularies which affect performance
- relies on deprecated openBIS features (dynamic property plugin)
- information (e.g., room A is on floor B in building C on property F) is replicated for every object using the vocabulary
Locations in other BAM systems are identified with a path-like structure with / separators.
That's why @jraedler propose to change the concept to an object type:
- Locations should allow to represent all relevant and future classes without being too detailed
- Using custom locations should be possible (satellite orbits, latitude/longitude...)
- Because of BAM's location identifier (
/) can't be use as a code, we could use name to map into these
- Location classes can be used to filter in the advanced search
We would also need a defined process to handle the currently existing object types that use the controlled vocabulary when refactoring it to object type. @jraedler suggested:
- create new object type LOCATION
- create objects in BAM_GLOBAL for BAM locations using other databases as source (similar to PERSON.BAM)
- add object property to all object types that currently use the controlled vocabulary
- migrate 1) map the vocabulary into the object link, 2) delete the vocabularies from the objects, 3) delete the controlled vocabulary from the object types, 4) delete fully the controlled vocabulary
The proposed properties could be:
name (str, mandatory) --> path identifier, e.g., "Berlin/.../.../..."location_type (controlled vocabulary, optional) --> e.g., room, floor, outside...description (multiline str, optional)
These are the notes that @jraedler passed around.
Due to its character and impact with other refactoring, this can stay a bit in the backlog until we have the new structure in place. But it should definitely go into the new model.
Right now, BAM's masterdata contain the locations as controlled vocabularies. This produces some problems:
Locations in other BAM systems are identified with a path-like structure with
/separators.That's why @jraedler propose to change the concept to an object type:
/) can't be use as a code, we could usenameto map into theseWe would also need a defined process to handle the currently existing object types that use the controlled vocabulary when refactoring it to object type. @jraedler suggested:
The proposed properties could be:
name(str, mandatory) --> path identifier, e.g.,"Berlin/.../.../..."location_type(controlled vocabulary, optional) --> e.g., room, floor, outside...description(multiline str, optional)These are the notes that @jraedler passed around.
Due to its character and impact with other refactoring, this can stay a bit in the backlog until we have the new structure in place. But it should definitely go into the new model.