Closed hammar closed 3 years ago
Noted an issue with enums in ADT Explorer: they apparently cannot be unset, once set, and the ADT Explorer GUI defaults to showing an enum field as filled with one (the first?) value in the enum schema. I.e., it's really easy in the GUI to mess up enum-using twins and not be able to undo one's changes. So, for those cases where we use enums: should we provide a safe "unset" option in the enum?
As a matter of fact, ADT Explorer does not seem to play nice with enums GUI-wise even with a solution such as the one proposed above. Perhaps best to update it to do so, rather than implement workarounds in the models.
@hammar , For ADT-Explorer I agree with this " As a matter of fact, ADT Explorer does not seem to play nice with enums GUI-wise even with a solution such as the one proposed above. Perhaps best to update it to do so, rather than implement workarounds in the models." Could you please show repro steps, not sure I understand correctly.
@cschormann, could you please make sure you address ADT Explorer issues with enums? See above.
Thanks
@hammar @alinamstanciu I have just merged a bunch of changes into Willow Ontology to align with the spreadsheet I prepared on this Capability topic: https://github.com/WillowInc/opendigitaltwins-building/tree/main/Ontology/Willow/Capability
There are a few differences from what I see here and I've fully populated the Capability enums for position, phenomenon, etc.
@hammar , For ADT-Explorer I agree with this " As a matter of fact, ADT Explorer does not seem to play nice with enums GUI-wise even with a solution such as the one proposed above. Perhaps best to update it to do so, rather than implement workarounds in the models." Could you please show repro steps, not sure I understand correctly.
@cschormann, could you please make sure you address ADT Explorer issues with enums? See above.
Thanks
I'm uploading five pictures illustrating different parts of the process/problem:
@hammar @alinamstanciu I have just merged a bunch of changes into Willow Ontology to align with the spreadsheet I prepared on this Capability topic: https://github.com/WillowInc/opendigitaltwins-building/tree/main/Ontology/Willow/Capability
There are a few differences from what I see here and I've fully populated the Capability enums for position, phenomenon, etc.
Posting in the same response here as I did to Alina's other comment (as I'm not sure if you're pinged on that):
I based this list on the Optio3 list, which I took to be the target list for the first iteration -- but changing to the list provided by Rick is not a problem and I will do so shortly (in an hour or so) and update this PR. I'll also rename substance to phenomenon.
The phenomena and position lists are now updated, I hope this is more in line with expectations.
Note that since RDF, JSON, and JSON-LD do not care about key ordering, enums can sometimes be serialized in a semi-random order when the models are generated. This is obviously less than ideal and I will try to dig into the relevant libraries to see if I can mitigate the effect.
@hammar , For ADT-Explorer I agree with this " As a matter of fact, ADT Explorer does not seem to play nice with enums GUI-wise even with a solution such as the one proposed above. Perhaps best to update it to do so, rather than implement workarounds in the models." Could you please show repro steps, not sure I understand correctly. @cschormann, could you please make sure you address ADT Explorer issues with enums? See above. Thanks
I'm uploading five pictures illustrating different parts of the process/problem:
- The enum schema
- Twin that uses this schema. Note that "substance" and "position" fields are seemingly prepopulated with the first enum value for the respective property, in spite of these properties not actually being set on the twin yet.
- Result of saving the twin with that default value prepopulated from the schema. Note the lack of patch.
- Saving a value that does not exist in the enum definition. Note that this actually saves the default (first listed value), rather than throw an error as expected.
- Saving another value that is consistent with the enum schema definition. In this case I manually typed in "Steam", an allowed value, and saved. Note that this actually saves the default (first listed value) rather than the one I entered.
Thanks Karl!!!!
@hammar @alinamstanciu I have just merged a bunch of changes into Willow Ontology to align with the spreadsheet I prepared on this Capability topic: https://github.com/WillowInc/opendigitaltwins-building/tree/main/Ontology/Willow/Capability There are a few differences from what I see here and I've fully populated the Capability enums for position, phenomenon, etc.
Posting in the same response here as I did to Alina's other comment (as I'm not sure if you're pinged on that):
I based this list on the Optio3 list, which I took to be the target list for the first iteration -- but changing to the list provided by Rick is not a problem and I will do so shortly (in an hour or so) and update this PR. I'll also rename substance to phenomenon.
@hammar , are we eventually going the way Rick did it ? https://github.com/WillowInc/opendigitaltwins-building/tree/main/Ontology/Willow/Capability/Sensor Thanks
Hi all, I just completed another large push within Willow Capabilities as I've iterated on the ideas posted above by @hammar around clustering, etc. Here's a link to Willow Capability: https://github.com/WillowInc/opendigitaltwins-building/tree/main/Ontology/Willow/Capability
Key updates:
@rszcodronski that looks very promising. I'm a bit under-the-weather at the moment (hopefully just a cold..) and not operating at full capacity; so a more thorough analysis from me may take a day or two more. In the interim I've asked @erikoskarwallin to check this design versus the Idun platform and needs, and see if we can get the REC consortium on board. Personally I think (again, subject to actually looking a little deeper, once my head is working properly) that I'm on board.
Cheers,
Karl
Note that this contains the REC view on quantitysensors, including semantic typing where applicable, etc. I put together this list with the goal to fulfil the Optio3 requirements, but it is not a 1:1-mapping of every exact concept against Optio3 and it is shorter and structured somewhat differently (I'd argue more concise/usable, but I recognize that opinions may diverge on this) than the Willow list.
Anyone else who has input on this, or should we merge and proceed?
Noted an issue with enums in ADT Explorer: they apparently cannot be unset, once set, and the ADT Explorer GUI defaults to showing an enum field as filled with one (the first?) value in the enum schema. I.e., it's really easy in the GUI to mess up enum-using twins and not be able to undo one's changes. So, for those cases where we use enums: should we provide a safe "unset" option in the enum?