Difference between revisions of "Architecture of Preferences and Data"

From wiki.gpii
Jump to: navigation, search
m (category added)
Line 1: Line 1:
{{note|This page is out of date, and has been superceded by [[A Detailed Tour of the Cloud4All Architecture]]|gotcha}}
== Overview ==
== Overview ==

Revision as of 21:08, 13 August 2015



The GPII Personalization Framework takes a powerful and forward-looking approach to data modelling and interoperability. Our goal is to enable developers to represent data, such as user preferences, in whatever formats and structures best fit their needs and implementation constraints. This "minimising the costs of disagreement" approach emphasizes the inherent mutability of simple data structures (such as those represented in JSON), allowing the GPII Personalization Framework to easily adapt and transform data structures as needed in order to interoperate with others. Using as its basis the Model Transformation library that was developed for Fluid's Infusion application framework and similar projects such as Boomerang, the GPII development team will provide implementers with the tools necessary to use their preferred formats and structures while still retaining interoperability and compatibility with others.

The Preferences Server

The GPII Preferences Server is designed with a RESTful approach. REST, which stands for Representational State Transfer, is not new or obscure; it's the architecture of the Web. In the RESTful approach, Web services are modeled as series of Resources, each with its own unique URL. Resources represent the content of a Web service, and are distinct from the many Representations, or formats that those Resources can be presented in.

In the case of the GPII Preferences Server, the primary Resource in the architecture is the user and their preferences. These will be identified by a URL such as:

http://preferences.gpii.net/users/<anonymous user token>/preferences

The Preferences Server will support multiple Representations of a user's preferences, corresponding to particular formats and structures that are optimized for distinct use cases and implementations. While the server will indeed provide a standardized JSON Representation, consisting of the preferences mapped as flat key-value pairs that correspond to the AccessForAll preferences registry, other formats will also be provided and used. For example, a more terse and hierarchical JSON structure suitable for the high-performance processing and interchange requirements of the GPII Personalization Framework. One can even imagine HTML Representations of the user's preferences, enabling them to review the preferences they've set and edit them accordingly.

