Ted: we'll defer to email on this but I was
curious if Patrick received an answer for hosting our F2F at VW in
California. He was there a couple weeks ago and was going to try
to get a firm answer in person
... if not we'll have to look at other alternatives, ideally from
one of the participants in the group who have an office in the
area
... I imagine people will want to book their travel soon
Ted: second half of the week of our
next F2F is the transportation data workshop
... in some cases this may be more pertinent to colleagues in your
company which I hope you have reached out to to see if they are
interested in attending
... even if far afield from your current work I would think it
would be worth attending and you can report back to your
company
... I sent a reminder to register
to our mailing list earlier, deadline to do so is 8 July
Glenn: I will register and be submitting a whitepaper along the lines of the convergence accelerator
Daniel: same
Ted: I was hoping for a quorum to complete this topic, there was maybe more of one last week in my absence
Ulf: last week the group was firm in their support on Daniel's wording in github issue
Daniel: I made progress since and would like to get feedback and issue a pull request
Ted: in the scattered conversations I think there are two main points, figuring out what belongs in VSS spec to make it more readable and standalone and then the wording for data model within Gen2 spec
Daniel: last week we had a few discussions on the nuances of the wording and feel we are pretty close. a concrete example from media or other domain would help
Gunnar: (via WebEx chat) Yes last meeting we discussed and achieved rough consensus on the infographic. Patrick, Laurent, Daniel, Ulf and myself. Ted, we even joked that you could be absent more often. ;-)
Ted: I should miss more calls due to travel :)
Ted believes second domain for data model under consideration from F2F was notifications with Laurent or Patrick taking a first pass
Ted: we didn't get to this at the
F2F and thought we could potentially at least identify a couple
next priority items while we work on fuller roadmap
...we'll wait for Patrick and defer
Ted: Armin is getting closer to
completion with his policy language and at the F2F wanted a clear,
detailed example to see how to represent it
... we also had a demo of Ulf's Gen2 prototype with a speedometer
client app
... in the BG data task force we discussed defining a mock 3rd
party application that would want to access and evaluate a modest
number of signals, perhaps off-boarding a few and then we can work
on the accompanying policy
... we batted around a couple ideas eg vehicle management for a
family, Glenn and Harjot were willing to talk to their product
people to see if any ideas for an interesting/plausible one has
come in from user feedback
... we'll put a writeup up somewhere and allow for input and scope
creep from the group before freezing it
Harjot: I did reach out to a few of our contacts and waiting to gather the full reponse and will update you accordingly
Ted: it would be helpful to have some realistic if not real sample data but probably have to wait until we know what signals we will want to collect
several potential topics for upcoming calls such as BMW WoT demo, maybe better during our earlier call time in our biweekly rotation
Daniel: actually Benjamin and I were discussing earlier and could go through the slides and give an example now
Minutes from W3C Web of Things workshop on demo
Benjamin: we attended the W3C WoT
workshop hosted by Siemens
... the Things Description is advancing on REC track, it is a
semantically annotated thing
... we chose HVAC system but you could pick any branch within
VSS and we wanted to show some practical examples
... this slide is a serialization of the data. JSON-LD combines
simple JSON information with linked data characteristers with
corresponding ontologies you can dereference
... this makes it nice for machine and human readability. we
did one with all the security requirements defined in the
specification
... how you interact with the thing (vehicle in our case) what
the payload of a message being sent to the car
... what protocol is being used. we built it on top of BMW
connected drive, used the web API as a basis to build the car
web thing servient (WoT term)
... this provided an interface showing flows in NodeRED of
certain interactions
... they are connected to either web things end points
... we could include some nodes that are indirect interactions
with the vehicle
Daniel: an important addition is that from the thing description there is no additional work needed to generate interaction rules in NodeRED (open source tool)
Benjamin: that is a rather
complex example, when you perform this action, trigger this
other...
... we showed this to the WoT community, we also played a bit
with some more complex thing descriptions
... we received some good feedback
... non-automotive experts could devise ideas on how to utilize
a vehicle as a thing
Daniel: (projecting making car
things on fly) this is a view in
nodeRED, car imported through thing description and here are some
example flows
... we could read position long/lat separately, whether the car
was secured (locked) and could perform remote unlock
instructions
... we could use MS flow to send a message to your phone if an
event occured on your vehicle
... the server nor car are running right now so cannot show
that right now
Ted: I presume this is purely research and no immediate plans to turn into a product
Daniel: exactly, see how to bring something complex like a car to WoT
Benjamin: we basically used some more advanced features of thing desciption to link different parts (VSS branches) of the vehicle, how they relate
Gunnar: (via WebEx chat) No questions from me on the web of things, interesting though.
Ted: very cool, from earlier
discussions I was expecting a vehicle to potentially be split
apart into various simpler things for different purposes
... regarding longitude and latitude from
elsewhere - maybe we want to add to VSS since we don't have a
LBS/Nav domain underway
[better would be to come up with a rudimentary domain for long/lat
etc and that can be discussed at transportation workshop]
Benjamin: it might not just be long/lat that is missing from VSS
Glenn: I was curious for autolock based on distance from vehicle, what is the communication like?
Benjamin: I didn't work on that piece of the code, think it was just a distance calculated from the app on phone
Daniel: correct, we sent location
from phone to nodeRED server that knew where the vehicle was and
did the calculation
... we didn't worry about battery/power consumption or
anything
Glenn: instead of VISS on the car you are getting the data from BMW connect and converting?
Benjamin: correct, you could
produce the signals otherwise and map to VSS and use in
nodeRED
... to Ted's earlier comment, yes an expert to a subset of
signals and concerns around them would think of solutions and
consumer needs
... we can customize the behavior and preferences of the
customer as their needs may vary
... as you said, it isn't about exposing a vehicle as a thing
in entirety but one of several things for different
purposes
Ted: cool, so what's next? - that you can talk about obviously
Daniel: this demonstrates the
power you can achieve with these standards and using nodeRED shows
that you can rapidly drag and drop custom capability
... next step is transportation workshop
... this gives us again an opportunity to see how it can fit
into broader transportation realm
... the domain knowledge we express in VSS/VSSo can be combined
with other transportation ontologies for a wide array of purposes
Glenn: it has got me thinking
about how we can integrate other applications and create
value
... this may also help draw other OEM into these standardization conversations
Daniel: disclaimer: just because
we express interest in standards doesn't mean we are opening
this up anytime soon
... it is still just a research project and there will be business decisions as
for what is next. we are thinking of the technical
perspective
Glenn: understood. looking from OEM perspective, open would be risky and a gateway to services would be necessary to govern interactions
Ted: from what I understood NodeRED
was operating in the cloud and communication go-between from car
and other thing (smartphone etc), no direct interaction to
vehicle
... strong auth can be enforced and conditions from
vehicle (eg it is moving) that limits or severs tie to server
Daniel: correct
Ted: I'll start a doodle and send mail about summer schedule, figure out when people will be on vacation and we won't meet
This is scribe.perl Revision: 1.154 of Date: 2018/09/25 16:35:56 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Present: Gunnar Paul Ted Glenn Magnus Ulf Daniel Harjot Benjamin Don No ScribeNick specified. Guessing ScribeNick: ted Inferring Scribes: ted WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 02 Jul 2019 People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option. WARNING: IRC log location not specified! (You can ignore this warning if you do not want the generated minutes to contain a link to the original IRC log.)[End of scribe.perl diagnostic output]