RE: VSS and VIWI

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
>     
>     
>

Received on Tuesday, 3 September 2019 13:35:52 UTC