Ted: I want to discuss a proposed Transportation Data Workshop, looking at last week of June 2019 in California
Ted explains W3C process, what a workshop entails. position papers, program committee, sponsors, host
Ted: we want to see if there are
common needs, issues and proposed starts to solutions, goal is
to scope potential new working group
... this will be separate from the W3C Automotive Working
Group
... I have been meeting with some interested parties, will
schedule a brainstorming call Thursday or Friday of next
week
... looking to this group to see if there are interested
individuals in being part of the program committee
... what's involved: setting initial scope, reviewing papers
and attendee applications, setting agenda for workshop,
participating in report
[[
potential workshop topics:
-consent capture & policy language
-metadata - sampling, accuracy
-additional transportation ontologies eg profiles, trip data
-other transportation data - routing, traffic/construction/hazard, weather
-other off-boarding challenges and data marketplace enablers
]]
Glenn: we have strong interest in
this workshop and would be interested in sponsorship,
presenting a position paper
... it is aligned with our interests
Ted: do you think someone from Geotab would be willing to be part of the program committee?
Glenn: yes, definitely and draw from a pool of people involved in this space
Gunnar: I want clarification on whether this would be part of current working group or new
Ted: it would be a new working group. the current one is chartered to deliver in-vehicle services
Gunnar: interesting but somewhat
diverse set of topics, we are having some car to cloud
discussions at GENIVI as well
... privacy policy and data contract is not in our scope
... would like to delve into what topics will be explored
... would recommend keeping the scope narrow
Ted: agree, the purpose of stating topics up
front and having a program committee is to ensure it does not get
too broad
... we try to compliment efforts instead of compete against them,
avoid recreating wheels and leverage work at other standards bodies
... is there a writeup yet for car to cloud activity GENIVI is considering?
Gunnar: some, will be made more
concrete at AMM in May
... we will have presentations on different companies
views
... we will be looking at the whole picture, existing standards
that can be leveraged
... we would like to see how to collaborate and promote each
others activities
Ted: similar to our state then. incidentally I am not anyone communicated but we decided to have our next face to face in Munich ahead of the GENIVI All Member Meeting on 13 and 14 May so as to avoid competing with those attending AMM sessions
Gunnar: that makes sense, Tuesday is members only, Wednesday open day
Ted: not sure if one of the chairs asked yet but if there is meeting space we would be inclined, if not we speculated BMW, VW or INRIX could host
Gunnar: I'll have to check
Ted: as I will be unavailable on Thursday we will be cancelling the data task force call. I will try to circulate draft outline for workshop by then
Ted: it is quite common to reference
other standards within ours as mentioned, however we have two
dependent pieces moving simultaneous (VISS Gen2 and VSS) at two
different orgs (W3C and GENIVI respectively)
... corporate policies govern what projects and organizations
people can participate in and unfortunately that is the case here
where at least one and perhaps other individuals cannot contribute
to GENIVI repo
... that can be a challenge even though we have full overlap of
participants from VSS in W3C Auto
... I want to see if others have this issue, either on or off the
record and see if we can come up with a solution
... we could have a convention where if an issue in the W3C spec
stemming from underlying data model arises, the issue gets raised
on W3C github repo
... I or others like Daniel and Benjamin can make sure it gets
referenced in the GENIVI repo and resolved
... we could take this further and leverage the decentralized
nature of git and have a checked out fork in W3Cs github where
issues, commits and pull requests can be made directly
... we would want to routinely reconcile them in batched pull
requests to GENIVI repo
... others have any thoughts, ideas or concerns?
https://github.com/w3c/automotive/pull/298
Ted: my recollection was this stemmed from Magnus Feuer's Remote Vehicle Interface (RVI) project which is now defunct
Gunnar: unsure the exact history but it is not tied too closely to RVI but meant to solve general need to describe vehicle data
Gunnar: with open licenses it
doesn't really matter where it resides
... the way I see it at present, VSS design decisions are coming entirely from
the W3C group
... to the point of contributing to the different
organizations, I would not cater too much to companies who
cannot contribute to open projects
... technically speaking what you described is true, including
using a common base between the different repos
... that would essentially make it one project
... is it possible to put this in writing to GENIVI so it is
not second hand information
Ted: I can ask if person wants to
bring it up with you directly, not expecting him back for a couple
calls due to work travel
... are there other groups at GENIVI using and relying on
VSS?
Gunnar: not offhand but alternative acces methods
besides VISS like MQTT are being discussed
... I would hope those to be based on the same or similar data
model
... I do not see a technical fork in the road at this
point
... it becomes a group decision then and unless there is a
disagreement, no need to fork
Magnus: I second that
... it is not good for us to be moving away from VSS but if we
have a problem with the current arrangement then my suggestion
would be some sort of proxy convention as you described
... it can be handled within the data task force or ordinary WG
calls
Ted: in case you missed it, we wanted to go protocolless but were advised against doing so as SOAP/Web Services tried and failed. nonetheless we are try to avoid being too protocol specific to give implementers flexibility
Gunnar: I would make the opposite
observation, you are not leveraging the protocol enough
... it doesn't necessarily mean you accept MQTT or need to
specify it but be cognizant of it
Ted: agree we are working more to not preclude it. point being if/when GENIVI starts on MQTT, consider leveraging Gen2
Gunnar: second that, we are
aiming for the same thing
... there may be more ways to do things than just MQTT and REST
but they are still useful to define
... vehicle data can be used (and accessed) in many different
ways
Ted: in summary, we will work with proxying conventions and if that is not sufficient we can consider fork and regular reconcilliation
Glenn: when working on an ANSI
standard and reconciling in EU and NA. we had a liaison
... should we do similar here?
Ted: I feel we have that
Gunnar: we have an agreement (MoU) in fact and collaboration for years
Ted: not much time to delve into issues and not the right people on the call. I encourage people to read and provide responses directly in github in the meantime
[need to wait for Ulf, Benjamin, Daniel on underlying VSS + Wildcards]
Gunnar: related to earlier
non-REST approach, we need to separate these things
... perhaps some of these pull requests should be discussed
before proposed
Laurent: pull request initiates a discussion
Ted: Ulf essentially does the same, helps to have something tangible
[adjourned]