https://www.w3.org/auto/wg/wiki/Vss_data
Ted gives high level intro
Glenn: use cases that benefit
individuals can span multiple vehicle manufacturers
... road use indicator is one such example
Ted gives a high level overview of what the project's goals are, collect and represent some signals in VSSo to support an interesting and impactful set of use cases
Joakim: we want to be able to
share anonymized data in collaboration with other using this
common data model
... it is doable. it is a process...
Glenn: in the last couple weeks
we have been advised on addition requirements with the proposed
protocol and going through a vetting process
... we may be able to provide it for consideration towards an
industry best practice and preparing it to share with this
group
... we can bring a legal representative for us give a
presentation
Joakim: that would be helpful
https://www.w3.org/auto/wg/wiki/Vss_data#Use_Cases
<gatkinso> re: sharing data see CISCO TRUST LINK https://www.cisco.com/c/en/us/about/trust-center.html
Ted: you'll see various succinct use
cases and corresponding signals needed to support them
...there may be some missing signals so do please look over and
add additional you think would be useful
Harjot: to what detail were you looking for in the use cases?
Ted: we can develop the selected ones in more detail including what sort of benefits the questions may have in the real world
Harjot: some of these use cases require bidirectional communication. also a challenge trying to get harmogenous data across different sets
Gunnar: can you elaborate on bidirectional communication?
Harjot: mostly around resetting thing in IVI
Gunnar: my understanding is you are looking to collect data and be able to run applications against it and demonstrate queries
Glenn: relates to GENIVI meeting
recently, in addition to collect data there are some use cases
for sending signals back to the vehicle
... suggestion was to bring it to SAE and there is some
coverage there
Gunnar: the use cases where you
have to affect the car itself are fewer than the reading and
analysis
... you can define actual remote APIs and keep it out of the
data exchange category
Ted: for now we should keep the project scope to simple reads. should we have time later and can support some mock/fake vehicles to write to we can look into more
... I am rethinking trying to narrow down our desireable use cases and see what use cases we can support with the signals we can get
Glenn: I think Ulf has a list of
signals for specific use cases
... we have started looking at how to bring some signals from
our format to VSS
... a few of the signals are found in several as Ted
illustrated and may help the use case selection
... certainly will be good to get something with actual GPS
Joakim: there are various recipes we should work on for uploading format to be supported
Gunnar: maybe we should start with the use cases
Adnan: what would be useful in the use cases is details on frequency of requests, number of vehicles
Joakim: that is interesting and yes having that detail would help
Glenn, Gunnar and Ted discuss the sensitivity of GPS even if we strip time and all identifying information
Ted: could do some sort of offsetting algorithm, undisclosed minutes,degrees long/lat so we can look at eg hard braking in a made up geofenced area
Ted suggest updates to wiki on granularity, starting inquiries into what signals you could potentially get
Joakim and Adnan to start making internal inquiries, easier if more specific
https://lists.w3.org/Archives/Public/public-automotive/2019Nov/0017.html
Ted: kind of early to be discussing
the datastore engine given we are still in process side but why
not
[summarizes email thread with Benjamin]
Benjamin: you basically summarized what I described, happy to help toward an rdf+sparql
Joakim: what graph db would you suggest?
Benjamin: there are some stacks around W3C specs, rdfs, shex, sparql - I was thinking of hypergraphql
Benjamin: you can have great
specifity
... neo4j meant to be industry compatible
Joakim: I am more familiar with sparql et al too, how do you even import the db into neo4j with the ontology
Benjamin: there are some ways and
proprietery internally
... the tools are there
... agree with Ted to try both approaches
... depends on the data requirements we want to express
Glenn: we would be prepared in two weeks to have a draft policy document on data collection
Updates to wiki - signal granularity
Sparql et al Recipe in mail thread or on server from Benjamin for Ted to follow
Joakim and Adnan to make initial inquiries