Added additional sensor categories + substance and position properties

[hammar]

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?

[hammar]

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.

[alinamstanciu]

@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

[rszcodronski]

@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]

@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.

[hammar]

@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]

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.

[alinamstanciu]

@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!!!!

[alinamstanciu]

@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

[rszcodronski]

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:

• Introduced subclasses to Sensor/Setpoint/Actuator to cluster on the following: Quantity, State
• The above allows us to move the lastValue to the Quantity/State level since all interfaces below all have the same schema (double, boolean, percent unity)
• The Willow ontology is representative of my current thinking. If/once the concepts are taken up by this ontology, we will remove duplicate properties (i.e. lastValue) and just extend this ontology.
• Ideally, in the future I would like to have the interfaces within StateSensor, StateSetpoint, and Actuator extend the State class but at this time we cannot have the same property, lastValue, defined in both.
• I believe we should keep State at the same level of Sensor and encourage end users to use this when describing the state of the parent twin. These are often virtual concepts that don't have actual physical sensors which determine their value.

[hammar]

@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

[hammar]

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?