Determine customization possibilities for models #10
Description
Responsible: @azaroth42 @no-reply @mjgiarlo @hannahfrost @guegueng
Accountable: @mjgiarlo @hannahfrost
Consulted: ?
Informed: Directors
Issue:
There should be a lightweight way to customize models provided in HyBox. If no customization is possible, then the risk is that adopters will turn away from the product for the wrong reasons. For example, if the would-be adopter "needs" to have a certain metadata field, but there is no possibility of adding additional fields, then that might be considered a deal-breaker. The decision to be made is the extent to which customization of models is to be implemented, from a documented set of choices with advantages and likely costs/risks.
The subsequent side of this is that the information needs to be exposed to the end user in a reasonable way.
Proposal:
Responsible to discuss and document decision on most appropriate way forwards, taking into account cost to implement. Initial strawperson list to discuss and extend:
- No customization
- Create hyboxlocal namespace and shove everything in there
- Selection from a long list of pre-determined predicates / options
- JSON-LD contexts to perform mappings only in JSON input
- Allow assignment of human readable label to mapping
- Allow creation of terms, labels/templates, and expression of equivalence to external
- Allow full on ontology modeling