[Architecture] return payload from the matchmaker

Claudia Loitsch claudia.loitsch at tu-dresden.de
Mon Feb 11 06:48:47 EST 2013


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

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


More information about the Architecture mailing list