JOIN/SIGN UP
Already a Member? |
GET INVOLVED
Understanding and Engaging in COVESA Expert Groups & Projects |
COLLABORATIVE PROJECTS
HISTORICAL
SDV Telemetry Project - On Hold |
Already a Member? |
Understanding and Engaging in COVESA Expert Groups & Projects |
SDV Telemetry Project - On Hold |
We use cookies on this site to enhance your user experience. By using this site, you are giving your consent for us to set cookies. |
You are viewing an old version of this page. View the current version.
Compare with Current View Page History
« Previous Version 17 Next »
Disclaimer
This proposal is just that, a proposal. So, contributors are very welcome. If any ideas or assertions presented in this draft are incorrect, do not hesitate to share your own view by commenting on the page or contacting the author. The principal intention of sharing these ideas is to find synergies and joint agreements on the best possible next steps for the data modeling group. In this sense, I tried to point out aspects where I believe there is room for improvement with as much constructive criticism as possible.
This page describes the proposal to restructure the data modeling activities within COVESA. First, the current state is presented to provide the necessary context. Then, the proposal is introduced.
So far, the data modeling activities in COVESA have been primarily centered on the continuous development and maintenance of the Vehicle Signal Specification (VSS) and the tools that parse VSS into different formats. In the current setup, there is no clear description of what requirements (i.e., functional and non-functional) are driving the design of the data model. It seems that the primary purpose of VSS is to serve as a naming convention for the properties of the vehicle. Nevertheless, there is little attention given to the separation of concerns:
The figure above shows how VSS modeling belongs to the conceptual area. To use the specification described in VSS (i.e., a "vspec" file), one has to parse it into a specific format (e.g., JSON) by using the VSS tools. The tools are the mechanism that makes the VSS data model usable in the application area. From the practical point of view, the application area needs a specific schema that determines the structure in which the data is to be stored. In this context, we mean long-term storage (e.g., a database) or short-term storage (RAM and variables' allocation during application execution).
In the current setup, the whole data model is taken one-to-one and parsed as the schema for the application area. Then, it is up to the specific implementation to use custom mechanisms to ignore the overhead when only some concepts defined in the data model are required or used. Although this aspect has shown no significant limitation until now, it becomes relevant when multiple domains are involved. Therefore, with the increasing interest in adding other domains apart from vehicle-specific data, it is crucial to define a data modeling strategy that can scale beyond tree hierarchies and vehicle-specific data.
One may argue that, with the current setup, it is also possible to describe a customised shorter spec file or use functions (e.g., overlays) to define the specification that matches the needs of the application area. Although possible, that implies creating disparate data models. Ideally, the concepts should be modelled only once in the conceptual area to serve as a controlled vocabulary. Then, an arbitrary selection of the concepts and some modifications to the constraints (e.g., min, max, etc.) can deliver the schema needed in specific use-cases, without affecting the standard definition of the concepts. Hence, the following section propose a few specific tasks to improve the data modeling workflow.
The idea is to define the data modelling workflow for COVESA in terms of the conceptual area (i.e., development and maintenance of the controlled vocabulary) and the application area (i.e., tools that construct a usable schema out of the data models for a particular use case).
In the conceptual area, there should be a clear step-by-step guide on how to work with two different levels of expressiveness. This consideration is needed because a tree hierarchical model alone (what VSS has been so far) is not the best model type to handle some upcoming needs, such as data integration. Hence, the model might be selected depending on the user needs.
(less expressive) Tree hierarchical model, good for:
Information classification according to a given criteria (e.g., taxonomy, meronymy, custom tree.)
Naming convention following a dotted notation (i.e., concatenation of the branches)
Machine readable and uniquely identified resources (If using RDF and SKOS standards)
(more expressive) Ontology, good for:
Data integration
Concepts re usability
Reasoning
Multiple hierarchies
Knowledge representation
In the application area, the tools have to provide a mechanism to "cherry pick" (i.e., to arbitrary select) concepts of interest from one or multiple domains, including the context and pointers to the uniquely identified definition of the concepts.
In other words, the proposal is not to enforce the use of ontologies. It is rather providing a common agreement on how and when to use what data model. The idea is better explained with the following figure, which is explained below:
The simplicity of VSS has proven to be a successful approach for the continuous contribution of Subject Matter Experts (SMEs); just by modifying a text file, discussing the changes, and creating a pull request. The approach itself should be generalized to serve as a guideline to describe and maintain one hierarchy. The idea here is to abstract the modelling approach used in VSS and describe it with generic terms that might be re used with other domains. This implies doing some minor adjustments to geralize the YAML-based modeling approach, and also defining a rule set to support COVESA participants to identify the need of a new tree model.
People often refer to a hierarchical tree data model as a taxonomy. However, this is not always the case. Depending of the meaning of the implicit relationship between branches of a tree, the hierarchy can be:
Tree hierarchy type | Implicit relationship | Example |
---|---|---|
Taxonomy | ChildBranch -- Sub class of --> ParentBranch |
|
Meronymy | ChildBranch -- Part of --> ParentBranch |
|
Custom | ChildBranch -- Custom --> ParentBranch | VSS |
To handle these semantic differences, the following is proposed:
Powered by a free Atlassian Confluence Community License granted to COVESA. Evaluate Confluence today.