Automotive Working Group Teleconference

<scribe> scribenick: ted

Gen2 Data Model

Patrick's email

Magnus: I need a bit more clarification why we need this
... my impression is this would make it generic and result would be deviation

PatrickL: I hear the concern. the different use cases we set out to solve are for quite different styles of interfaces
... my concerns of deviation are actually lessened if we can keep the core as simple and basic as possible, to support different transport protocols

Ulf's reply

PatrickL: Ulf is concerned about unlimited types

Patrick quotes Ulf [[As the discussion focusses on the "type" issues, I would say that this opens up for unlimited number of "types", now called names.]] https://lists.w3.org/Archives/Member/member-automotive/2019Mar/0003.html

Daniel: we have already shown a variety are protocols can be supported and don't see it as a show stopper

PatrickL: problem is an additional rule to understand the key/value pairs

Magnus: wouldn't this open up unlimited number of signals that can be added as unlimited types will be allowed
... if everyone defines their own it will loose interoperability

PatrickL: we don't want that
... VSS describes what the tree should look like for vehicle signals and we can come up with another tree for media using the same core specs

Daniel: navigation and media are part of VSS. for VSS2 we are trying to improve the structure based on internal experience
... I intend to propose fuller changes at the F2F in Munich
... we may be proposing some additions as will others, we want them to fit

PatrickL: that would work

Daniel: I am coming from GraphQL side, Benjamin may answer from semweb side
... if you want to graph a driver to a vehicle you wouldn't have VSS for the driver but can still have inter connectivity

@@WoT

Benjamin: I am in agreement with Magnus, need for a strong data model otherwise we will miss a big part of the point of having such an API
... we don't have to follow something as drastic as the WoT WG but learn from their good practices based on other industry silos
... we are missing semantics, inter-meaning

PatrickL: true, this is not what my proposal is about

Magnus: I would say no

PatrickL: it brings the description of the ontology within the protocol itself
... looking at the charter you will see we have three steps, finish VISS, build core protocol spec, defining and agreeing on specific interfaces for services within the vehicle
... that is something I don't even work on right now and not sure how to make that clearer

Magnus: what you are saying is you tried to create a way for a client that has no way of understanding VSS structure to be able to request a resource

PatrickL: that is a part of it, to be able to explore what could be available
... we will not just have VSS in the future. we are seeking a common way to communicate across transfer mechanisms

Magnus: it is kind of like what getmetadata was doing in VISS

PatrickL: maybe, unsure
... the Gen2 data model is not trying to replace VSS but to support a specific data model for context - could be VSS

Daniel: there seems to be some confusion still. a couple weeks ago you said there were too many data types, we are switching topics
... I want to understand the main problem that is the issue, we are in a circular discussion
... let's start with the problem

Laurent: another example that might match what Patrick explained
... I was part of CCC and when we talked about vehicle data we talked about transport, moving data from a to b
... we talked about serialization without defining the structure yet
... we want to have a common transport and at the time we didn't know what data we wanted to exchange and even looked at VSS
... we were thinking XML and schema agnostic so you could parse and if there is a version mismatch discard what you can't understand
... we looked at how we want to exchange media as well
... we want a transport that can transport structured data, serializer that could be used for any protocol and then on top of that specifications for common services
... they could be small grained services
... there was space for something common so third party developers can create something for the car along with the OEM adding services themselves
... we need a public API but also need to advance at a faster pace, using private internal APIs
... I need basis of protocol to be a bit wider
... when Patrick talked to me about the Gen2 data model topic, it reminded me of these past conversations
... I want something that can transport outside of VSS for now

PatrickL: we are speaking about so many different topics because the proposal impacts all things that makes the generic protocol
... I am always getting a different question to a specific part of it, we haven't identified this as a generic protocol

<LaurentC> https://www.etsi.org/deliver/etsi_ts/103500_103599/10354405/01.03.00_60/ts_10354405v010300p.pdf

<LaurentC> https://www.etsi.org/deliver/etsi_ts/103500_103599/10354406/01.03.00_60/ts_10354406v010300p.pdf

<LaurentC> https://www.etsi.org/deliver/etsi_ts/103500_103599/10354408/01.03.00_60/ts_10354408v010300p.pdf

Daniel: it is hard then to agree on one data model. allowing for private extensions helps provided people follow the structure
... if you shrink the scope of VSS and to the possibility of extensions that would be simpler but not as useful
... to me the common data model is the strength
... taking one step backwards and look at the requirements

