[Architecture] return payload from the matchmaker

Kasper Galschiot Markus kasper at raisingthefloor.org
Tue Feb 12 10:24:49 EST 2013


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

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


More information about the Architecture mailing list