Closed juliangruendner closed 2 weeks ago
I'd prefer the second option, i.e having some JSON object with further attributes for the defining attributes.
I assume there is currently some hardcoded default or implicitly assumed value?
If so should we change these defaultsfor each attribute once the optionality is configurable via the querying metadata files?
For instance, if I would define for each defining attribute in the Fall QueryingMetadata
definition whether its optional or not, does it then at that point make sense to treat them differently?
I assume there is currently some hardcoded default or implicitly assumed value?
If so should we change these defaultsfor each attribute once the optionality is configurable via the querying metadata files? For instance, if I would define for each defining attribute in the Fall
QueryingMetadata
definition whether its optional or not, does it then at that point make sense to treat them differently?
@paulolaup default is always "true" - if configurable the default can still be "true". whether or not the optional can then be missing i have no strong opinion about - either works in my opinion
It should be configurable via the ontology query metadata whether or not a value or attribute is optional or not (true, false).
For this the following attributes should be added to the querying metadata:
for the value:
for each attribute:
TODO: discuss @paulolaup, @Frontman50 .
the current attribute is fully defineda s follows:
where the part after the id allows you to define the id type, e.g.
the information could be potentially added in an extra attribute as follows "attribute_optional": ["Encounter.class", "Encounter.serviceType.coding:Fachabteilungsschluessel", "Encounter.serviceType.coding:ErweiterterFachabteilungsschluessel" ]
alternatively one could extend and change the attribute_defining_id_type_map as follows:
The result of setting the optional in the query metadata should lead to an update in the ui profiles as follows:
for value:
for attribute: