01:48:33 Karen has joined #auto 16:00:19 RRSAgent has joined #auto 16:00:19 logging to https://www.w3.org/2019/09/10-auto-irc 16:00:21 RRSAgent, make logs public 16:00:21 Zakim has joined #auto 16:00:23 Meeting: Automotive Working Group Teleconference 16:00:23 Date: 10 September 2019 16:03:08 magnus has joined #auto 16:29:28 Topic: Meetup reaction 16:29:37 -> https://www.meetup.com/Silicon-Valley-Automotive-Open-Source/events/264114649/ Meetup registrants 16:29:37 several showed up without registering eg us, Volvo and a few others 16:29:37 -> https://www.w3.org/2019/Talks/tg-meetup/ Ted's meetup slides 16:29:37 Adnan and Peter's to be sent to public-automotive 16:30:51 @@Autonomic, Ford, Honda, LG - make intros by email so I can follow up and/or you are welcome to 16:31:38 from Q&A data integrity metadata, realtime/latency considerations for eg v2x use cases (from Lynn @ Ford) 16:32:13 Harjot has joined #Auto 16:32:16 t2 has joined #auto 16:40:52 discussion/recap of web payments task force which was of interest to an OEM in the room 16:44:09 discussion of VSS gaps and EV signals - agreed in Munich after vss2.0 release. BMW, Siemens, others 16:45:36 @@CharinEV 16:46:04 Glenn: NIST is holding a meeting on cybersecurity Thursday 12 Sept for EVSE 16:49:39 magnus has joined #auto 17:02:22 Magnus: if we are taking up v2x use case, do we care about the bandwidth of the data channel? 802.11p is limited 17:03:31 Ted: uuid gh issue for vss will help, terser than full descriptive label 17:04:14 Adnan: do we have to take that into account, it is a limitation of the network layer 17:04:32 Magnus: yes but you cannot ignore it either given time sensitivity 17:04:57 Ulf: you should accomodate condensed transmission like using uuids, which helps this use case 17:05:20 … not sure we need to do more in spec itself 17:07:32 Glenn: have we reached out to OmniAir? they are responsible for v2v safety message 17:07:43 Ted: no, just ITS 17:08:23 Glenn: we should reach out to them, they're pretty advanced at this point 17:08:37 Ted: too late then probably for v2v but possibly still for v2i 17:10:21 … still relevant for translating instead of having to do custom v2v app per oem 17:10:34 Peterw has joined #auto 17:10:36 Magnus: wanted to be sure scope isn't changing 17:19:09 Topic: ViWi/VSS options 17:19:26 [prep for larger group discussion, wiki from end of yesterday] 17:19:50 s/wiki from/wiki generated from whiteboard/ 17:20:15 https://www.w3.org/auto/wg/wiki/Viws 17:25:58 [tangent on Graph, who (redacted) is prototyping what based on VSSo and interest in having a demo, how that would be useful] 17:30:07 Agreement on wanting to create GraphQL PoC/demo with VSSo 17:30:31 Adnan shares a Youtube video (one less redaction), will provide link for minutes 17:30:38 link? 17:32:11 (err video is 'unlisted' so still somewhat redacted... sending in personal mail, not to list) 17:32:28 (awaiting ok from conf organizers or similar) 17:37:14 Ted: I had on agenda what this group can work on while this circular viwi/viss/gen2 debate does another lap 17:41:14 Ado has joined #Auto 17:41:27 https://blog.mirumee.com/highlights-from-the-graphql-summit-2018-in-san-francisco-49d7ab20f5cd 17:55:49 Ted: I will fill in the wiki more and encourage others to as well. not expecting us to resolve this at f2f unfortunately 17:56:21 Present+ Joakim, Adnan, Harjot, Glenn, Ulf, Ted, Peter, Magnus, PatrickL 17:57:30 [discussion of uuid and tree position, need consistency if location changes] 18:05:46 Peterw has joined #auto 18:10:28 Adnan presents diagrams of analysis he and Daniel did on ViWi data 18:10:50 Adnan: please correct our understanding. on third level you can have elements under a number of resources 18:11:12 … we focused on use case/example data structure for media 18:11:32 … we put some nodes together. we see this as more application centric than data centric 18:11:46 … we really liked the registry approach 18:12:10 … each service might come with its own overlapping data model 18:12:13 [p3] 18:12:24 PatrickL: could you go back to #2? 18:12:39 … property would be the connecting link to that element 18:12:57 … album has the artist pointing to the element artist 18:13:15 Adnan: you would still have relationship end to end since you can have multiple, adding complexity 18:13:26 … it is still valid, not being critical 18:14:11 PatrickL: links go from property artist to element 18:14:18 [p3] 18:14:44 Adnan: if we try to map VSS data model to ViWi you can see replication of several resources within element 18:15:13 … resource should not have elements such as isOpen, isLocked. not sure what sort of flexibility we might have there 18:15:45 … each service could populate its own data model based on registry 18:16:17 … what are your thoughts on how to find common solution 18:16:36 PatrickL: there would be taxonomies for everything in vehicle and trees or subclasses for different use cases 18:16:43 … to find those I would use something like registry 18:17:03 … I have one taxonomy about everything in the vehicle 18:17:19 Adnan: there could be multiple domains 18:17:45 … you would have a data taxonomy for each and service registry would discover tree and expose 18:18:13 PatrickL: would there be one implementation representing the whole vehicle signals or could it be split into several 18:18:25 Ulf: one should strive for having one single entry 18:18:43 PatrickL: that would not work with what we have, we cannot fit everything 18:19:13 Adnan: do you have an example? 18:19:35 PatrickL: we can have 4-5 implementations regarding seat and distributed, listed separately in registry 18:19:54 Adnan: that is fine and could work, it is up to service registry on how to handle this 18:20:09 … we want to map data to something understandable [to developer] 18:20:18 … from service registry it would be mapped within the tree 18:20:40 … you do not need to know what service is doing but want to use tree to find the data 18:20:54 PatrickL: ok, was confused by the one implementation 18:21:05 Adnan: how to approach and resolve... 18:21:13 PatrickL: service/resource/element 18:21:48 … every category of element that is the same type, eg seat, is a resource and every bundle has elements 18:22:05 … service/resource/element is about type and not tree representation 18:22:25 Adnan: yeah but you would break the taxonomy, exposing the tree 18:22:52 … can we find a common solution where we use existing parts from ViWi and modify things based on tree taxonomy of eg VSS 18:23:13 PatrickL: this matches quite well with my pull request from earlier in the year 18:23:47 … it allows for a graph and not only a tree. it does not follow service/resource/element way but chains 18:24:01 Adnan: that would be ok with you in VW? 18:24:06 PatrickL: yeah 18:24:27 Ulf: so you're saying we can keep arbitrary depths? if so can you please provide some examples 18:24:45 Adnan: maybe case of accessing pressure for tire, what is the path? 18:24:53 PatrickL: currently not possible 18:25:01 Adnan: but for the new ViWi 18:25:20 PatrickL: I would create it for the element and property, worth doing to be understandable for developer 18:25:43 … I would make 'blue bubbles' (cf diag) so you don't always have to go through the registry 18:26:02 … the seat has a list and points to these four implementations, it would be a type of node 18:26:26 Adnan: did you think as well about reverse compatibility for ViWi 18:26:39 PatrickL: not interested in that but a good new protocol... 18:26:55 … ok with breaking compatibility. what we have works fine for a developer 18:27:24 joakim has joined #auto 18:27:50 Ted: so you're back to Gen2 and not 'the other Patrick' interest in ViWi 18:28:21 Ulf: what you say can then handle VSS as is and that scenario? 18:28:30 PatrickL: of course as people are using it 18:29:01 … I do think VSS could use some changes and no special types 18:36:48 https://www.w3.org/auto/wg/wiki/Viws 18:40:32 Resolved: Gen2 revitalization 18:40:34 I have made the request to generate https://www.w3.org/2019/09/10-auto-minutes.html ted 19:56:34 Zakim has left #auto 20:47:10 Topic: Graph prototype 20:48:25 Glenn: objective is to expose the common data model to a broader audience of developers 20:50:00 … we can present oem and data provider using this and then various participants can demo to various audiences at conferences 20:50:16 … refine scope over the next few weeks 21:20:06 [light minuting] 21:20:17 Topic: Tire client app 21:20:21 @@see notes 21:24:29 Topic: Auto landing page 21:24:40 https://www.w3.org/comm/assets/staging/auto/ 21:24:47 https://www.w3.org/auto/ old 21:25:45 Harjot: I suggest s/Big Data/data analytics/ 21:31:02 Ted: I guess s/in-vehicle and cross-vehicle applications/in-vehicle, cross-vehicle and cloud based applications/ 21:32:44 Glenn: s/might incorporate other transportation modes or address general public safety issues./might incorporate other transportation modes, address general public safety issues and SmartCity (v2i) interactions./ 21:34:26 Ted: s/blizzard/confusing array/ 21:37:42 … s versions proprietary interfaces 21:38:09 … s Web applications applications 21:38:36 … s next version next generation 21:39:19 … with accompanying reference / demo implementations 21:40:41 … is primarily focused on/is 21:41:47 _W3C_ Web of Things 21:42:29 associated - stemming from. example based on / leveraging 21:43:01 drop the other domains for now on landing page 21:43:34 descr on wg & bg from onboard email 21:44:20 comment out

starting with Applications, of course, 21:48:10 comment out related auto until we get other sdo liaisons 21:54:22 Harjot: I am happy to take a pass at it as well if you throw into a google doc 21:54:26 Ted: will do 21:56:19 Topic: Workshop prep 21:56:20 https://www.w3.org/2019/07/trans-data-ws/agenda 22:21:54 (raw notes, see real agenda page https://www.w3.org/Data/events/data-ws-2019/schedule which will be edited heavily tomorrow w slides, presenters and talk titles) 22:22:13 Topic: review of draft Graph project 22:22:46 https://docs.google.com/document/d/1ACoHvQZQTgJF41gIvM48RfoG695O58AUjdvGATGBB6k/edit?usp=sharing_eil&ts=5d781dc9 22:34:50 I have made the request to generate https://www.w3.org/2019/09/10-auto-minutes.html ted