Semantic definition of different signal/attribute types

[felix-loesch]

In order to fully represent the different types of signals and attributes that can be defined in VSS we need to differentiate the following types of signals/attributes in VSSo:

• StaticVehicleProperty: this will be used for VSS attributes
• DynamicVehicleProperty: this will be used for VSS signals
• ObservableVehicleProperty: this will be used for read only VSS signals (sensor)
• ActuatableVehicleProperty: this wil be used for read/write VSS signals (actuator)

Orthogonal to that classification we also should differentiate between:

• NumericProperty: these properties have a physical unit and can have optionally minValue and maxValue
• EnumerationProperty: these properties do not have a physical unit but have a limited set of possible EnumerationValues

[erikbosch]

We already have part of this described in https://github.com/w3c/vsso/blob/main/vsso-core/vsso-core.ttl

But I noted some deviations or potential errors there:

vsso-core:StaticVehicleProperty a owl:Class ;
   ...
    rdfs:comment "_StaticVehicleProperty_ - Follows the definition of an [attribute](https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/attributes/) in
VSS. `StaticVehicleProperty` is meant to stay stable at least over the duration of a vehicle lifecycle.
If you expect more frequent updates, please consider [DynamicVehicleProperty](#https://github.com/w3c/vsso#DynamicVehicleProperty)"@en ;
    rdfs:seeAlso "https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/attributes/".

Lately we have said in VSS that "attribute values should typically not change more than once per ignition cycle", which is more frequently than "at least over the duration of a vehicle lifecycle"
The link https://github.com/w3c/vsso#DynamicVehicleProperty is not correct, is it?

vsso-core:ObservableVehicleProperty a owl:Class ;
    ...
    rdfs:comment "_ObservableVehicleProperty_ - Follows the definition of an [actuator](https://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/sensor_actuator/) in
VSS. It is a [DynamicVehicleProperty](#https://github.com/w3c/vsso#DynamicVehicleProperty), which can be observed but _not_ changed.
    rdfs:seeAlso "ttps://covesa.github.io/vehicle_signal_specification/rule_set/data_entry/sensor_actuator/" ;
    

Should be Follows the definition of a [sensor] shouldn't it?
See also missing h in first seeAlso

[felix-loesch]

I agree that the semantic definition of signal types is there for StaticVehicleProperty, DynamicVehicleProperty, Observable- and ActuatableProperty. What is still missing is to differentiate between NumericProperty and EnumerationProperty.
I have a proposal how that can be added.

[danielwilms]

Should be Follows the definition of a [sensor] shouldn't it? See also missing h in first seeAlso

Fixed in #20

Lately we have said in VSS that "attribute values should typically not change more than once per ignition cycle", which is more frequently than "at least over the duration of a vehicle lifecycle"

You're right. Fixed it.

Fixed the links as well.

[jdacoello]

I have a proposal to solve the extra classification in a (semantically) consistent manner.

So far, the main classification of vehicle properties has been:

• VehiclePropety
  • StaticVehicleProperty
  • DynamicVehicleProperty
    • ObservableVehicleProperty
    • ActuatableVehicleProperty

I propose to add an object property called hasVariableKind to connect VehicleProperty to a specific VariableKind. Since there are only two variable kinds either numbers or categories (what you called enumeration), it will be easy to define in the same ontology two individuals of VariableKind: Numeric and Categorical.
When the mapping is done from VSS into VSSo, the triple VehicleProperty --hasVariableKind--> VariableKind must be added.

The rest is handled by a defined class with conditions/restrictions for the reasoner, as follows:

• NumericVehicleProperty (equivalent to properties whose VariableKind is numerical) this is intended for all the properties that are quantifiable
• CategoricalVehicleProperty (equivalent to properties whose VariableKind is categorical) this is intended for all the properties that are qualitative

Resulting in a classification like this:

• VehiclePropety
  • StaticVehicleProperty
  • DynamicVehicleProperty
    • ObservableVehicleProperty
    • ActuatableVehicleProperty
  • NumericVehicleProperty (Automatically inferred)
  • CategoricalVehicleProperty (Automatically inferred)

It would be easier to maintain them instead of having them also in the hierarchy as primitive classes.
I could make a PR for this, but since the vsso-core is a file manually modified, I would like that we resolve first PR #32 to avoid mismatches due to the serialization of the file in different tools (e.g., Protege, TopBraid, etc.)

[rtroncy]

This is indeed a clean approach. Do you want to force having for ALL VehiclePropety a value for the hasVariableKind? And are we sure that no properties can have values that mix numerical values and categorical values?

[jdacoello]

This is indeed a clean approach. Do you want to force having for ALL VehiclePropety a value for the hasVariableKind? And are we sure that no properties can have values that mix numerical values and categorical values?

As of today, the VSS does not have any other kind of variable apart from numerical and categorical, which means that the mapped VSSo doesn't have it either. Even the Boolean data types indicate a category as true or false.

What could happen, however, is that in the future some other kind is introduced. For example, complex structures from camera, radar, LiDAR sensors. If that is the case, then we add the missing defined class and the extra individual needed to VSSo-core and push a version update.

In my opinion, the major benefit of this extra classification comes in the practical setup, where you might have different processing pipelines for each of the variable types. For example: the statistics of a numerical variable differ from the ones of categories.

[rtroncy]

I would not use categorical when the set of values is Boolean (true / false). Depending on the implementation, this can be translated into 0,1 and it has anyway a slightly different meaning than enumerating possible values. Can we already create a third variableKind for Boolean properties?

[felix-loesch]

How do you want to store the enumeration values then?

[jdacoello]

I would not use categorical when the set of values is Boolean (true / false). Depending on the implementation, this can be translated into 0,1

A boolean does not express a quantity, but quality or status of something.
The distinction is not because of the meaning of the data value, but rather because these variables require different processing and aggregations.

Maybe I used the wrong terms to communicate my idea:

I mean:

• Numerical in the sense that the variable can take any value within a range, and it is quantifiable (e.g., Speed)
• Categorical in the sense that the variable can take a value from a predefined set of possibilities, and it is NOT quantifiable (e.g., Gear, IsWindowSwitchOn)

See, for example, this short description of variable types.
It says that a numerical variable is quantifiable "(except numbers which are codes standing up for categories)". In the case that numbers are used to refer to a category, then we are dealing with categorical variable. And this is the case for booleans, too.

Types/Kinds of variables

To sum up, the following distinction is proposed:

• Categorical (qualitative, and NOT quantifiable)
  • Nominal
  • Ordinal
• Numerical (quantifiable)
  • Continuous
  • Discrete