Meeting minutes
Introductions
History of VSSo
Daniel: VSS is a tree like structure, related to the structure of the vehicle itself. the leaves are the data itself. it could be sensor, actuator or attribute
… core truth is in YAML for VSS
… on top of YAML specification we have JSON, CSV, GraphQL, etc and tooling evolving all the time
… VSS group meets weekly
… as long as you stay in the domain of vehicles, those formats are fine but to relate to other domains it is beneficial to use ontologies
… work started in 2016, before I got involved. the structure was somewhat different
… we found it a compeling standard, it was open and extensible. it was a perfect start for an ontology
… the first VSSo version was done by Benjamin Klotz while he was a PhD student and working with BMW
… this was the basis for the Member Submission to W3C
… we thought it would be easier to restructure VSS's hierarchy for VSSo
… VSSo was added to the W3C Automotive Working Group charter, next version was done in the Business Group and now published as a final BG report and First Public Working Draft for the WG
… the main use cases are analytics for current vehicle state, dynamic over time and building services
… we want VSSo to be very close to VSS and wanted a tight coupling. we started with a VSSo Core ontology, one of the two specs published
… on top of that core ontology we created concepts for handling all VSS definitions
… from there you can link as mentioned to other domain ontologies
… we had some issues in our github repository we wanted to discuss with this group
… how we should handle classes versus instances
Ravi: as for linking to other ontologies, what are taking place there?
Daniel: VSSo is based on SOSA/SSN and in addition to those is linking to IoTStream
Felix: there is no limit, you can link to any logically related ontology
… that is the power of the semantic approach
Ravi: I understand that, wanted to know if there were any immediate
DanielA: the intent is to align to the VSS base but you might desire to extend with a customized ontology
… possible to build on top of that
Ravi: there might be more to signals than what is currently defined in VSS either because of different vehicle capabilities (eg lidar) or paired devices
… we would like to be flexible on alignment
Daniel: agree, another under represented area is the underlying components producing the signals. they're not being defined currently in VSS, could be part of an extension
Felix: we can do this in W3C, describe other ontologies
… at Bosch we use this internally and align with our ontologies. you can start small in individual areas but you will see some can be linked well
… so far it scales well and you can build out other domains
Ravi: thanks, sounds like you are using in practice already
Felix: Yep
Ravi: VSS has definition of a given keyword, what you call a cabin door. where does the definition and conventions come from?
Daniel: the naming convention comes from the tree structure that is based on vehicle structure, eg under Cabin or Drivetrain
… VSS is just a structural element
Felix: re speed, there are several concepts unfortunately within the vehicle measured by drivetrain's transmission, wheel, GPS
… there is a difference and good to know which you are using
Daniel: you basically have an observable signal
Ravi: so the names come from W3C?
Daniel: VSS is defined in COVESA
Ravi: when we define our data elements and attributes in VSSo, are we limited to VSS?
… for example I might want a cruise control set speed. there are different definitions presently in SAE, IEEE etc
Felix: you can have multiple definitions linked to the same element, coming from COVESA VSS or choose to use SAE definition for the same element
… it is something we can do or have a common source for them
… it is really difficult to choose one...
Ravi: the Core ontology has to be as unambiguous as possible
DanielA: I think you meant the VSSo expanded ontology not VSSo Core
… if a concept is not available in VSS you can define it
Felix: or if you are not ok with a COVESA VSS definition, you can make a proposal or pull request
… we did so, as some signals we wanted were missing
Daniel: this brings up the question: what is the single concept of truth?
… we have different audiences interested in this data, some prefer JSON, protobuf etc and they tend to find YAML more readable than an ontology
Ravi in Zoom chat shared: [[Definition of Coolant Inlet Pressure as per SAE:
Bulk coolant pressure entering the inlet manifold of the cooler. Boiling point is a function of absolute pressure, so given that this pressure drops as the coolant passes downstream due to viscous losses, entering pressure is a critical design parameter. Areas of even lower absolute pressure can occur in coolant eddy currents passing sharp corners inside the tube matrix.
==========
Definition of Coolant Inlet Temperature:
Bulk coolant temperature entering the inlet manifold of the cooler.]]
Ravi: these are the sorts of things that belong in an ontology
… intent is defining the term, additional labels, relations are not part of VSS
Daniel: it is possible to extend VSS to provide those
Ravi: yes but some would be better within VSSo itself
Felix: we have unit, min, max and means to provide more details. you could provide sort of definition to provide this additional information
… including providing SAE definition
Ravi: part of the challenge is having different interpretations of the same feature
… issue we have in Ford, across different departments within a single OEM. how can we address across OEM?
Daniel: we have the same issue internally
… it is possible to have private extensions, some details you might want to restrict and not be part of a public definition
DanielA: one of the actions from this workshop could be providing information on how can people extend, perhaps providing examples?
Ravi: understand existing definitions are coming from VSS and we can contribute more
Ravi: can you give more details on workflow for submitting issues, should we be using the tools for our derivatives?
Felix: from VSS in vss-tools you can generate the ttl
Daniel: and on W3C side, take that ttl and generate the spec from tooling
Pierre-Antoine: you mentioned many different formats including JSON, wouldn't JSON-LD make more sense?
Daniel: the group went with JSON before the ontology work, it should be possible to generate JSON-LD from the turtle ttl
[Felix shares screen]
Felix: the current proposal is to do subclassing. VSSo Core has Vehicle component as a class and subclasses eg Cabin, Engine
… in order to relate your signal to the Vehicle component you also have to subclass the property it belongs to. it works but it leads to many properties
… these subclasses do not introduce new data property, it would still be attribute, actuator or sensor
… the advantage of this approach is you have these definitions you can instantiate differently later on
… our proposal is to keep the higher level, logical class definitions as defined in Core
… advantage is the ontology stays simple, you can reuse belongsTo relationships
… you can handle the VSS evolution easier as well
… you cannot instantiate these signals but can link to other things
… this is our first, larger issue and discussion point and want to hear opinions
Daniel: it is often ok to have as instances but if you have brand or model and want to query it, have a challenge
Felix: if they are already instances then the concrete values need to be as well
… it makes things a little more complicated but doable for static properties. question is what do you want in the end, use cases being supported
Pierre-Antoine: why do you say you must have a subproperty? it is a convenience but don't see it as a MUST. you can use belongsTo in that situation
Felix: you can do that but then loose OWL compliance
… what is the meaning of these signal definitions is what we should be asking
… if VSS defines these relationships from its branches it is important to include those in VSSo
… more cumbersome with eg SHACL
… we don't have a flat list of signals associated with a vehicle but a logical structure in VSS
Pierre-Antoine: now I understand what you're trying to solve
DanielA: I agree this belongs to relationship and having many subproperties is unneccessarily redundant
… where you have an instance of a vehicle property I see it as useful, you can point to the actual definition without further clarification
Felix: it is possible with SOSA observation, every property can be tied to a vehicle observation
… if that is seen as too heavy, you could go with property value + timestamp
Pierre-Antoine: would you have the hierarchy of confidence per property or only at the abstract level?
Felix: we do both. there are logically signals that might not belong in a particular make/model of vehicle
… in a future version we might come up with a common standard of how to treat property values
Ravi: I like the instances approach better. advantage of subclasses is visualizing things
Felix: you can go from the component to the property even if it is defined in the other direction
Ravi: you could categorize components eg ADAS, seat
… they may have different parameters than an engine. how can you justify them being the same class?
… I would like to see engine still be a subclass. there may be common data from engine elements
… I like approach of instances but do not want to loose the hierarchical structure
Felix: they we need to do something different than basing on VSS
… if additional properties are added to a class and subclass a vehicleComponent for an engine
… then the subclasses are different from a super class. properties are vastly different than a seat
Daniel: that comes back to what is defined in VSS
… it isn't more defined in VSS
… for signals and observations subclasses make sense for the value they carry
… if every signal is treated differently it would be difficult to use
Felix: I agree it is worth differentiating the types of signals
Ravi: is it necessary that what we capture in VSSo, have an advocate in VSS
… does it need to exist in both?
Felix: it needs to come from somewhere. it could come from elsewhere after you generate VSSo, extension can contain more
DanielA: it would depend on what you want to add
… if you are including additional information about an already defined signal, it should be included. more abstract better handled in an extension
Proposal: DynamicVehicleProperty to realize as instance
* StaticVehicleProperty as subclasses to instantiate for concrete values
* VehicleComponent to realize as instances
* Vspec2ttl (VSS Tools): define rules/exceptions for how to generate VSS signals in VSSo
Felix: there are some areas not covered by tools yet
DanielA: I would add unit for example and making a distinction if it is a quantity or category
… it could be handled as extension to VSSo
Felix: what is the vehicle? is this something part of VSSo Core? are we referencing the vehicle itself or vehicle component root?
Daniel: it is the vehicle imho
DanielA: where do the units come from?
Felix: any appropriate unit ontology
Sub-classes vs. Instantiation of existing VSS concepts
Daniel: we have unit categories in a configuration file for our tooling, it is a recent addition
Felix: which one did you use?
… QUDT?
Daniel: didn't settle on an ontology yet
DanielA: VSS has defined specific units as part of its signal definitions whereas VSSo can support compatible types
… I would vote for quantity kind
… a recommendation for quantity kind would make sense
Felix: so even if coolant temp is in Celsius, someone can use quantity kind to represent in Fahrenheit or Kelvin?
DanielA: yes
Pierre-Antoine: you want to avoid complexity for the data consumers
… encourage choosing specific unit ontologies to avoid interpretation problems
Pierre-Antoine provides link in chat https://
Felix: hard to choose one unit ontology
… data provider should use Celsius and consumers depend on that but maybe present to an En-US speaker as Fahrenheit
[discussion of whether core truth would be better in ontology than YAML]
Daniel: it would make sense but mess up how the group works. I think we have a compromise we can live with
… we can address with tooling
… concerned there would be pushback
… VSS has a good momentum. circular would be problematic, require more tooling and we have limited engineering resources
Pierre-Antoine: if the community around VSS is happy with YAML... if it ain't broke, don't fix it
… if commitment is less than converting community and tooling
… JSON schema can be used with additional constraints to create ontologies
Daniel: I agree. having tooling to go full circle is what I want to avoid, easier to go one direction
… we are focused on one single domain, if we were trying to define a person to represent driver and passengers that is another story
[Daniel asks about logistics, Ted wants to get show of hands of interested parties, figure out a call cadence. Carine clarifies contributions can come from non-Members with IP commitment]
Felix: more complicated as VSSo come from VSS which is not under the same rules
[discussion on IP and licensing by a bunch of engineers]
Pierre-Antoine: anyone consider using the punning capabilities of OWL as it would allow instances and subclasses to an extent
… it would preserve the hierarchy of VSS but make things a cleaner design
Daniel: as Ted mentioned, we talked with someone (Alan F, Autonomic) about that last week
… I have never used it and would be grateful for opinions on how to use it
Felix: first time I came across it. is it implemented in toolsets?
Pierre-Antoine: the usual OWL implementations support it
… from an RDF perspective it is more natural
… some may see it as a hackish way of doing things but can be used well, elegantly to address the dilemna between the two approaches
… in most cases it is invisible to the user
Daniel gives background on previous design decisions
Pierre-Antoine: to be honest, for this to work there would be some redundancy so it is good that you are deriving VSSo from VSS and can handle in tooling
… it makes things appear more complex and harder to understand but you get benefit of class and instance views
Daniel: definitely
… excited to learn more about it and agree since we're generating, may be easier to adopt
Felix: did you get feedback from Paul on COVESA AMM?
Daniel: yes, we just have to find the timeslot but we can have a presentation there
VSSo extension for handling data streams
DanielA: there are cases you need to express something else than what is in VSSo
… defined scope, concepts that can be reused, terminology, the classes...
… scope is to handle data in motion or more generically as data streams
… there are some questions not handled by the model
… how many journies a vehicle has taken in the last month...
… what I'm reusing is the VSSo Core ontology, SSN/SOSA. this is useful for low level observations. I found IoTStream ontology interesting for this use case
… when we use SOSA we have background information and the dynamic data as well
… you can observe or act on the given data. from an IoTStream perspective you can express events that occur based on the signals
… and make aggregate observations on the stream itself, net change for example of a given signal for a journey (or other period constraint)
… the idea is a vehicle can have multiple journeys and each a stream of data
… described as an IoTStream
… it must use QUDT units
Felix: do you cover this with stream processing, run time series through it and have rules defined to analyze the stream to come up with an aggregate observation?
DanielA: depends on how and when you want to make annotations
… there are two options, you can have individual or a stream processing to aggregate based on queries
… the results can be labeled with this ontology. another option if you annotate the data itself, used when the data isn't in RDF. express sequencing of the data observations
[Daniel Alvarez-Coello's slides]
… I'm working on some models with these techniques
… benefit is you can start mixing in additional data sources/domains such as speed limit
… advantage is this aggregation on active streams minimizes data storage needs
Ted: on our embedded devices we utilize curve logging for reason you mentioned, minimizing data points needed to off-board but get a reasonable representation
… one of your use cases for stream analysis
DanielA: should these extensions be in the same repo or elsewhere?
Ted: probably adjacent