[Architecture] return payload from the matchmaker

Claudia Loitsch claudia.loitsch at tu-dresden.de
Mon Feb 18 10:20:22 EST 2013


Many Thanks Kasper.

The current file for windows does not contain solutions for built-in 
features. Does someone know when these information are available in the 
solution registry at least for settings forground and background?
We need it for running our first rule and to return correct output to 
the flow manager.

Best regards,

Claudia

Am 12.02.2013 16:24, schrieb Kasper Galschiot Markus:
> Hi Claudia,
>
> Yeah, that's the correct file for the windows part of the solutions 
> registry - for the linux applications, see 
> https://github.com/GPII/universal/blob/master/testData/solutions/linux.json
>
> and yes, the invert 
> (https://github.com/GPII/universal/blob/master/testData/solutions/win32.json#L39-L51) 
> is the magnifiers colour inversion.
>
> ~Kasper
>
> PS: you can mark stuff on github like I did above, by clicking on the 
> line numbers to the left of the code. Shift click to mark a range :)
>
>
>
> On 2/11/13 12:48 PM, Claudia Loitsch wrote:
>>
>> Dear Kasper and all,
>>
>> Based on the example of the return payload below I wanted to define 
>> the output for the rule-based matchmaker. I looked for the current 
>> solution registry to find entries for windows and found the following 
>> file: 
>> https://github.com/GPII/universal/blob/master/testData/solutions/win32.json 
>>
>>
>> Did I found the correct path for the solution registry or is there 
>> another place in the GPII repository?
>>
>> Does the transformation specification “Invert” in the file above 
>> apply to the setting “Colourinversion” in windows magnifier?
>>
>> Many thanks in advance
>>
>> Claudia
>>
>>
>> Am 18.01.2013 14:27, schrieb Nick Kaklanis:
>>> Hello Kasper,
>>>
>>> Thank you very much for this!
>>> Now I have a clearer view regarding the output of the matchmakers.
>>>
>>> Best regards,
>>> Nick
>>> Nikolaos Kaklanis
>>> Information & Communication Systems Engineer, MSc, PhD candidate
>>> Research Associate - Informatics and Telematics Institute
>>> Centre for Research and Technology Hellas
>>> 6th Klm. Charilaou - Thermi Road
>>> P.O. BOX 60361 GR - 570 01
>>> Thessaloniki, Greece
>>> Tel.: +30-2311-257751
>>> Fax : +30-2310-474128
>>> E-mail :nkak at iti.gr
>>> On 17/1/2013 9:02 μμ, Kasper Galschiot Markus wrote:
>>>> Hey Nick,
>>>>
>>>> We didn't get to discuss output of the matchmakers much at the 
>>>> telco today, but as I mentioned in the call, I put a breakpoint at 
>>>> the matchmakers return and got an up to date example of a return 
>>>> payload.. This is for Carla:
>>>>
>>>> http://pastie.org/5710473
>>>>
>>>> From what I remember, this is basically the entries from the 
>>>> solution registries (only those solutions that should be launched), 
>>>> but with a new section in each settings handler block called 
>>>> "settings" with the values that should be set. So basically the 
>>>> system will, when receiving a payload like this, go through each of 
>>>> the solution entries, set the given settings and fire up the 
>>>> application.
>>>>
>>>> ~Kasper
>>>>
>>>> PS: I'm CC'ing the architecture list as this might be of common 
>>>> interest.. For everyone: the below discussion is mostly about 
>>>> transformations - only this top section refers to matchmaker 
>>>> related stuff
>>>>
>>>>
>>>> On 1/17/13 12:33 PM, Nick Kaklanis wrote:
>>>>> Hi Kasper,
>>>>>
>>>>> Thank you very much for your valuable comments!
>>>>> One thing that we have to discuss during the telco is the output 
>>>>> of the MatchMakers.
>>>>> Claudia has started writing up the rules (in natural language - in 
>>>>> a .doc file) and I've started to implement them in Jena and 
>>>>> integrate them in the RuleBasedMM. I can show you an example 
>>>>> during the telco. The bad thing is that current output of the 
>>>>> RuleBasedMM cannot be used by the FlowManager - it's just a string 
>>>>> containing the result of the matchmaking process. If we agree to 
>>>>> the output of the RuleBasedMM, then I could implement the 
>>>>> mechanism that will extract something that you can actually handle.
>>>>>
>>>>> Best regards,
>>>>> Nick
>>>>>
>>>>> On 17/1/2013 1:26 μμ, Kasper Galschiot Markus wrote:
>>>>>> Hi Nick,
>>>>>>
>>>>>> Comments inline
>>>>>>
>>>>>>
>>>>>> On 1/16/13 9:29 AM, Nick Kaklanis wrote:
>>>>>>> Hello Kasper,
>>>>>>>
>>>>>>> Now things are more clear to me! :)
>>>>>>> Thanks a lot!
>>>>>>>
>>>>>>> I have some comments (see below).
>>>>>>>
>>>>>>> On 16/1/2013 12:02 πμ, Nick Kaklanis wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> -------- Original Message --------
>>>>>>>> Subject: 	Re: CLOUD4All - Solutions Registry automatic creation
>>>>>>>> Date: 	Tue, 15 Jan 2013 18:20:45 +0100
>>>>>>>> From: 	Kasper Galschiot Markus <kasper at raisingthefloor.org>
>>>>>>>> Organization: 	Raising the Floor - International
>>>>>>>> To: 	Nick Kaklanis <nkak at iti.gr>
>>>>>>>> CC: 	Votis Konstantinos <kvotis at iti.gr>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Hi Nick,
>>>>>>>>
>>>>>>>> I'm so sorry for being so damn slow at replying!
>>>>>>>>
>>>>>>>> It's very exciting to see this work moving ahead - hooking up the
>>>>>>>> semantic framework with the unified listing/solution registry is really
>>>>>>>> gonna be a big step forward in the project.
>>>>>>>>
>>>>>>>> Anyway, the capabilitiesTransformations block you created looks good -
>>>>>>>> though there are some details you would have no way knowing about due to
>>>>>>>> the lack of documentation :) :
>>>>>>>> > "capabilitiesTransformations": {
>>>>>>>> >             "KeyEcho": "general_enableKeyEcho",
>>>>>>>> >             "SpeakTutorialMessages": "general_enableTutorialMessages",
>>>>>>>> >             "PunctuationVerbosity": "general_speechVerbosityLevel",
>>>>>>>> >             "SpeechRate": "profiles_default_voices_default_rate",
>>>>>>>> >             "ScreenReaderTTSEnabled": "general_enableSpeech",
>>>>>>>> >             "ScreenReaderBrailleOutput": "general_enableBraille",
>>>>>>>> >             "WordEcho": "general_enableEchoByWord"
>>>>>>>> >         }
>>>>>>>> >
>>>>>>>>
>>>>>>>> The setting that the application (ORCA) understands should go on the
>>>>>>>> left, the common term should go on the right. Also, and I need to
>>>>>>>> confirm this with Colin, but we should probably prefix the common terms
>>>>>>>> with"http://registry.gpii.net/common/"  - so for the KeyEcho, it would
>>>>>>>> look something like:
>>>>>>>>
>>>>>>>> "general_enableKeyEcho":"http://registry.gpii.net/common/KeyEcho"
>>>>>>>>
>>>>>>>> (as you can see, both the in the solution registry, the switch to flat
>>>>>>>> preferences is still in progress for the architecture team :) )
>>>>>>>>
>>>>>>>> So what you have above works for setting that translate 1:1 - so for
>>>>>>>> example, if the common term "KeyEcho" has the value range of true and
>>>>>>>> false, and ORCAs setting "general_enableKeyEcho" also can only be true
>>>>>>>> and false, then this will work... It gets more complicated if, say the
>>>>>>>> common term KeyEcho can be: "on" and "off" -- then we would need to use
>>>>>>>> a transformation, in this case mapping "on" to "true" and "off" to
>>>>>>>> "false"... Or the common term could even have: "on", "onModifier", "off"
>>>>>>>> as it's value range.
>>>>>>>
>>>>>>> Could you please give me this example in JSON?
>>>>>>>
>>>>>>
>>>>>> Sure.. So since this is a more complex relationship than 1:1, 
>>>>>> well need to use the transformer.. Based on: 
>>>>>> https://github.com/GPII/universal/blob/master/testData/solutions/linux.json#L24-L38, 
>>>>>> it would look something like the following:
>>>>>>
>>>>>> "capabilitiesTransformations": {
>>>>>>                     (...),
>>>>>>                     "general_enableKeyEcho": {
>>>>>>                         "expander": {
>>>>>>                             "type": 
>>>>>> "fluid.model.transform.valueMapper",
>>>>>>                             "inputPath": 
>>>>>> "http://registry.gpii.net/common/KeyEcho",
>>>>>>                             "options": {
>>>>>>                                 "true": {
>>>>>> "outputValue": "on"
>>>>>>                                 },
>>>>>>                                 "false": {
>>>>>> "outputValue": "off"
>>>>>>                                 }
>>>>>>                             }
>>>>>>                         }
>>>>>>                     }
>>>>>>                 }
>>>>>>
>>>>>>>> > Moreover, I saw that some "capabilitiesTransformations" sections (like
>>>>>>>> > the following) are not so easy to be generated automatically (I cannot
>>>>>>>> > exactly understand them):
>>>>>>>> >
>>>>>>>> > "capabilitiesTransformations": {
>>>>>>>> >           "text-scaling-factor": {
>>>>>>>> >             "expander": {
>>>>>>>> >               "type": "gpii.transformer.fontSizeToScale",
>>>>>>>> >               "inputPath": "display.screenEnhancement.fontSize",
>>>>>>>> >               "baseFontSize": 12
>>>>>>>> >             }
>>>>>>>> >           }
>>>>>>>> >         }
>>>>>>>> >
>>>>>>>> So in this case, what happens is that we have the 'common term'
>>>>>>>> "display.screenEnhancement.fontSize" (yeah, this should be
>>>>>>>> "http://registry.gpii.net/common/fontSize"  - as said we're still working
>>>>>>>> on the switch to the new prefs format). The value range for the common
>>>>>>>> term is the fontsize in points, whereas the application in question
>>>>>>>> needs it in factor (that is, "text-scaling-factor" has a value range of
>>>>>>>> factors, 1 meaning 12pt, 2 meaning 24 pt, 1.5 meaning 18pt, etc).. So
>>>>>>>> the transformation is given via the above code, via the type, inputPath
>>>>>>>> and some other parameter (baseFontSize for example) specific to the
>>>>>>>> transformation type.
>>>>>>>
>>>>>>> Now, I understand better how the transformer works in practice. 
>>>>>>> However, I think that I need to know all the "keywords" (naming 
>>>>>>> conventions) that you use (e.g. "expander", "inputPath", 
>>>>>>> "baseFontSize"). Can you give me the general structure in JSON 
>>>>>>> format or is there any page in the wiki where I could find more 
>>>>>>> details on this? I need to know, for instance, if "baseFontSize" 
>>>>>>> is a term of the "transformer language"...
>>>>>>>
>>>>>>
>>>>>> I'm not sure if these are described in a centralized place, but 
>>>>>> if they're not, we should probably create a page for them and 
>>>>>> start with the documentation.. I'll ask colin about it in a 
>>>>>> separate email.. There is a chance that all these will be in the 
>>>>>> registry - but in either case we'll need to document it.
>>>>>>
>>>>>>>> So basically, this also solves the mystery of what the transformer
>>>>>>>> is/does.. The only thing it does/can do, is to take entries like the
>>>>>>>> above, and translate whatever is specified in the common term (ie.
>>>>>>>> fontSize) to something the application understand, based on how the
>>>>>>>> setting is described in the capabilitiesTransformations block.
>>>>>>>>
>>>>>>>> Generally, it's up to the people creating the solution entry (usually
>>>>>>>> vendors) to provide how these mappings are to the GPII.. It would be
>>>>>>>> ideal if it was possible to enter this info (how the different terms
>>>>>>>> transform) into the semantic framework using the interface you've
>>>>>>>> developed - there is currently no way of entering this info but JSON.
>>>>>>>
>>>>>>> Now, I've added in the ontology the one-to-one mapping regarding 
>>>>>>> the names of terms (application specific settings-to-common 
>>>>>>> terms). I'll see if I could also include in the ontology details 
>>>>>>> regarding the transformation of values.
>>>>>>>
>>>>>>
>>>>>> Awesome - besides documentation, let us know if there is anything 
>>>>>> we can be helpful with.. For example if you notice some 
>>>>>> transformations that are required but not yet implemented, it's 
>>>>>> useful for us to know (obviously you cannot do this until you 
>>>>>> know which ones already exist :) ).. also if there are aspects of 
>>>>>> the transformer that would be useful for the rules based 
>>>>>> matchmaker, we'd be happy to talk about how to best make it 
>>>>>> avialable.
>>>>>>
>>>>>>>> Hope I didn't confuse you more than clearing things up :)
>>>>>>>>
>>>>>>>> Looking forward to talking with you in the MM/arch meeting thursday!
>>>>>>>
>>>>>>> I'm looking also forward to talking with you tomorrow!
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Nick
>>>>>>>
>>>>>>>> ~Kasper
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> > Can you please give me some explanations on this?
>>>>>>>> >
>>>>>>>> > Best regards,
>>>>>>>> > Nick
>>>>>>>> >
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> Kasper Galschiot Markus
>>>>>>>> Research Engineer,
>>>>>>>> Raising the Floor - International,
>>>>>>>> www.raisingthefloor.org
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -- 
>>>>>> Kasper Galschiot Markus
>>>>>> Research Engineer,
>>>>>> Raising the Floor - International,
>>>>>> www.raisingthefloor.org
>>>>>
>>>>
>>>> -- 
>>>> Kasper Galschiot Markus
>>>> Research Engineer,
>>>> Raising the Floor - International,
>>>> www.raisingthefloor.org
>>>
>>
>>
>> -- 
>> -------------------------------------
>> Dipl.-Medieninf. Claudia Loitsch
>>
>> Technische Universita"t Dresden
>> Institut fu"r Angewandte Informatik
>> Professur Mensch-Computer Interaktion
>>
>> Tel.: 0351/463 42025
>> Fax: 0351/463 38491
>>
>> E-Mail:claudia.loitsch at tu-dresden.de
>
> -- 
> Kasper Galschiot Markus
> Lead Research Engineer,
> Raising the Floor - International,
> www.raisingthefloor.org


-- 
-------------------------------------
Dipl.-Medieninf. Claudia Loitsch

Technische Universita"t Dresden
Institut fu"r Angewandte Informatik
Professur Mensch-Computer Interaktion

Tel.: 0351/463 42025
Fax: 0351/463 38491

E-Mail: claudia.loitsch at tu-dresden.de

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


More information about the Architecture mailing list