Simplicity*

The quality or condition of being easy to understand, use or do

• Must be human-readable.
• Must be easily understood by Subject Matter Experts (SMEs), even when they have little to no knowledge of data modelling best practices.
• Must be useable by new comers within a reasonable period of time (e.g., a few hours).
• Must be easy to contribute (i.e., to extend the controlled vocabulary).

✅ Yes

Technology Agnosticism*

Interoperable and flexible across various platforms, devices, or environments, not tied to specific vendors, technologies, or frameworks. 

• Must be compatible with little effort to other artefacts and must not be a constrainer.
• Must work with a variety of technologies

✅ Yes

Via vss-tools.

Modularity*

Quality of being composed of separate, interchangeable units or modules that, when combined, form a complete whole, facilitating flexibility, scalability, and ease of maintenance.

Having independent components (modules) that can be developed, managed, and modified separately yet seamlessly integrated or combined.

• Must allow the use (or contribution) of only the pieces needed.
• Must be able to adopt only parts of the model that matter to the user.
• Must be able to extend and override parts of the model as needed for internal and external use.

⚠️ Partly 

Specification can be split into multiple files. However, not all components are reusable (e.g., allowed values).

Scalability & Maintainability*

Ability to grow and and handle increasing demands while being easily understood, modified, and maintained.

• Vocabulary of a domain can grow with constant effort.
• Must support a wide variety of vehicle domains (e.g. Seating, HVAC, Entertainment, Engine, etc...).
• Must support the re use of existing models or vocabularies.
• Should extend beyond passenger cars (e.g., Motorcycle).

⚠️ Partly

Yes in the sense that the vocabulary of vehicle properties can be further extended. However, its expressivity is limited and covering more features requires significant work on the tools.

Metadata Resource Uniqueness*

See note

• Elements in the domain model must provide explicit future-proof identifiers.
• Supports versioning. 

⚠️Partly

Just the Fully-Qualified Name (fqn) and the UUID that can be constructed from the metadata are unique. Specification of a concept can appear multiple times.

This sounds like a concept identifier:

A concept identifier in data modeling is a unique and stable reference (often called an identifier or key) that represents a specific concept or entity within a data model. It's used to clearly distinguish one concept from another and to enable reliable referencing and linkage of data across different contexts or systems.

Key characteristics of a concept identifier:

• Uniqueness: Each identifier uniquely references one concept or entity.

• Stability: The identifier remains consistent over time, even if the concept’s attributes change.

• Non-descriptive: Often identifiers are abstract (e.g., numerical or UUID), so they don't carry inherent semantic meaning, which prevents misinterpretation or ambiguity.

• Interoperability: Enables consistent referencing across multiple systems or data sets.

Examples:

• UUID: Universally Unique Identifier, e.g., 550e8400-e29b-41d4-a716-446655440000

• Primary Key: Database-generated auto-incrementing IDs, e.g., CustomerID = 12345

• Standardized Codes: e.g., ISO country codes (US, DE), or standardized identifiers in medical contexts (SNOMED CT IDs).

Practical usage in data modeling:

• Used as a primary key in database tables to uniquely identify records.

• Supports linking data from multiple sources through foreign keys or reference identifiers.

• Facilitates interoperability and integration among different data systems and external sources.

Importance:

Having clearly defined concept identifiers ensures:

• Data integrity and consistency.

• Simplified integration and interoperability between systems.

• Improved traceability and data governance.

In summary, a concept identifier is foundational in robust data modeling because it provides clear, stable, and unambiguous references to concepts within data systems.

• Concepts of interest in a domain model can be classified with arbitrary hierarchies.

❌No

One tree has one dimension only. Paths of the expanded tree create dependencies and moving a concept to another part in the tree is usually painful.

• Elements of the model can be re used and nested arbitrarily.

❌No

VSS tree has one dimension only. One fixed hierarchy!

• Not only the data structure is specified, but also the allowed operations on the data are formalised (e.g., API-oriented).

❌No

VSS focuses on the data structure (e.g., datatypes, units, etc.) But, no possible interactions with the specified data are formally described (e.g., Concept Seat is modeled but not the possible operations on that property).

• Must scale across Automotive and adjacent industries.
• Low development and maintenance costs.
• Based on a well-established set of stable open-source tools.
• Specified domain models should be usable outside COVESA.

❌No

Limited to COVESA community and the vss-tools (mainly exporters). Any change in the modeling language requires rework of the tools.

Support for Automated Reasoning**

• Resulting domain models could implement basic inferences. 

❌No

No mechanism for semantic correctness and consistency. (e.g., what distinguishes a Car from a Motorcycle? etc.)

⚠️Partly

Only via add-ons.

✅ Yes

✅ Yes

⚠️ Partly 

⚠️ Partly

⚠️Partly

❌No

❌No

❌No

❌No

Support for Automated Reasoning**

❌No

❌No

⚠️ Partly

⚠️ Partly

❌No

?

❌No

❌No

❌No

❌No

✅ Yes