Patrick: This is just a starting point of a discussion and not necessarily fully thought-out yet.
The basic idea is that a schema (LinkML or otherwise) generally can't capture everything about how a tool to collect data adhering to that schema should look or behave. Obviously the schema can inform some sensible defaults (i.e. provide a dropdown menu when a value must be chosen from an enumeration) but it can't capture things like "suggest terms retrieved from this arbitrary endpoint". Or "this field should be omitted from the entry UI because it will be populated by a separate process" (see #337). For use cases like these that are common enough, it would be nice for data-harmonizer clients to not have to write a lot of custom code and instead simply provide some configuration.
The changes here represent a very basic sketch of what a UI configuration approach might look like. A data-harmonizer application (i.e. web/index.js) provides a UI configuration object to the DataHarmonizer constructor (an application could even store this configuration in a standalone JSON file). The DataHarmonizer class is responsible for interpreting this configuration and applying the correct settings internally. The specific example implemented here is directing the DataHarmonizer instance to use an OLS-based autocomplete for a particular field.
It's not implemented in this proof-of-concept, but you could also imagine a UI config like:
{
"fields": {
"internal_id": {
"hidden": true
},
"look_but_dont_touch": {
"readonly": true
}
}
}
I could also imagine non-field-specific configuration going outside of the "fields" key (e.g. #334):
{
"numFrozenColumns": 2
"fields": {
...
}
}
Again, this is just a conversation starter. I'd be interested to know if this might address (or not) other cases.
....
Damion: Hi Patrick, sorry for delay in looking at this closely - I'm realizing discussion was held up. I totally see need to add DH interface configuration such as number of columns to freeze, but it seems like there are two types of configuration - ones that don't depend on a specific schema/class at hand, and those that do, i.e. with some classes it makes sense to freeze 2 panes, or hide x columns.
I was wondering for configuration how much mileage we could get out of encoding user interface behaviour right into a class or slot annotation, such that it could apply to any tool that displays it, if desired? Or name that tool explicitly in the annotation, e.g.
class_X: {
annotations: {
ui_behaviour: {
DataHarmonizer: { // Optional layer ???
numFrozenColumns": 2
}
}
...
slots: {
"internal_id": {
"annotations": {
ui_behaviour: {
DataHarmonizer: { // Optional layer ???
"hidden": true,
"readonly": true // e.g.
}
}
}
}
Or this structure could be separate from schema content, but could be added to new DH instance as you have it:
const uiConfig = { ...
What this would do is enable better code synchronization and not have it that people are manually adapting their code to match a change or deprecation in a class or slot reference.
Patrick: This is just a starting point of a discussion and not necessarily fully thought-out yet.
The basic idea is that a schema (LinkML or otherwise) generally can't capture everything about how a tool to collect data adhering to that schema should look or behave. Obviously the schema can inform some sensible defaults (i.e. provide a dropdown menu when a value must be chosen from an enumeration) but it can't capture things like "suggest terms retrieved from this arbitrary endpoint". Or "this field should be omitted from the entry UI because it will be populated by a separate process" (see #337). For use cases like these that are common enough, it would be nice for data-harmonizer clients to not have to write a lot of custom code and instead simply provide some configuration.
The changes here represent a very basic sketch of what a UI configuration approach might look like. A data-harmonizer application (i.e. web/index.js) provides a UI configuration object to the DataHarmonizer constructor (an application could even store this configuration in a standalone JSON file). The DataHarmonizer class is responsible for interpreting this configuration and applying the correct settings internally. The specific example implemented here is directing the DataHarmonizer instance to use an OLS-based autocomplete for a particular field.
It's not implemented in this proof-of-concept, but you could also imagine a UI config like:
{
"fields": {
"internal_id": {
"hidden": true
},
"look_but_dont_touch": {
"readonly": true
}
}
}
I could also imagine non-field-specific configuration going outside of the "fields" key (e.g. #334):
{
"numFrozenColumns": 2
"fields": {
...
}
}
Again, this is just a conversation starter. I'd be interested to know if this might address (or not) other cases.
....
Damion: Hi Patrick, sorry for delay in looking at this closely - I'm realizing discussion was held up. I totally see need to add DH interface configuration such as number of columns to freeze, but it seems like there are two types of configuration - ones that don't depend on a specific schema/class at hand, and those that do, i.e. with some classes it makes sense to freeze 2 panes, or hide x columns.
I was wondering for configuration how much mileage we could get out of encoding user interface behaviour right into a class or slot annotation, such that it could apply to any tool that displays it, if desired? Or name that tool explicitly in the annotation, e.g.
class_X: {
annotations: {
ui_behaviour: {
DataHarmonizer: { // Optional layer ???
numFrozenColumns": 2
}
}
...
slots: {
"internal_id": {
"annotations": {
ui_behaviour: {
DataHarmonizer: { // Optional layer ???
"hidden": true,
"readonly": true // e.g.
}
}
}
}
Or this structure could be separate from schema content, but could be added to new DH instance as you have it:
const uiConfig = { ...
What this would do is enable better code synchronization and not have it that people are manually adapting their code to match a change or deprecation in a class or slot reference.