Flat, URL-keyed Preferences Profile in JSON Format

    "http://registry.gpii.net/common/language": [
            "value": "fr-ca"
    "http://registry.gpii.net/common/speechRate": [
            "value": 100
    "http://registry.gpii.net/common/repeatKeysRepeatRate": [
            "value": 0.5
    "http://registry.gpii.net/comon/repeatKeysAutomaticDelay": [
            "value": true

Hierarchical Preferences Profile in JSON Format Conforming to the Current ISO 24751 Standard

    user: {
        language: "fr-ca"

    display: {
        screenReader: {
            speechRate: 100

    control: {
        alternativeKeyboard: {
            repeatKeys: {
                repeatRate: 0.5
                automaticDelay: true

In each case where the the Preferences Server exposes a particular data Representation (in JSON format), there will also be an accompanying "schema" or map, describing how data structure corresponds to the underlying AccessForAll preferences registry. This will ensure that multiple formats can coexist harmoniously; each Representation will be self-describing, ensuring that implementations can easily understand the format and its meaning. Here's an example:

    "user.language": "http://registry.gpii.net/common/language",
    "display.screenReader.speechRate": "http://registry.gpii.net/common/speechRate",
    "control.alternativeKeyboard.repeatKeys.repeatRate": "http://registry.gpii.net/common/repeatKeysRepeatRate"
    "control.alternativeKeyboard.repeatKeys.automaticDelay": "http://registry.gpii.net/common/repeatKeysAutomaticDelay"

In this example, keys within the hierarchical structure (separated by dots) are mapped to their corresponding AccessForAll Registry entries via their unique URI. Any application built in a Registry-aware way would be able to understand the meaning of this preferences profile, regardless of its particular structure.

In this way, the GPII Preferences Server takes advantage of RESTful principles and self-describing Resources to ensure that we can widely interoperate, supporting the diverse needs and requirements of implementers.

The Role of JSON

JSON plays an important role within the GPII architecture. While we're committed to interoperating with other formats as needed, JSON provides several key advantages over competing formats such as XML. In particular, it maps directly to the core data structures supported by any programming language, device, and operating system. Its structure corresponds with the basic data types every programming is familiar with (such as numbers, strings, arrays, and dictionaries). Robust JSON parsers exist for just about every programming language and operating system known. The cost of parsing JSON is extremely low, both in terms of performance and code complexity; this makes it particularly well suited to use with mobile and embedded devices.

While JSON may initial seem to lack the features of a more complex format such as XML, those features are typically easily represented within JSON, and--when needed--support for things such as schemas is well-established. A solid proposal for JSON schema is on the standardisation track at the IETF - but should this require enhancement for the GPII, JSON schema systems in JSON are for the reasons listed above considerably easier to produce than XML schemas in XML. For developers, supporting JSON comes at a fraction of the complexity of XML.

Most importantly in the context of the GPII architecture, JSON's correspondence with the fundamental data types of computation mean that it can be easily traversed, understood and transformed. Unlike XML/XSLT, it's easy to write code and declarative rules to adapt, transform, and restructure data represented in JSON.

For these reasons, the GPII Personalization Framework will leverage JSON extensively throughout the core system, binding to other data formats whenever needed in order to support legacy applications and broad interoperability with code that may not have been designed with the GPII in mind.

Brokering Between Preferences Representations - the Ontology Server

The ease of producing JSON schematic structures represented in JSON itself makes it economic and desirable to produce a dedicated piece of architecture for managing this process. We describe each of the JSON formats in which user preferences documents can be served as being derived from an ontology - a schema describing the layout and meaning of the terms appearing in the format. Use of the Model Transformation Library referred to in the introduction makes it easy to provide an open infrastructure for ontologies - users can define and register new ontologies without writing programming language code.

The two formats we have described above, the standard "Flat, URL-keyed Preferences Profile" as well as the "Format Conforming to the Current ISO 24751 Standard" both constitute ontologies in our terminology - even though the first format conveys no ontological information beyond the names of keys. Further ontologies may easily be added to the system by integrators, AT vendors and other stakeholders simply by defining a transformation document in the format accepted by the model transformation system, which translates their ontology into one of the two standard ones. As long as there exists a path linked by transformations between any one ontology and another, the system can broker between preferences stored in the two formats automatically, ultimately for writing as well as for reading. Here is a sample document defining a transformation between the standard registry format and a part of the ISO 24751-2 schema (the hierarchy under "display.screenEnhancement") described above:

    "transformations": {
        "display.screenEnhancement.fontSize": "{http://registry.gpii.org/common/fontSize}.0.value",
        "display.screenEnhancement.foregroundColor": "{http://registry.gpii.org/common/foregroundColor}.0.value",
        "display.screenEnhancement.backgroundColor": "{http://registry.gpii.org/common/backgroundColor}.0.value",
        "display.screenEnhancement.fontFaceFontName": "{http://registry.gpii.org/common/fontFaceFontName}.0.value",
        "display.screenEnhancement.fontFaceGenericFontFace": "{http://registry.gpii.org/common/fontFaceGenericFontFace}.0.value",
        "display.screenEnhancement.magnification": "{http://registry.gpii.org/common/magnification}.0.value",
        "display.screenEnhancement.tracking": "{http://registry.gpii.org/common/tracking}.0.value",
        "display.screenEnhancement.invertImages": "{http://registry.gpii.org/common/invertImages}.0.value",
        "": {
            "expander": {
                "type": "gpii.ontologyServer.transform.application",
                "inputPath": "",
                "outputPath": "applications"

(note that this transformation format is not final and will evolve over the next few releases of the GPII system, in particular to eliminate the indirection ".0.value" appearing on the right hand side of rules)

Architecture, Implementation, and Standards

Effective, easy to use standards are always driven and informed by working implementations. When it comes to personalization standards, the GPII Personalization Framework is being designed and architected to serve as a strong and viable implementation from which standardization decisions can be made.

Here are some of the key considerations for proposing a new feature or standard:

  • What is the use case, why do users need it, and what impact will the proposal have on them?
  • What are the particular strengths and weakness of the proposal in regards to implementation, such as:
    • How difficult will it be to implement?
    • What techniques, algorithms, and data structures will implementers needs to use?
    • What performance characteristics will the proposal have?
    • What semantics or technologies does the proposal commit us to that might form a fragile point in the future?
  • Are there existing implementations that provide this feature? How do they work?
  • What alternative proposals might fit this same use case?

In the case of new formats, query languages, or Domain Specific Languages (DSLs), a proposal should be accompanied by:

  • A working parser reference implementation that covers the full extent of the proposal's grammar, syntax, and semantics
  • A comparison of existing implementations and parsers