PatrickL: yes, there is a compiled list created last year derived from all the protocol discussions
... Ulf provided a starting point based on VISS

Magnus: please correct my understanding but I heard you both wanted to support VSS
... could you clarify then that you may support different data models in the future but for now look to improve VSS for what we need
... seems we are going in circles

PatrickL: we want to support VSS and the description for vehicle signals
... for me it should be confined to vehicle signals, hearing just now it might encompass Nav as well
... we want to be able to communicate in different protocols. we want to use the same ontology and style for using it

Daniel: we have that through VSS, VSSo and WoT

PatrickL: I don't understand

Daniel: if you have a domain specific description you can define protocol, security model etc. we can apply it to the automotive domain
... what you described before can be handled in VSSo
... if you see some specific doesn't fit within vehicle domain then think of what else you can pull in
... apologies, have to leave

Ted: Navigation is a beast and to come up with an API to support routing would be an undertaking. limited signals such as direction, location and destination would be very helpful. I would prefer to see separate data models, using same structure, for these different domains and for them to share the core access method spec

PatrickL: I have trouble the generic VSS data model and ontology parts, that could be something someone can help me with
... it would be difficult to handle different ontologies with one model. WoT is in the same area with a generic data model and methods that can be executed, used to view, edit a certain data model in a RESTful manner
... I am unsure how to proceed. yes everything is feasible, adding new data types as we go but that is not something I can allow for
... I need a basic, stable version where only the clients are allowed to change on a rapid level

Ted: when VSS work was starting up there was concern about compatibility with VISS. we decided to snapshot and create a 1.0 branch and agreed to endeavor to backport new signals there using previous methodology. we can do the same here, if more dramatic changes to VSS are proposed we can have a frozen branch for Gen2

PatrickL: yes and would like to see VSS focusing on ontology and in W3C side we are using a generic data model that allows for things like VSS
... with this split we would bundle the knowledge in the right areas

Laurent: we have a dependency on VSS and potentially mapped into a C or Java library
... we want to progress without iterate and merge when ready. we have nothing to transport until VSS2 is complete
... here we want to do same as VSS/VISS model with a better (gen2) VISS

Magnus: VSS was the data model to use in VISS but there was no hard link between the two. it was possible to use alternate data models underneath
... get, set, subscribe basically maps to the data model you have
... my other comment was about a generic data model that would be a superset of whatever you have underneath
... I feel we are back to where we began then where there could be infinite data models, eg per OEM and dilute any value of this standards work
... even if the way to access is standardized. interpretting the kind of data within it might be difficult

Laurent: I agree there is a danger on multiple data models, you talked about translation and I want to be able to devise bridges and caches without knowing VSS2 to work
... that is why a generic data model is a good idea
... I have experience bridging with different protocols. you want to be able to handle zero knowledge parsing and proxying

Benjamin: I have noted a few things that might be worth clarifying
... you said you wanted one unique ontology but for potentially multiple domains

PatrickL: one ontology for every aspect, one for signals, one for nav, one for media... to make them manageable

+1

Benjamin: they what is the common ground for telling if the signal from navigation is exposed where
... I would still support the VSS2 view. it is moving closer to providing knowledge about what all those signals mean
... we already have one example of extensions. it is not meant to be a massive model
... there may be new types of wheels, sensors going forward and don't want to have to rework the protocol
... it would be easier to have a basis for the data model

PatrickL: what worries me a little bit was this was not known to me that you went in a more generic way and not transfering pure vehicle data
... VISS was transport and VSS signals and you have grown VSS to more than signals

Benjamin: they are still just signals but not just for vehicle but media and nav

Ted: I would prefer separate data models per service instead of a huge monolithic one, they can follow same approach

PatrickL: we can continue as we have for now
... to really follow what is happening on VSS side is a challenge
... Gen2 can be influenced by ideas from VSS

Ted: having these moving separately and independently is a big part of the problem, we can have more VSS discussions here. we have heard they are open to requirements from Gen2 side

Magnus: I agree, we should work closer with VSS instead

PatrickL: we don't have a full quorum so suspect we will continue next week

Benjamin: if there are requirement from Gen2 for VSS2 please feel free to share anywhere
... Ulf and Daniel are active but that is pretty much it. I agree improved communication would help and would appreciate the feedback

PatrickL: as I don't understand the current state, eg going beyond vehicle signals
... my commits to Gen2 are what I would like to see in VSS

Ted: Benjamin, perhaps you and Daniel can prepare a summary of changes, ideas and direction for VSS for the group?

Benjamin: we could and that would be helpful with the communication aspect