W3C home > Mailing lists > Public > public-automotive@w3.org > September 2019

Re: VSS and VIWI

From: Rudolf J Streif <rudolf.streif@ibeeto.com>
Date: Tue, 3 Sep 2019 10:35:43 -0700
To: "Luennemann, Patrick (CQTM)" <patrick.luennemann@carmeq.com>, "Winzell, Peter" <peter.winzell@volvocars.com>, "ted@w3.org" <ted@w3.org>, Peter Winzell <peter.winzell@jayway.com>, public-automotive <public-automotive@w3.org>
Message-ID: <b018ff9a-69c6-d5c1-c3a2-34b046f6b7b9@ibeeto.com>
And

/<service>/<resource>/<element>

would not be the equivalent of VSS leaf? Why not?

:rjs

On 9/3/19 6:35 AM, Luennemann, Patrick (CQTM) wrote:
> Hej everyone,
>
> I just explained the 3 VIWI levels in the call and wanted to give a textual description as well.
>
> The three levels in VIWI (be aware, there is a forth) are not comparable to the levels within VSS.
> They express a certain idea, certain type.
>
> /<service>
> This is an implementation, a service (if you want to a micro-service) bundling functionality.
> It contains resources (lists).
>
> /<service>/<resource>
> This is a list within the service. The service on this level can only have resources (lists).
>
> /<service>/<resource>/<element>
> This is an element. All elements in a resource are of the same type (defined through being in that resource).
> An element contains multiple properties.
>
> /<service>/<resource>/<element> Property
> This is a property that holds data.
> It has a certain type.
> It is the smallest item that can be filtered for.
>
>
> /Patrick 
>
> --
> Patrick Lünnemann
> CQTM / Carmeq GmbH
> Telefon: +49 160 901 319 84
>
> -----Original Message-----
> From: Rudolf J Streif <rudolf.streif@ibeeto.com> 
> Sent: Dienstag, 20. August 2019 22:26
> To: Winzell, Peter <peter.winzell@volvocars.com>; ted@w3.org; Peter Winzell <peter.winzell@jayway.com>; public-automotive <public-automotive@w3.org>
> Subject: Re: VSS and VIWI
>
> Out of curiosity: what is the reason of the tree depth limit to 3 for ViWi? Is that a technical limitation of some sorts?
>
> The reason for VSS's essentially unlimited tree structure is extensibility. The tree can grow horizontally and vertically as needed.
> When we created VSS we found this very useful. We purposely tried to avoid any limitations.
>
> Another way of possibly overcoming the tree depth limitation and potentially providing a more automated way of mapping is to use hashes for the branches of the tree that are omitted. So for Peter's example:
>
> To replace
>
> Vehicle.Cabin.Seat.Row4.Pos1.Isbelted
>
> with a SHA256
>
> /Vehicle/103890db1712299c242c7613e0195d56bd99155dab18e1ad1477a152b2ab3337/Isbelted
>
> Obviously this is not human-readable anymore and since SHA256 is a one-way function the REST server can only do a comparison to check for the resource but that comparison is rather quick. A lookup table for reverse lookup could easily be created with the VSS processors.
>
> :rjs
>
> On 8/20/19 9:59 AM, Winzell, Peter wrote:
>> Hi Ted,
>> So, could this alternate URI be exemplified ?  As this would keep the VSS model intact?
>>
>> Br
>> Peter Winzell
>>
>>
>>
>> On 8/20/19, 5:22 AM, "Ted Guild" <ted@w3.org> wrote:
>>
>>     Regarding tree depth, one idea is to support alternate URIs so you can
>>     have paths that correspond to tree branches and for those to either
>>     transparently proxy or redirect. 
>>     
>>     We remain extremely focused on vehicle signals, they are of greater
>>     interest for more participants than the other 'domains' we'll want to
>>     have in-vehicle services for. We want the protocol to be able to be
>>     able to accommodate them as well. 
>>     
>>     On Mon, 2019-08-19 at 15:58 -0700, Peter Winzell wrote:
>>     > Hi All!
>>     > Some thoughts for tomorrows’ meeting.  Looking at the VIWI submission
>>     > and the VIWI data model and how to keep VSS intact.
>>     > For me it seems that the we would try to map the VSS data model
>>     > against the viwi.service.car definition.
>>     > 
>>     > In VIWI  we have a number of vehicle data objects defined such as
>>     > car/info. infoObjects where we are able to retrieve the VIN is one
>>     > such object:
>>     > 
>>     > /car/info/<vinidentifier> 
>>     > 
>>     > In VSS:
>>     > Vehicle.VehicleIdentification.VIN
>>     > 
>>     > In Vss the vin number is defined as the tree branch
>>     > Vehicle.VehicleIdentification.VIN
>>     > 
>>     > Vehicle — |
>>     > 		 —|
>>     >                     VehicleIndentification —|
>>     > 							  VIN
>>     >                  —|
>>     >                      …
>>     > …
>>     > 
>>     >  In this case we have two tree structures with the depth 3. This
>>     > seems to match pretty well ?
>>     > 
>>     > However, VIWI limits the depth of the tree structure to 3 , which in
>>     > the following example makes VSS incompatible with the current VIWI
>>     > data model :
>>     > 
>>     > In VSS:
>>     > Vehicle.Cabin.Seat.Row4.Pos1.Isbelted.
>>     > 
>>     > In this case we would try to match this we would have to define 3
>>     > more vehicle data objects:
>>     > /Vehicle/Cabin/Seat
>>     >           - available seat objects would be returned by a GET
>>     > request, row would be one such object which links to the 
>>     > /Vehicle/Row/Rowobjects
>>     >          - available row objects  returned by a GET request. Which
>>     > links to positionObjects
>>     > /Vehicle/Pos/Positionobjects
>>     >         — Isbelted element
>>     > 
>>     > This would keep the tree limit - in my view this would transform the
>>     > VSS data model into something not VSS although we have some sort of
>>     > mapping ?. The other way around is not possible since this would make
>>     > the current VIWI model incompatible with present in-vehicle
>>     > implementations if I understand correctly. So I now see us spitting
>>     > the spec into two separate tracks where we have  VISS/VSS and VIWI
>>     > submitted as the W3C signal specification. I have a feeling that both
>>     > tracks will suffer from adapting to each other/ and in the end we
>>     > could end up with something of inferior technical quality. For Volvo
>>     > cars we see VSS as a key element to the W3C submission and we want to
>>     > continue this work going forward. 
>>     > 
>>     > Br
>>     > Peter Winzell
>>     > 
>>     >  
>>     > 
>>     > 
>>     > 
>>     > 
>>     > 
>>     > 
>>     -- 
>>     Ted Guild <ted@w3.org>
>>     W3C Automotive Lead
>>     http://www.w3.org
>>     
>>     
>>
-- 
-----
Rudolf J Streif
CEO/CTO ibeeto
+1.855.442.3386 x700



Received on Tuesday, 3 September 2019 17:36:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:06:14 UTC