For discussion: Add support for definition #671
Conversation
| @@ -20,8 +20,6 @@ SteeringWheel.Position: | |||
|
|
|||
| ``` | |||
|
|
|||
| If `allowed` is set, `min` or `max` cannot be defined. | |||
There was a problem hiding this comment.
This is not enforced in vss-tools. In standard catalog as of today we only use allowed for strings, and there min/max does not make sense, but nothing that forbids it.
There was a problem hiding this comment.
In the same manner that "default" only applies to attributes, but nothing forbids assigning a default to other signals.
| @@ -14,17 +14,32 @@ entry example is given below: | |||
| ```YAML | |||
| Speed: | |||
| type: sensor | |||
| description: The vehicle speed. | |||
| definition: Vehicle speed relative to the X-axis of the intermediate axis system as defined by ISO 8855 section 2.13. | |||
There was a problem hiding this comment.
This is a good exercise, trying to find a definition for vehicle speed. I looked a bit in ISO 8855 trying to find correct words, but the result is not that intuitive. it tries to capture:
- If the vehicle is sliding sideways down an icy hill speed shall be 0, as we only are interested in the "forward" component
- We are interested in the speed relative to the surface, i.e. it shall be 0 if the vehicle is stuck with spinning wheels in mud
- We are not interested in the speed relative to vehicle x-axis, if the rear of the vehicle is heavily loaded there might be small difference between speed mentioned along vehicle x-axis and the intermediate x-axis
But I am no vocabulary expert, this just shows that it isn't that easy. Then we can also discuss if we want to specify what a signal ideally should contain, or rather what it is allowed to contain. Most likely we consider it OK that speed is reported wrong if one or more wheels are stuck in mud.
There was a problem hiding this comment.
Indeed, this isn't easy. A vehicle on the back of a two truck clearly has a speed as would be reflected by GPS, but I would bet most car will report a Vehicle.Speed of 0 in that case. That leads to thoughts I have been having on the need to have an accurate description of each signal, where in this specific case of Vehicle.Speed the description would be something like "speed of the vehicle when ignition is turned on and the vehicle is self-propelled" with a comment such as "refer to GPS speed" for a vehicle speed in situation where the actual movement of the vehicle is of interest (such as when being towed or slipping down an icy hill with brakes fully on)".
Signed-off-by: Erik Jaegervall <[email protected]>
erikbosch
force-pushed
the
erik_definition
branch
from
afbf3f1 to
1f8b76e
Compare
|
Meeting notes:
|
|
Closing this one for now as there does not seem to be much support for it |
At the AMM we briefly discussed "description" vs "definition". I had a mail conversation with Alan to get some more input, see response below. My conclusions based on the answer and the discussion at the AMM:
Based on this I propose:
definitionas an optional member of a signal declaration. That way we can start adding definitions if we like.definitionfor most signals we can decide on time plan to make definition mandatory and description optionaldefinitionas an allowed/expected attribute in vss-tools, but for now no other explicit changes. this meansdefinitionwill be included in Yaml/JSOn output, but ignored for other outputsThis PR propose a possible change for documentation. If we agree to do the change a corresponding change in vss-tools must be implemented (low effort). This PR also include some unrelated changes to make sure documentation and actual behavior in vss-tools match.
Info received from Alan
Hi Erik,
The important distinction between definition and description is that a definition is a more formal specification that includes the necessary and sufficient conditions. It's the king of specification you find in a dictionary. To state the obvious, that provides unambiguous semantics. But the real reason it's critical is that those necessary and sufficient conditions translate to formal axioms in an ontology and can be used for inferencing and automation.
A description, on the other hand, provides any kind of information that helps humans conceptualize the entry. It can include examples, physical properties, etc.
If I'm defining human being, then I can say that it's a culture-bearing primate classified in the genus Homo, especially the species H. sapien. It meets the necessary conditions because there can be no human being who is not a culture-bearing primate classified in the genus Homo. It includes the sufficient conditions because every a culture-bearing primate classified in the genus Homo is a human being.
If I'm describing human being, then I can say it has superior mental development, power of articulate speech, and upright stance. However, we are finding that bonobos and even some monkeys can fit that description. So it's not a definition.
Typically, we use definitions for reference data - data whose consistency, semantic precision, and operational impact require centralized curation prior to use. We use descriptions for master data and transactions - data for which changes in state are managed as a routine course of business. I would classify the objects, properties, and signals in VSS as the former.
In sum, it's not just changing the name but ensuring that the content contains the necessary and sufficient conditions.