[WoT RPC proposal]
Daniel: forgive the rough drawing
sketch
... I had some internal discussions in WoT group
... what is still missing is RPC calls and relation to VSS as
raised in repository as well
... seems we are deviating already from VSS
... the example in VSC repository already shows lack of
alignment
... in VSS we have branches, sensors and actuators
... how do we get this together with RPC idea
... we have VSSo (ontology on top of VSS) although it needs to
advance from VSS1.0->2.0
... thing description is thing deployment, description of VSS
tree excerpt needed and the RPC call
... we have all the units etc in VSSo. we have data schema and
with it can link to VSSo signals
... thing has properties attributes and events. you can have a
describeable property
... actions are equivalent of RPC calls as I see them, you have
input that triggers action
... actions can either use actionable signals from VSSo
... works for simpler scenarios with small set of clear
signals, some cases like cruise control would be more
complicated
... we can sort RPC calls based on topic branch. WoT makes it
easy to point to underlying signal
... there is existing tooling for WoT including bridging to
different underlying protocols
... happy to share a short example
... using a JSON-LD file, where context comes in place you can
see here a window and its properties eg position
... you can say the thing is observable. WoT can generate code
to HTTP REST, Sockets etc
MagnusF: so this is like a window object description with methods, gettables and settables
Daniel: exactly
... it can include what we can to describe with VSS and
separate RPC calls
MagnusF: haven't read on VSSo much, can I use inheretance etc?
Daniel: right, you don't have to
use a branch but did so to make it more understandable
... you can have link to branch, use single elements
MagnusF: how to get a notication and needed interface when someone else changes it?
Daniel: this goes through to all
thing descriptions. you would refer to notification
interface
... I split deployment from modeling in my example you would
provide URL to where you would get notification
... as mentioned WoT supports a number of protocols
already
... we used our thing description, Node and did some drag and
drop to create the interaction
MagnusF: completely different
approach, not necessarily bad
... this ties RPC and signals into a more traditional object
model
Daniel: exactly
Joakim: there is a vocabulary but
those objects or statements are schemaless
... any examples on how to query this?
Daniel: I prepared this last week, earlier example not running at present
MagnusF: Steven, curious your reaction?
Steven: what comes to mind is it
changes what we would define as a service. we have been seeing
it as a collection of RPCs
... now you are seeing service as collection of objects that
belong to that service
Daniel: yes and no. you bind it with logical bundles
Steven: do like how this makes the model more unified
Peter: you mentioned there are a
number of protocols already supported
... we have similar API that is agnostic about protocol
Daniel: you need to make the protocol bindings in thing description, doesn't have alternatives easily
Peter: I want to provide developer option to close all windows
MagnusF: still a bit confused on
classes vs objects
... for services we didn't really have objects either but here
how do we instantiate eg close all windows. how do I get the
objects to call?
Daniel: you just describe the API
you are calling. you don't really define it since it is done
already with its ontology
... then the tooling lets you choose what exists to expose
MagnusF: I'll need to read more on the ontology
Ted: fair warning, Semantic Web and ontologies gets rather academic rather quick, you don't need to delve deep into its background but keep higher level focus
MagnusG: can you provide link to think description playground you are using?
http://plugfest.thingweb.io/playground
Ted: we have jumped around on protocol preferences, believe we need to have clear requirements and develop some more use cases in detail in order to make more informed decision
Joakim: I use this technology for analytics/queries more than calling functions
Wiki scratch space for use cases
Daniel: it gets hard to get
agreement on protocol that everyone would use
... common definition of services (functions) being offered of
huge benefit
Peter: yeah
Daniel: perhaps you want to map to an underlying existing API, possible to have different instantiations
Joakim: in W3C Media and Entertainment we defined first an ontology to represent all the information and API later on top of that
Ted: I want VSC to reuse VSS signals as defined. if VSC follows same taxonomy then creating a corresponding ontology using same tooling (needs to be revised for VSS2) is straighforward and you can have signals and service functions in Web of Things playground in creating your thing description
Joakim: there are many metadata
formats for media on the web but we wanted to say what the
relationships were and to make it easier for developers withou
knowing 25 different formats
... here I am imagining OEMs have their legacy signals, naming
of functions and this can be a layer on top
Daniel: layer is only in terms of
communication
... you point to the underlying REST API
Joakim: reason I mentioned EV
charging the other day, it is becoming more important
... it would be good if we could do something in this group for
the different players to be able to jump in
... we want to make it easier for our partners to tie in
Ted: maybe see if you can have Adnan replay the video
Daniel: we have a paper about it
Ted: basically after Peter and Daniel approve my pull request to VISS and Peter sends out a Call for Concensus we can more VISS from Candidate Recommendation to Proposed Recommendation
Ulf: from my point of view I see
it as complete and a working design
... working on implementing it in our Gen2 implementation,
prompted a small pull request Ted already approved
... minor details, so far see this as working, not seeing
additional issues
Glenn: we sent GENIVI a licensing agreement for our curve logic algorith, we will want an open source and open standard to accompany it
https://www.youtube.com/watch?v=2vxsyJLygws
Ted tries to describe it
Ulf: what you can use to describe
it is it allows you to throw away many data points
... the ones you keep allow you to reconstruct to a reasonable
error threshold the full picture
MagnusF: I have done this under
another name for aerospace
... you do not need full resolution but just the diff, in fewer
bits. you don't know full location but the delta
Ulf: that is not in this algorithm
Ted: initially my interest was in
metadata on how sampling by an app is done when offboarding so
it has more value in the cloud, also degree precision etc
... adding sampling
methods to Gen2 reduces complexity of client applications,
convenience to developer
[Ulf presents sampling characteristics slides]
Ulf: it affects things like data
quality, bandwidth and maybe other things
... if you want as client to be able to read sampling
characteristics available in the vehicle, you may want to also
be able to set it
... should it be per signal, group or for all signals sent to a
given client app?
... it could also be set vehicle wide
... perhaps even be able to support all of the above. how to
perhaps provide that control
[example using #sampleMethodX]
(for per signal or group of signals)
Ulf: WebSocket could readily
support or HTTP header
... setting it per vehicle, it should be a node in the
tree
... then could be
Vehicle.Connectivity.Data.SamplingCharacteristics
Peter: per vehicle is
interesting, would that be for all signals exposed by
Gen2?
... per signal I see more valuable
... to try to not overcomplicate would be a goal
Ted: I could see benefit of doing
so for the vehicle so all Gen2 clients are limited in what data
they consume. maybe default but overrideable
... HTTP doesn't make sense unless you requested earlier and
want to keep subsequent request open, strains HTTP with
timeouts. WebSocket on the other hand quite natural for
this
Ulf: if we are to introduce in Gen2 it would need a chapter
Ted: wonder what methodologies we want interval, simple delta (eg +10), curve, event
Ulf: we already have interval and
delta
... for subscriptions
... per signal for delta
... we might have another already
Ted: others interested?
MagnusF: clear need as long as we can keep it simple and easy to understand for developers
Ted reviews discussion and options
Gunnar: I want to object to CVIS since it is close to CVII
MagnusF: I would go for VISS
version 2
... it is established, doesn't clash
Gunnar: there was some concern on Service being in name given Vehicle Service Catalog
Ted: could change that S but that might cause confusion
Ulf: changing it to Signals would help
Gunnar: then it is too close to
VSS
... how about VIPS - Protocol
MagnusF: I like that
Ulf: then you loose connection to VISS
Peter: my vote keeping VISS
Adnan: relation to signals a bit
strange, made some suggestions
... CVIS maybe
Gunnar: CVII is perhaps turning into a significant initiative
Arman: Connected a bit redundant to interface, no strong opinion
Daniel: VISS version 2
Glenn: no strong preference, defer to Ulf
Gunnar: VIPS
Karen: don't mind CVIS as it
compliments CVII more than causes confusion
... VSS has some history
MagnusF: VIPS
MagnusG: no strong opinion VISS or CVIS although latter has prior meaning for me
Peter: VISS
Urata: no strong opinion understand VSS and VISS a bit confusing but VISS2 natural for me
Steven: equal for VIPS as Protocol part helps or VISS2
Ulf: CVIS as well, VIPS as 2
Ted to send finalist to survey
[adjourned]