Architectural Notes About the Needs and Preferences Set Format

From wiki.gpii
Jump to: navigation, search

Decisions, Open Questions, Notes, and Ideas

Decisions

Preferences Sets consists of:

  • Preferences grouped by contexts and containing conditions
  • Policies which are cross-cutting assertions about preferences
    • Security policies
    • Provenance/origin (where did this preference come from? The Snapshotter? A discovery tool? Somewhere else?)
    • Do not ontologize (dont infer from this setting, only apply to this particular application)
    • Priority
    • Required
    • Launch on startup

Priority

An unbounded float range defining the relative importance of one application or context. If a user actively specifies a priority, this will take the value of 1024 or above. Anything below this means that the priority was inferred by the system

Required

Integer range, with fixed upper bound: 100, meaning system cannot be used without this being present/available


SUGGESTED EDITS TO FOLLOWING SECTION - TO MAKE IT CLEARER AND REFLECT OTHER DECISIONS AROUND THE REGISTRY TERMS

Granularity and Abstraction

Some preference terms are very specific, such as the font size of the OS menu bar. But we also allow for very general, user-oriented preferences (for example simpleKeyboard, simplifiedContent, everythingEnlarged).

The goal of having a registry of preference terms (and to identifying some as "common" terms) is to:

  1. Serve as a meeting point for adapting settings across different applications by
    • EITHER using terms and value ranges that are commonly used by other applications - to facilitate generalizability of settings across applications
    • OR providing transforms from other registered terms to the common terms -- so that different where different terms are used, they can be understood and (wherever possible) transformed in to forms needed by other applications
  2. Representing the user's needs and preferences in a vocabulary that suits them
  3. Allowing vendors to continue using their terminology - but have their terms be relateable to other terms in the registry

Different types of preference terms

