14:15:18 RRSAgent has joined #auto 14:15:18 logging to https://www.w3.org/2022/03/14-auto-irc 14:15:19 RRSAgent, make logs Public 14:15:21 Meeting: Automotive Working Group Teleconference 14:15:28 Meeting: VSSo workshop 14:16:00 scribenick: ted 14:16:07 Scribe: Ted 14:16:15 Chair: Daniel, Ted 15:01:15 Present+ Daniel, Ted, Carine, Wonsuk, Peter, Pierre-Antoine 15:01:24 Present+ Ulf 15:01:31 Present+ DanielA 15:03:47 Present+ Ashish 15:04:09 Present+ Felix 15:10:49 Topic: Introductions 15:10:54 Topic: History of VSSo 15:11:10 @@DWslides 15:12:15 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 15:12:25 … core truth is in YAML for VSS 15:12:47 … on top of YAML specification we have JSON, CSV, GraphQL, etc and tooling evolving all the time 15:12:56 … VSS group meets weekly 15:13:26 … 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 15:13:46 … work started in 2016, before I got involved. the structure was somewhat different 15:14:10 … we found it a compeling standard, it was open and extensible. it was a perfect start for an ontology 15:14:35 … the first VSSo version was done by Benjamin Klotz while he was a PhD student and working with BMW 15:14:46 … this was the basis for the Member Submission to W3C 15:16:02 … we thought it would be easier to restructure VSS's hierarchy for VSSo 15:16:45 … 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 15:17:06 … the main use cases are analytics for current vehicle state, dynamic over time and building services 15:17:48 … 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 15:18:24 … on top of that core ontology we created concepts for handling all VSS definitions 15:19:20 … from there you can link as mentioned to other domain ontologies 15:19:41 … we had some issues in our github repository we wanted to discuss with this group 15:19:49 … how we should handle classes versus instances 15:20:56 Present+ Ravi_Chalanti 15:21:26 Ravi: as for linking to other ontologies, what are taking place there? 15:21:50 Daniel: VSSo is based on SOSA/SSN and in addition to those is linking to IoTStream 15:22:04 Felix: there is no limit, you can link to any logically related ontology 15:22:25 … that is the power of the semantic approach 15:22:48 Ravi: I understand that, wanted to know if there were any immediate 15:23:16 DanielA: the intent is to align to the VSS base but you might desire to extend with a customized ontology 15:23:24 … possible to build on top of that 15:24:41 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 15:24:55 … we would like to be flexible on alignment 15:25:35 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 15:26:23 Felix: we can do this in W3C, describe other ontologies 15:27:08 … 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 15:27:23 … so far it scales well and you can build out other domains 15:27:37 Ravi: thanks, sounds like you are using in practice already 15:27:41 Felix: Yep 15:28:21 Ravi: VSS has definition of a given keyword, what you call a cabin door. where does the definition and conventions come from? 15:30:30 Daniel: the naming convention comes from the tree structure that is based on vehicle structure, eg under Cabin or Drivetrain 15:30:53 … VSS is just a structural element 15:31:33 Felix: re speed, there are several concepts unfortunately within the vehicle measured by drivetrain's transmission, wheel, GPS 15:31:52 … there is a difference and good to know which you are using 15:32:22 Daniel: you basically have an observable signal 15:32:30 Ravi: so the names come from W3C? 15:32:42 Daniel: VSS is defined in COVESA 15:33:28 Ravi: when we define our data elements and attributes in VSSo, are we limited to VSS? 15:33:53 … for example I might want a cruise control set speed. there are different definitions presently in SAE, IEEE etc 15:34:39 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 15:34:55 … it is something we can do or have a common source for them 15:35:03 … it is really difficult to choose one... 15:35:22 Ravi: the Core ontology has to be as unambiguous as possible 15:35:27 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 15:35:49 DanielA: I think you meant the VSS ontology not VSS Core 15:36:18 s/the VSS ontology not VSS Core/the VSSo expanded ontology not VSSo Core/ 15:36:37 … if a concept is not available in VSS you can define it 15:37:10 Felix: or if you are not ok with a COVESA VSS definition, you can make a proposal or pull request 15:37:22 … we did so, as some signals we wanted were missing 15:37:55 Daniel: this brings up the question: what is the single concept of truth? 15:38:51 … we have different audiences interested in this data, some prefer JSON, protobuf etc and they tend to find YAML more readable than an ontology 15:39:53 Present+ Nick Russell 15:40:43 Ravi in Zoom chat shared: [[Definition of Coolant Inlet Pressure as per SAE: 15:40:43 15:40:43 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. 15:40:46 15:40:49 ========== 15:40:52 Definition of Coolant Inlet Temperature: 15:40:55 Bulk coolant temperature entering the inlet manifold of the cooler.]] 15:41:08 Ravi: these are the sorts of things that belong in an ontology 15:41:46 … intent is defining the term, additional labels, relations are not part of VSS 15:41:59 Daniel: it is possible to extend VSS to provide those 15:42:16 Ravi: yes but some would be better within VSSo itself 15:42:59 Felix: we have unit, min, max and means to provide more details. you could provide sort of definition to provide this additional information 15:43:22 … including providing SAE definition 15:43:38 Ravi: part of the challenge is having different interpretations of the same feature 15:44:07 … issue we have in Ford, across different departments within a single OEM. how can we address across OEM? 15:44:44 Daniel: we have the same issue internally 15:45:18 … it is possible to have private extensions, some details you might want to restrict and not be part of a public definition 15:46:21 DanielA: one of the actions from this workshop could be providing information on how can people extend, perhaps providing examples? 15:46:52 Ravi: understand existing definitions are coming from VSS and we can contribute more 15:48:32 -> https://github.com/COVESA/vehicle_signal_specification VSS Github repository 15:52:04 Ravi: can you give more details on workflow for submitting issues, should we be using the tools for our derivatives? 15:52:32 Felix: from VSS in vss-tools you can generate the ttl 15:52:45 Daniel: and on W3C side, take that ttl and generate the spec from tooling 15:53:17 Pierre-Antoine: you mentioned many different formats including JSON, wouldn't JSON-LD make more sense? 15:53:55 Daniel: the group went with JSON before the ontology work, it should be possible to generate JSON-LD from the turtle ttl 15:54:05 [Felix shares screen] 15:54:37 -> https://github.com/w3c/vsso/issues/26 Agenda for discussion topics 15:55:21 @FLslides 15:56:27 Felix: the current proposal is to do subclassing. VSSo Core has Vehicle component as a class and subclasses eg Cabin, Engine 15:56:59 … 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 15:57:25 … these subclasses do not introduce new data property, it would still be attribute, actuator or sensor 15:58:03 … the advantage of this approach is you have these definitions you can instantiate differently later on 15:58:36 … our proposal is to keep the higher level, logical class definitions as defined in Core 15:58:56 … advantage is the ontology stays simple, you can reuse belongsTo relationships 15:59:09 … you can handle the VSS evolution easier as well 15:59:55 … you cannot instantiate these signals but can link to other things 16:00:22 … this is our first, larger issue and discussion point and want to hear opinions 16:01:44 Daniel: it is often ok to have as instances but if you have brand or model and want to query it, have a challenge 16:02:01 Felix: if they are already instances then the concrete values need to be as well 16:02:28 … 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 16:03:29 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 16:03:51 Felix: you can do that but then loose OWL compliance 16:05:46 … what is the meaning of these signal definitions is what we should be asking 16:06:29 … if VSS defines these relationships from its branches it is important to include those in VSSo 16:06:42 … more cumbersome with eg SHACL 16:07:12 … we don't have a flat list of signals associated with a vehicle but a logical structure in VSS 16:07:21 Pierre-Antoine: now I understand what you're trying to solve 16:07:45 DanielA: I agree this belongs to relationship and having many subproperties is unneccessarily redundant 16:08:10 … where you have an instance of a vehicle property I see it as useful, you can point to the actual definition without further clarification 16:09:12 Felix: it is possible with SOSA observation, every property can be tied to a vehicle observation 16:09:32 … if that is seen as too heavy, you could go with property value + timestamp 16:12:18 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 16:14:32 Pierre-Antoine: would you have the hierarchy of confidence per property or only at the abstract level? 16:16:09 Felix: we do both. there are logically signals that might not belong in a particular make/model of vehicle 16:16:54 … in a future version we might come up with a common standard of how to treat property values 16:16:54 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 16:17:37 Ravi: I like the instances approach better. advantage of subclasses is visualizing things 16:19:23 Felix: you can go from the component to the property even if it is defined in the other direction 16:20:07 Ravi: you could categorize components eg ADAS, seat 16:20:28 … they may have different parameters than an engine. how can you justify them being the same class? 16:21:03 … I would like to see engine still be a subclass. there may be common data from engine elements 16:21:15 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 16:22:07 … I like approach of instances but do not want to loose the hierarchical structure 16:22:20 Felix: they we need to do something different than basing on VSS 16:22:57 … if additional properties are added to a class and subclass a vehicleComponent for an engine 16:23:30 … then the subclasses are different from a super class. properties are vastly different than a seat 16:23:30 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 16:23:43 Daniel: that comes back to what is defined in VSS 16:24:05 … it isn't more defined in VSS 16:24:59 … for signals and observations subclasses make sense for the value they carry 16:26:21 … if every signal is treated differently it would be difficult to use 16:26:33 Felix: I agree it is worth differentiating the types of signals 16:29:34 Ravi: is it necessary that what we capture in VSSo, have an advocate in VSS 16:29:46 … does it need to exist in both? 16:30:10 Felix: it needs to come from somewhere. it could come from elsewhere after you generate VSSo, extension can contain more 16:30:21 DanielA: it would depend on what you want to add 16:31:23 … if you are including additional information about an already defined signal, it should be included. more abstract better handled in an extension 16:31:24 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 16:32:46 Proposal: DynamicVehicleProperty to realize as instance 16:32:51 * StaticVehicleProperty as subclasses to instantiate for concrete values 16:33:09 * VehicleComponent to realize as instances 16:33:36 * Vspec2ttl (VSS Tools): define rules/exceptions for how to generate VSS signals in VSSo 16:34:20 Felix: there are some areas not covered by tools yet 16:34:48 DanielA: I would add unit for example and making a distinction if it is a quantity or category 16:35:12 … it could be handled as extension to VSSo 16:37:22 Felix: what is the vehicle? is this something part of VSSo Core? are we referencing the vehicle itself or vehicle component root? 16:38:36 Daniel: it is the vehicle imho 16:39:12 DanielA: where do the units come from? 16:39:28 Felix: any appropriate unit ontology 16:40:07 Sub-classes vs. Instantiation of existing VSS concepts -> https://github.com/w3c/vsso/issues/22 16:40:36 Daniel: we have unit categories in a configuration file for our tooling, it is a recent addition 16:40:54 Felix: which one did you use? 16:40:59 … QUTT? 16:41:11 Daniel: didn't settle on an ontology yet 16:42:08 DanielA: VSS has defined specific units as part of its signal definitions whereas VSSo can support compatible types 16:42:24 … I would vote for quantity kind 16:42:39 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 16:43:15 … a recommendation for quantity kind would make sense 16:44:40 Felix: so even if coolant temp is in Celsius, someone can use quantity kind to represent in Fahrenheit or Kelvin? 16:44:43 DanielA: yes 16:45:12 Pierre-Antoine: you want to avoid complexity for the data consumers 16:45:40 … encourage choosing specific unit ontologies to avoid interpretation problems 16:46:37 Pierre-Antoine provides link in chat https://ci.mines-stetienne.fr/lindt/v2/custom_datatypes.html#ucum 16:47:46 Felix: hard to choose one unit ontology 16:49:21 … data provider should use Celsius and consumers depend on that but maybe present to an En-US speaker as Fahrenheit 16:59:11 [discussion of whether core truth would be better in ontology than YAML] 16:59:39 Daniel: it would make sense but mess up how the group works. I think we have a compromise we can live with 16:59:56 … we can address with tooling 17:00:09 … concerned there would be pushback 17:00:45 … VSS has a good momentum. circular would be problematic, require more tooling and we have limited engineering resources 17:01:40 Pierre-Antoine: if the community around VSS is happy with YAML... if it ain't broke, don't fix it 17:02:18 … if commitment is less than converting community and tooling 17:02:39 … JSON schema can be used with additional constraints to create ontologies 17:03:22 Daniel: I agree. having tooling to go full circle is what I want to avoid, easier to go one direction 17:04:34 … we are focused on one single domain, if we were trying to define a person to represent driver and passengers that is another story 17:11:57 [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] 17:12:38 Felix: more complicated as VSSo come from VSS which is not under the same rules 17:21:16 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 17:21:48 [discussion on IP and licensing by a bunch of engineers] 17:21:56 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 17:24:27 Present+ Frederic_Landqvist 17:29:35 Pierre-Antoine: anyone consider using the punning (sp?) capabilities of OWL as it would allow instances and subclasses to an extent 17:30:14 … it would preserve the hierarchy of VSS but make things a cleaner design 17:30:49 Daniel: as Ted mentioned, we talked with someone (Alan F, Autonomic) about that last week 17:31:30 … I have never used it and would be grateful for opinions on how to use it 17:31:46 Felix: first time I came across it. is it implemented in toolsets? 17:32:18 Pierre-Antoine: the usual OWL implementations support it 17:32:50 … from an RDF perspective it is more natural 17:33:26 … 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 17:34:27 s/(sp?)// 17:34:52 … in most cases it is invisible to the user 17:36:33 Daniel gives background on previous design decisions 17:38:00 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 17:38:27 … it makes things appear more complex and harder to understand but you get benefit of class and instance views 17:38:32 Daniel: definitely 17:38:54 … excited to learn more about it and agree since we're generating, may be easier to adopt 17:39:13 Felix: did you get feedback from Paul on COVESA AMM? 17:39:36 Daniel: yes, we just have to find the timeslot but we can have a presentation there 17:39:38 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 17:43:52 s/QUTT/QUDT/ 17:44:05 Topic: VSSo extension for handling data streams 17:44:27 DanielA: there are cases you need to express something else than what is in VSSo 17:44:57 … defined scope, concepts that can be reused, terminology, the classes... 17:45:15 … scope is to handle data in motion or more generically as data streams 17:45:24 … there are some questions not handled by the model 17:45:47 … how many journies a vehicle has taken in the last month... 17:46:54 … 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 17:48:03 … when we use SOSA we have background information and the dynamic data as well 17:48:38 … you can observe or act on the given data. from an IoTStream perspective you can express events that occur based on the signals 17:49:28 … and make aggregate observations on the stream itself, net change for example of a given signal for a journey (or other period constraint) 17:49:56 … the idea is a vehicle can have multiple journeys and each a stream of data 17:50:16 … described as an IoTStream 17:50:28 … it must use QUDT units 17:51:54 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? 17:52:06 DanielA: depends on how and when you want to make annotations 17:52:54 … there are two options, you can have individual or a stream processing to aggregate based on queries 17:53:52 … 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 17:54:04 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 17:55:03 @DAslides 17:55:09 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 17:55:40 … I'm working on some models with these techniques 17:56:20 … benefit is you can start mixing in additional data sources/domains such as speed limit 17:57:26 … advantage is this aggregation on active streams minimizes data storage needs 17:59:34 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 18:00:29 … one of your use cases for stream analysis 18:02:46 DanielA: should these extensions be in the same repo or elsewhere? 18:06:18 Ted: probably adjacent 18:06:19 I have made the request to generate https://www.w3.org/2022/03/14-auto-minutes.html ted 19:28:47 Zakim has left #auto