Changes between Version 79 and Version 80 of currentDesign


Ignore:
Timestamp:
12/14/17 23:48:56 (2 years ago)
Author:
Garth Braithwaite
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • currentDesign

    v79 v80  
    104104
    105105=== Peer Groups ===
     106- Currently thought to use the ANCILLARY VALUE mechanism within a demographic type indicator.
    106107- Peer groups allow a user to find and compare various indicators for a given community/group.
    107108- Peer groupings associate a general indicator range rank value to a dimension (that has the COMMUNITY_FLAG set).  This allows a user to see any and all dimensions (dimension values) that have the same “peer group value” for a given indicator(s).  This provides the foundation for doing data discovery “what ifs” e.g. I want to see any dimension values (communities) that have the same IP peer group rankings (income, birth rate, and education level) as my dimension of interest (Grand County).  Once that set of peers is defined a user could choose a set of indicators to report on to build their own report.  That definition could then be saved and shared much like a user can do with a query definition.
    108 - Will be implemented as needed via the ANCILLARY VALUE mechanism.
    109109- Here's a few basic demographic examples (with the associated dimension):
    1101101. PERSONAL INCOME: age, geo, race, eth, edu
     
    125125
    126126=== Rankings ===
    127 - '''NEEDS ATTENTION - using the ANCILLARY VALUE???'''
     127- Currently thought to use the ANCILLARY VALUE mechanism.
    128128- Rankings are like peer groups but can be different based on the usage context (think state or US high/low/same).
    129129- It was first thought to put a simple “RANK” field in the dataset values structure.  This would allow adopters to establish basic ranking values.  It also provide a second type of specialized measure that can be used for either peer groupings or HLS ratings etc. without having to implement a truly dynamic multi measure/multi peer group solution.  The dataset definition would have included ranking definition text field to provide the actual usage definition.
     
    140140- Demographics are indicator/dataset based - just like any other indicator profile.  This allows demographic data to be graphed, trended, and have contextual/metadata text.
    141141- Demographic indicators will set a DEMOGRAPHIC_FLAG to make it easy to identify those types of datasets.
    142 - The VALUE_TYPE will be $, count, etc. 
    143142- The dataset's ancillary "RANK" value field can be used identify peer communities.  Implementing a general RANK field has an issue of what is it – High/low/same, peer group ranking, relative to state?, relative to US?  relative to a specific group?  *** Maybe need to have the dataset definition include a RANK_DEFINITION field?  What about those instances where you want both – HLS RANK and PEER GROUP?  This is a future enhancement that can be added later if funding. 
    144143- At some point could implement a user defined search for all demographic indicators that are peers with x,y, and z.  Then a community profile report could be built for a set of indicators for that group of peer demographic areas. 
     
    164163=== Community Profile ===
    165164- Community Profile Snapshot and Highlight reports are IP, and IP dataset based.  They both rely heavily on IP context fields and may use IPV context fields if needed.
    166 - New IP target values and other related community values can be used for the comparison.  Could have the user specify.  Could have user build their own report and save definition and share - like saved query.
     165- New IP target values and other related community values can be used for the comparison at some future point.  Could have the user specify.  Could have user build their own report and save definition and share - like saved query.
    167166- The index pages will likely remain as is – possibly refactored to clean up.
    168167