Meeting minutes
Holiday break
RESOLUTION: cancel calls last two weeks of 2021
Peter: anyone going to CES?
Ted: Geotab will be there but I am avoiding
Peter: COVESA will be there
Ted: can you ask Alan if W3C will be at CES and if they are interested in coordinating with COVESA for their event and in outreach?
Carine: will do, not sure if they'll be attending in person
VSSo preparation for publication
https://
[discussion of W3C REC track stages]
Ted: Carine, to graduate from Candidate REC what is needed for an ontology?
Carine: it can be tools or produced results
Ted: after CR is Proposed Recommendation and then Recommendation
… for an ontology that will get additional signal definitions with getMetadataunderneath, I expect we would stay at Working Draft or CR
Daniel shares screen
Daniel: VSSo was initially created from VSS1.0 which has been revised extensively and the tree now makes more sense for an ontology
… we've discussed use cases, created a primer including its motivations and have Core document with structural concepts on sensors, actuators and branches, how it maps to OWL
… the generated signals and attributes come from VSS
… there are three separate documents
… attributes can be static or dynamic, using SOSA for the latter
… we wanted to be as close to SOSA as possible
… we have observable and actuable properties which is linked to the naming, vehicle components that come from the structure of the VSS tree
… I'm working on examples at present
… how this will be used in practice makes it much clearer
Daniel: Daniel Alvarez is working on tying it to a stream for AI
… for use as you said at scale and for AV
PR and Issues
Ulf: Isaac came up with an alternate flow to my earlier proposal
https://
Ulf: open flow becomes a bit explicit and reasonable to see here
… you start with the access token already
… for the earlier flow you had short and long term options
… this new one lacks stated purpose
… Isaac's proposal doesn't have an explanation on the flow but states scope can be either a purpose or signal set (in the token)
… I kind of like this myself, it is simpler and have no objection
… there needs to be clarity on the flow portion, saying this is optional for signal set but must be there when there is a purpose
… this is as complete as my proposal
Isaac: I tried to make it as few changes as possible to the original flow spec
… you can use explicit signals with either short or long term access
Ulf: good argument and agree. I vote for your proposal
… how do we reach a decision?
Ted: as you prefer this solution to your competing proposal, I think we have our answer
Magnus: go for it
Ulf processes pull request
and removes earlier
https://
Ulf: I describe how the URIs for the different servers can be created including port numbers and authority part
… presented previously and propose we move forward
https://
Ulf: we have to make clear to client implementation variation, what optional features are supported
… Gunnar was in favor of having everything mandatory or excluded from the spec
… besides filtering the other major variation is in access control
… we need a mechanism to inform client
… for access control that could be handled by the access grant server, learn what is implemented in this particular instance
… for filtering we should support time based
Ted: also delta change filter from v1. agree ideal would be no variation but more realistic is to minimize and make clear to the client
Ulf: I thought we can produce metadata in VSS