several showed up without registering eg us, Volvo and a few others
Adnan and Peter's to be sent to public-automotive
Summary of interactions with Autonomic, Ford, Honda, LG, others
from Q&A data integrity metadata, realtime/latency considerations for eg v2x use cases (from Lynn @ Ford)
discussion/recap of web payments task force which was of interest to an OEM in the room
discussion of VSS gaps and EV signals - agreed in Munich after vss2.0 release. BMW, Siemens, others
CharinEV/IEC
Glenn: NIST is holding a meeting on cybersecurity Thursday 12 Sept for EVSE
Magnus: if we are taking up v2x use case, do we care about the bandwidth of the data channel? 802.11p is limited
Ted: uuid gh issue for vss will help, terser than full descriptive label
Adnan: do we have to take that into account, it is a limitation of the network layer
Magnus: yes but you cannot ignore it either given time sensitivity
Ulf: you should accomodate
condensed transmission like using uuids, which helps this use
case
... not sure we need to do more in spec itself
Glenn: have we reached out to OmniAir? they are responsible for v2v safety message
Ted: no, just ITS
Glenn: we should reach out to them, they're pretty advanced at this point
Ted: too late then probably for
v2v but possibly still for v2i
... still relevant for translating instead of having to do
custom v2v app per oem
Magnus: wanted to be sure scope isn't changing
[prep for larger group discussion, wiki generated from whiteboard end of yesterday]
https://www.w3.org/auto/wg/wiki/Viws
[tangent on Graph, who (redacted) is prototyping what based on VSSo and interest in having a demo, how that would be useful]
Agreement on wanting to create GraphQL PoC/demo with VSSo
Adnan shares a Youtube video (one less redaction), will provide link for minutes
<magnus> link?
(err video is 'unlisted' so still somewhat redacted... sending in personal mail, not to list)
(awaiting ok from conf organizers or similar)
Ted: I had on agenda what this group can work on while this circular viwi/viss/gen2 debate does another lap
<Ado> https://blog.mirumee.com/highlights-from-the-graphql-summit-2018-in-san-francisco-49d7ab20f5cd
Ted: I will fill in the wiki more and encourage others to as well. not expecting us to resolve this at f2f unfortunately
[discussion of uuid and tree position, need consistency if location changes]
Adnan presents diagrams of analysis he and Daniel did on ViWi data
Adnan: please correct our
understanding. on third level you can have elements under a
number of resources
... we focused on use case/example data structure for
media
... we put some nodes together. we see this as more application
centric than data centric
... we really liked the registry approach
... each service might come with its own overlapping data
model
[p3]
PatrickL: could you go back to
#2?
... property would be the connecting link to that element
... album has the artist pointing to the element artist
Adnan: you would still have
relationship end to end since you can have multiple, adding
complexity
... it is still valid, not being critical
PatrickL: links go from property artist to element
[p3]
Adnan: if we try to map VSS data
model to ViWi you can see replication of several resources
within element
... resource should not have elements such as isOpen, isLocked.
not sure what sort of flexibility we might have there
... each service could populate its own data model based on
registry
... what are your thoughts on how to find common solution
PatrickL: there would be
taxonomies for everything in vehicle and trees or subclasses
for different use cases
... to find those I would use something like registry
... I have one taxonomy about everything in the vehicle
Adnan: there could be multiple
domains
... you would have a data taxonomy for each and service
registry would discover tree and expose
PatrickL: would there be one implementation representing the whole vehicle signals or could it be split into several
Ulf: one should strive for having one single entry
PatrickL: that would not work with what we have, we cannot fit everything
Adnan: do you have an example?
PatrickL: we can have 4-5 implementations regarding seat and distributed, listed separately in registry
Adnan: that is fine and could
work, it is up to service registry on how to handle this
... we want to map data to something understandable [to
developer]
... from service registry it would be mapped within the
tree
... you do not need to know what service is doing but want to
use tree to find the data
PatrickL: ok, was confused by the one implementation
Adnan: how to approach and resolve...
PatrickL:
service/resource/element
... every category of element that is the same type, eg seat,
is a resource and every bundle has elements
... service/resource/element is about type and not tree
representation
Adnan: yeah but you would break
the taxonomy, exposing the tree
... can we find a common solution where we use existing parts
from ViWi and modify things based on tree taxonomy of eg
VSS
PatrickL: this matches quite well
with my pull request from earlier in the year
... it allows for a graph and not only a tree. it does not
follow service/resource/element way but chains
Adnan: that would be ok with you in VW?
PatrickL: yeah
Ulf: so you're saying we can keep arbitrary depths? if so can you please provide some examples
Adnan: maybe case of accessing pressure for tire, what is the path?
PatrickL: currently not possible
Adnan: but for the new ViWi
PatrickL: I would create it for
the element and property, worth doing to be understandable for
developer
... I would make 'blue bubbles' (cf diag) so you don't always
have to go through the registry
... the seat has a list and points to these four
implementations, it would be a type of node
Adnan: did you think as well about reverse compatibility for ViWi
PatrickL: not interested in that
but a good new protocol...
... ok with breaking compatibility. what we have works fine for
a developer
Ted: so you're back to Gen2 and not 'the other Patrick' interest in ViWi
Ulf: what you say can then handle VSS as is and that scenario?
PatrickL: of course as people are
using it
... I do think VSS could use some changes and no special
types
https://www.w3.org/auto/wg/wiki/Viws
RESOLUTION: Gen2 revitalization
Glenn: objective is to expose the
common data model to a broader audience of developers
... we can present oem and data provider using this and then
various participants can demo to various audiences at
conferences
... refine scope over the next few weeks
[light minuting]
@@see notes
https://www.w3.org/comm/assets/staging/auto/
Harjot: I suggest s/Big Data/data analytics/
Ted: I guess s/in-vehicle and cross-vehicle applications/in-vehicle, cross-vehicle and cloud based applications/
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./
Ted: s/blizzard/confusing
array/
... s versions proprietary interfaces
... s Web applications applications
... s next version next generation
... with accompanying reference / demo implementations
... is primarily focused on/is
_W3C_ Web of Things
associated - stemming from. example based on / leveraging
drop the other domains for now on landing page
descr on wg & bg from onboard email
comment out <p> starting with Applications, of course,
comment out related auto until we get other sdo liaisons
Harjot: I am happy to take a pass at it as well if you throw into a google doc
Ted: will do
https://www.w3.org/2019/07/trans-data-ws/agenda
(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)