Terms In the Registry

  1. Common terms, which represent user preferences that can be applied across a variety of applications, and that are intended to capture (to a greater or lesser extent) the intention and vocabulary of the user
    • Some common terms are particularly optimized for translation
    • Others are higher level and more abstract ("I need it to be easier to read")
  2. Aliases, which are terms that have the exact same definition and value space as a common term - but are different terms.
    • These are stored in the registry as a simple preference name and a pointer to the common term which they are an alias of (becauase their definition and value space are identical to the Common Term.   
  3. Application-specific terms, which have a defined schema registered in the registry -  and which represent a setting for a specific application
    • Application-specific terms may or may not have transforms defined for them that would allow their values to be transformed into values for common terms
  4. Application-unique terms, which are terms that can have no meaning outside of an application.   For example, "Toolbar #2's position on the last time the application was closed".
    • Application-unique terms may or may not be registered in the registry, but are never aliases because, by definition, they are of no use in another application.
    • If a term ever is applicable to other applications, it is by definition no longer an application unique term.
    • It is allowed for these terms to be registered, however there is a filter to easily filter them out of any listings viewed in the Registry, and it is not yet clear if there is any way to make use of this information across applications.  But the ARE useful when a person uses another computer and would like the new computer to look just like their last one did when using this application.
    • This type of information could also be easily transferred using an application-unique datablock stored in an application-unique term's value-space. 
  5. Context Terms,  Most preferences can also act as context terms as well.  i.e the fact that one preference is set can be a context for another preference set
  6. Operators, which are common terms used to create preference statements.  (e.g.    AND, OR, NOT, WHILE, IF etc) 

Preferences not in the Registry 

  1. Unregistered, opaque application-unique blocks, which consist of an arbitrary block of one or more settings that are passed directly to a settings handler without any modification (and usually without any understanding of them by the GPII infrastucture).

Commons terms are concatenated lowerCamelCase

Flat common terms will be non-categorized, non-ontologized and non-hierarchical within the Registry. They will be lowerCamelCase. E.g.:

  • "http://registry.gpii.net/common/pitch"
  • "http://registry.gpii.net/common/screenreaderUppercasePitch"
  • "http://registry.gpii.net/common/bodyTextFontSize"

We currently have a couple of ontologies (or views within an ontology) that were created by Cloud4all for viewing the terms.  These can be found in the Semantic Alignment Tool (SAT).  (see   ).  We expect other reseachers, developers, or projects in the future to propose other ontologies or modifications to the SAT ontology.  The Registry is designed to support as many different ontologies as anyone would like to create.


END OF SUGGESTED EDITS -- START OF ORIGINAL TEXT

Granularity and Abstraction

Some common terms are very specific, such as the font size of the OS menu bar. But we also allow for very general, user-oriented common terms (for example simpleKeyboard, simplifiedContent, everythingEnlarged). The goal of common terms is to:

  1. Serve as a meeting point for adapting settings across different applications
  2. Representing the user's needs and preferences in a vocabulary that suits them

Three types of preferences in a set:

  1. Common terms, which represent user preferences that can be applied across a variety of applications, and that are intended to capture (to a greater or lesser extent) the intention and vocabulary of the user
    • Some common terms are particularly optimized for translation
    • Others are higher level and more abstract ("I need it to be easier to read")
  2. Registered application-specific terms, which have a defined schema registered in a Preferences Dictionary, and which represent a setting for a specific application
  3. Unregistered, opaque application-specific blocks, which consist of an arbitrary block of one or more settings that are passed directly to a settings handler without any modification

Commons terms are concatenated camel-case

Flat common terms will be non-categorized, non-ontologized and non-hierarchical. They will be camel case. E.g.:

  • "http://registry.gpii.net/common/pitch"
  • "http://registry.gpii.net/common/screenreaderUppercasePitch"
  • "http://registry.gpii.net/common/bodyTextFontSize"


END OF ORIGINAL TEXT BEING EDITED

Open Questions and Ideas

Accumulation

Can preferences be accumulated? For example, if I have a base set of preferences and one for a specific context, when I'm in that context are both preferences applied (with those that match the context more closely overwriting)? See the Oedipus use case below for an example. This could be a user setting, which explicitly states that "this should be accumulative" or "start from scratch". This should probably be stored in the preference set itself, perhaps as a policy?

Metadata About Preferences

Where do we store Matchmaker (and other) metadata:

  • eg. I dont want to have solutions suggested to me, suggestions on specific things, request to postpone suggestion for later (dont talk for the next 3 hours)
  • Metadata relating to preference editors

The ST MM wants to store all the context at the time of snapshot, e.g. (Screen metrics, background noise, luminosity, time of day). Where should this context be stored? Should we just make MM specific blocks in policies or other metadata location?

Recording PCP usage to train the Matchmakers - where should that metadata go? i.e. the user always increases volume in the PCP, so perhaps it should suggest user a higher value - or be a nazi and actually provide without the consent of the user.

Should "policies" actually be renamed to "metadata"? It seems to be more that just policies.

Ontology Transforms: Where do we put contexts in the extended-24751 sets?: This applies in cases where the Ontology Server will transform (on request) a preference set from e.g. flat to the hierarchical extended ISO for use cases such as supporting ontology-aware Matchmakers such as the Canopy Matchmaker. All the policies need to be copied over as well as the context, at least if we plan to be able to take things like: security, priority, requirement, etc.

Use Cases

Homer

Has low vision so generally prefer an increased font-size (15) on his system. At night, his eyes get tired so he would REQUIRES an even further increased font size (18) after 18:00. [require vs prefer, simple context set]

Oedipus

Is quite techy and *requires* a screen reader (or some other needs of using a computer without vision). He has used the PMT to create an "at the movies" context (non-accumulative). When this context is applied the screen reader TTS should be turned of and braille/haptic feedback enabled instead. (accumulative vs. non-accumulative contexts/sets, expression of required preferences)

Minelaus

Has very specific settings for his screen reader. He generally uses the pitch to give him clues about the text - as he mainly uses JAWS, he has most of the settings specified in terms of that (eg. pitch for italics in JAWS, pitch for underlined in JAWS, pitch for capitalized and underlined text in JAWS). He has some general preferences specified as well (generic pitch setting, read speed, etc). He also has some settings specifically for NVDA, which he requires to be able to use NVDA as its speech engine is quite different from other screen readers. As the NVDA settings are not representative for how he wants a screen reader to act, these settings should NOT be used to infer other settings. (application specific settings)

Aphrodite

(Currently out of scope) She uses two switches, both connected by USB. One of them should trigger the click function, the other should trigger the cancel function. (Using 'instance' to describe the same preferences but for multiple hardware devices).

Persephone

She has detailed pitch settings, i.e: 0.3 for general, 0.5 for italics, 0.4 for underlined, 0.6 for capitalized, 0.2 for headings. She uses computers extensively and often wants to edit her settings in a preference editor. (Illustrating the need for 'light' contexts -- if this was to be illustrated in Colin's proposal, one would require 4 different contexts)

Triptolemus

His preferences has been generated by the statistical MM (or Snapshotter) and all kinds of extra context information has been recorded as part of the snapshotting process. Some settings have been tweaked via the PCP, which is recorded in the NP set. He has also modified some settings in the PMT, the source of the change has been recorded in the NP set. Furthermore, he generally likes exploring new things so he wants MM suggestions (MM metadata).

Example Preference Set Format We Discussed

 {
    "contexts": {
        "default-xyz234871": {
            "name": "Base set",
            "preferences": {
                "http://registry.gpii.net/common/screenreaderUnderlinePitch": 2000,
                "http://registry.gpii.net/application/com.freedomscientific.jaws/underlinePitch": 2000,
                "http://registry.gpii.net/application/com.freedomscientific.jaws": {
                    "cat": "meow",
                    "dog": "base65stuff"
                }
            }
        },
        "at-night-xyz238416387": {
            "name": "Nighttime set",
            "priority": 0.0005,
            "preferences": {
                "http://registry.gpii.net/common/menuBarFontSize": 14
            },
            "conditions": {
                "stuff-in-here": "..."
            }
        }
    },
    "policies": {
        "default-xyz234871.http://registry\\.gpii\\.net/common/screenreaderUnderlinePitch": {
            "required": true,
            "authorized-applications": [
                "com.facebook"
            ]
        }
    }
 }
 

Other Notes, Unfinished Sketches, and an Archive of Stuff We Thought About

  • Claudia points out the complexity of alignment when we have "atomic terms" since
    • the number of common terms will be significantly higher
    • if a vendor has the concept of "just pitch," they will have to find a particular common term that best aligns with it
  • Multiple instances of the same solution (out of scope for now): e.g. Two screens, Two Switches: While we want to be able to support this at some point in the furture, this is out of scope for cloud4all. Expressing eg. two 'clickAction's as common terms, since it is impossible impossible to have two versions of the same common term (ie: common/switchClickAction can only be present once as it is used as a key). We need to somehow be able to express something like: rightSwitchClickAction and leftSwitchClickAction, and generally specify a whole group of settings for each specific switch, each specific screen, or whatever it might be (how does the system know what switch a user is referring to, across different machines, etc)?
  • Common terms will never be in the context of an application. There is no reason why settings expressed in the context of an application is not just saved as application specific terms (How does this match up with the needs of preferences editors? It may be very complex for an editor to support an arbitrary, infinite space of application-specific settings, especially when some of them may not be registered)

Alternative Example Preference Set Ideas

preferences: { 
    context1: {
        context-name: "At Home",
        priority: 60
        preferences: {
           "http://registry.gpii.org/common/pitch : http://registry.gpii.org/common/screenreader": 12
        },
        conditions: {
            ...
        }
    },
    context2: {
        context-name: "At the cat",
        preferences: {
            //"registry.gpii.org/common/screenreaderUnderlinePitch" ->
            // screenreader: {
                   underline: {
                       pitch: 27
                       }
                }
             "http://registry.gpii.org/common/pitch": {
                "contexts": [
                     "http://registry.gpii.org/common/screenreader",
                     "http://registry.gpii.org/common/underline"
                ],
                value: 2000
              }
            },
            "https://registry.gpii.org/common/cat": 45
        ],
        conditions: { ... }
    }
}
policies: {
    context1.preferences.screenreader.pitch: {
        priority: 100,
        required: 100,
    },
    context1: {
        priority: 57
    }
}
            "http://registry.gpii.net/common/pitch": [ { value: 24, conditions: { text-style: "underlined" }}, {value: 34, context: }
 {
    "Nighttime At Home": {
        "preferences": {
            "http://registry.gpii.net/common/(<context>/)*fontSize": 24,
            "http://registry.gpii.net/common/pitch": 32,
            "http://registry.gpii.net/common/switch/instance1/switchFunction": "scan"
            "http://registry.gpii.net/common/switch/instance1/switchPort": "com3"
            "http://registry.gpii.net/common/jaws-instance4/switch-instance2/switchFunction": "scan"
"http://registry.gpii.net/common/switch/switchPort": [
    instance1: ....
    instance2:  ...
]
            "http://registry.gpii.net/common/switch/instance2/switchFunction": "click"
            "http://registry.gpii.net/common/keyboard/instance1/key": "a"
            "http://registry.gpii.net/common/keyboard/instance1/favoriteKey": "∑"
            "http://registry.gpii.net/pointerControl///nstance1/switchPort": "com3""
            "http://registry.gpii.net/swich/automatedScanning/instance1/switchPort": "com3"
        },
    
        // Implicit AND
        "conditions": [
            {
                "http://registry.gpii.net/conditions/timeOfDay": {
                "range": {
                    "start": 1730,
                    "end": 730
                }
            },
            {
                "http://registry.gpii.net/conditions/location": {
                    "gps": {
                        "lat": "79.3N",
                        "long": "74.9W"
                    },
                    "range": "200m"
                }
             },
             OR 
             {
               "http://registry.gpii.net/conditions/application": {
                    "id": "com.freedomscientific.jaws"
                }
            }
        ]
        "priority": 100
    },
    "com.freedomscientific.jaws": {
        "preferences": {
            "http://registry.gpii.net/common/fontsize": [{
                "value": 19
            }]
        },
    
        // Implicit AND
        "conditions": [
            {
                "http://registry.gpii.net/conditions/application": {
                "id": "com.freedomscientific.jaws"
            }
        ]
        "priority": 100
    },
    "com.freedomscientific.jaws": {
        "preferences": {
            "http://registry.gpii.net/common/fontsize": [{
                "value": 19
            }]
        },
    
        // Implicit AND
        "conditions": [
            {
                "http://registry.gpii.net/conditions/application": {
                "id": "com.freedomscientific.jaws"
            }
        ]
{
    "contexts": {
        "default-xyz234871": {
            "name": "Base set",
            "preferences": {
                "http://registry.gpii.net/common/screenreaderUnderlinePitch": 2000,
                "http://registry.gpii.net/application/com.freedomscientific.jaws/underlinePitch": 2000,
                "http://registry.gpii.net/application/com.freedomscientific.jaws": {
                    "cat": "meow",
                    "dog": "base65stuff"
                }
            }
        },
        "at-night-xyz238416387": {
            "name": "Nighttime set",
            "priority": 0.0005,
            "preferences": {
                "http://registry.gpii.net/common/menuBarFontSize": 14
            },
            "conditions": {
                "stuff-in-here": "..."
            }
        }
    },
    "policies": {
        "default-xyz234871.http://registry\\.gpii\\.net/common/screenreaderUnderlinePitch": {
            "required": true,
            "authorized-applications": [
                "com.facebook"
            ]
        }
    }
}
 

Two types of contexts:

Environmental context:

  • time of day, light, noise

Ontological context:

  • Application type (e.g. screen reader)
  • Product (e.g. Jaws)
  • Link
  • To allow us to distinguish between multiple instances of the same application/solution, we have special contexts: instance1, instance2, ...