CTR Next Steps Notes

From wiki.gpii
Jump to: navigation, search
On May 7, 2014, at 9:40 AM, Kasper Markus <kasper@raisingthefloor.org> wrote:

Hi Everyone,

I'd like to call for a planning meeting regarding the common terms work in C4A (doodle poll here: 
http://doodle.com/9i7wpi3bgndgvf3t). We have the upcoming meeting in Crete (mid-june), and some scarily close deadlines for the SP3 implementations, and one of the things that is preventing a lot of the further efforts for the SP3 implementers is a stable (approved?) common terms vocabulary they can refer to when considering transformations.

The ISO working group will be doing the selection of 'approved terms' and define the last details of the standard at some point, but given our timeframe in C4A I think it's risky (read: unrealistic) to wait for that. So I suggest we call a meeting to:
  • Determine a process for selecting a base set the common terms used in the context of C4A
GV:  This is key and I would suggest we get right on this.
  • Decide on a means to make these terms available for SP3 implementers to browse and refer to
    • Either via a spreadsheet or (preferably) via the Common Terms Registry
</blockquoteGV: I don’t see any obstacle to having it be the Common Terms Registry.   In fact it would be good that it were - and work best all round.</div>
    • Decide a short term roadmap for getting from where we are now to a point where:
    • #1  We have a limited set of common terms that the SP3 implementers should worry about
    • #2  We have a process for evaluating new suggestions for common terms
    • #3  We have a place where all of us can go to and see information about each common term and the list of C4A relevant terms


  1. 1  (which terms are important) will be the key starting point.   I am guessing that the testing and matchmaking teams (including the transformer team) will be the best ones to look to for this. 

#2  The process I would recommend we start with is
  1. the NOMINATED terms are identified by TESTING+MATCHMAKING team members (nominating any new terms they feel needed)
    • The terms are not just settings. They also include the operators, contexts and other terms used to make up a preference statement.
  2. INDIVIDUALS then go through them and fill out the DEFINITIONS  and if possible THE VALUE RANGES
  3. INDIVIDUALS then go through the definitions and value ranges and MAKE EDITS OR SUGGESTION    *IN BRACKETS*
  4. The TRANSFORM team go through and find any TRANSFORM ALIASES and propose the  FORWARD and BACKWARD  TRANSFORMS
    • This will require that we select a value transformation language to be used at least temporarily - and if we are lucky and it tests out - long term.
  5. The group meets to
    • Review/edit the definitions and value ranges and DECIDE on value ranges
    • Review terms and select a canonical form (a STANDARD term) for each concept (and make the rest aliases or transform aliases
    • APPROVE the terms needed so that they become CANDIDATE TERMS  (only awaiting the final approval to become TERMS)
    • (If we have enough 24751 participation we might be able to approve final STANDARD terms — but this takes time and doesn’t occur in a single meeting.
      • we SHOULD be able to create approved terms though (just not pick the STANDARD terms).
    • NOTE:  Once terms are approved - they are frozen (since they may be relied upon by others) — even if they are not the STANDARD terms.  So we may want to stop at candidate terms for now. 

#3 is easy.  the Common Terms Registry can already be used for this — and is the right place for the viewing and editing etc to take place.   the NOTES field can hold all the working comments and question we have as we work on each term.

A couple things to think about quickly and do

  1. Pick a transformation language
  2.  Decide on the granularity of the terms
    1. for the pitch of the voice for uppercase words do we have a single term uppercasePitch  or do we define pitch and uppercase as separate terms because there can be an infinite number of different pitch settings or conditions under which the pitch would be changed. Or do we combine the two and have both pitch and uppercase as separate terms AND as a combined term pitchUppercase and/or uppercasePitch when we think some term would be a common combination.   
  3. Decide on Alias/transform mechanism that can handle compounding  (where we have to terms that are sometimes combined by a company into one compound term. (  e.g.   readability — which changes fontSizecontrast, and font)

A couple decisions I THINK that have already been made:
  1. STANDARD terms will be  lowerCamelCase  
  2. Which fields are in Standard and which not (though this really doesn’t effect our work — and is more of a 24751 question )

I realize that this sounds like duplication of the ISO committee work, which it might be to some extend, but we need this sooner rather than later, and what we create here might serve as a good starting point for the committee.

GV: Don’t see it as any duplication, but a facilitation.   Their main goal is the creation of the standard and processes for maintaining the Registry.  Having some experience will help greatly.    There needs to be a seed to grow from anyway - so this can be it.   I am pretty sure some 24751 members can join the effort - and it will be quite helpful to their work. 

GV: Thoughts on this or other anyone?