[Architecture] Ensuring the statistical matchmaker works before Luxembourg

Andreas Stiegler stiegler at hdm-stuttgart.de
Tue Jan 13 16:26:07 EST 2015


Heyho Kasper,

 

Oh, I’ve been  told that we would manually set that those context blobs are active. If not, we should add conditions to those two blops identifying that we are on the dtv or the vending machine. I sadly don’t know how we could tell that (and it somehow spoils the idea of those two scenarios with him not having any pref set entries for them). If there are conditions with something like “device ID” or so, that should do.

 

Other option: make the SMM default and add dispatcher overrides for the RBMM, but that would requiring altering the conditions and context blobs in the vlad profile, as then gpii-default would have to be SMM.

 

I think we should go with the first option: a condition for device-id or something equivalent that allows us to tell that we are on the DTV or the vending machine. If somebody could add that to those two context blobs along with a priority, all should be fine.

 

The two context blobs just serve the purpose of dispatching the call to the SMM, they are not required in any other regard.

 

Best regards,

Andy

 

From: Kasper Markus [mailto:kasper at markus.dk] 
Sent: Tuesday, January 13, 2015 9:21 PM
To: Andreas Stiegler
Cc: architecture at lists.gpii.net
Subject: Re: Ensuring the statistical matchmaker works before Luxembourg

 

Hi Andy,

Thanks for your reply!

The one thing I'm still not quite understanding is the "log in with the pref set and the respective context active". The decision of the active context is up to the minimatchmaker and based on the 'condition' blocks along with any priority on the context blocks. I might be missing something obvious, but I just wanted to make sure that this will work with Andres' work merged in as well.

Good luck on your Glasgow lectures,

Cheers,
~Kasper



On 1/13/15 3:00 PM, Andreas Stiegler wrote:

Hi Kasper,

 

The blocks in the pref set are only to ensure that the SMM I used (given the dispatcher is included in the Luxemburg version).

The idea behind those two SMM scenarios is, that both are scenarios where vlad encounters devices that he never used before (ticket machine, hotel screen), but were used by many other people already. So what the SMM does is searching through its database for users that have similarity to the other settings that vlad used in the past and infer settings for it (and magically, our training data for the review covers both the vending machine and the dtv well).

We did tests with the SMM here covering both scenarios. So unless vlads pref set changed, all should be fine. We were never able to test it with the actual vending machine or screen hardware of course.

 

Testing should be rather simple as the SMM is being deployed on the IDRC cloud. Once that’s done you should just be able log in with the pref set and the respective context active. The dispatcher will forward to the SMM and apply the settings.

 

The whole call chain works and was tested over here, but I don’t know if the dispatcher is already in.

 

If you want to install the SMM locally, just go to https://github.com/REMEXLabs/GPII-Statistical-Matchmaker , and follow the instructions (npm install and delete duplicate infusion inclues).

 

I’ll only be available very sporadically this week, as I’m giving guest lectures in Glasgow.

 

Best regards,

Andy

 

From: Kasper Markus [mailto:kasper at markus.dk] 
Sent: Tuesday, January 13, 2015 11:45 AM
To: Andreas Stiegler
Cc: architecture at lists.gpii.net Architecture
Subject: Ensuring the statistical matchmaker works before Luxembourg

 

Hi Andy,

Hope you've had a nice christmas and new year!

We're getting scarily close to the review meeting and in that connection I have some questions/requests for you:

*	For the vladimir scenario - there are some blocks describing that the STMM should be used (https://github.com/kaspermarkus/universal/blob/review3/testData/preferences/vladimir.json#L76-L87). These are modeled as context blocks, but it's not clear to me how the system would evaluate these blocks to be active.. Could you clarify this?
*	We have not yet tested any of the ST MM scenarios and it would be good to have done so as soon as possible. Since the ST MM is used in the scenarios of the Kiosk and DTV, the only people really able to test it properly pre-luxembourg would be Jasmin and Thomas respectively. So, would you be able to write up instructions to them on how to set everything up, deploy the ST MM and run the tests so they can try it out and we can find any potential issues before meeting up in luxembourg?

Cheers,
~Kasper

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20150113/d377d341/attachment.html>


More information about the Architecture mailing list