Neal GThe data dictionary/table name descriptions from patentsview.org could use some clarification. With an update on the data dictionary, it would be possible to generate the back-end data required by the leaflet visualization front end we produced.
The front end layout (using mock data) is shown below:
Several networking conversations with a census representative regarding data and outreach methodologies
Identified a number of indicators from a few conciliatory sources regarding business indicators, job availability, demand v. supply mismatches, cost of living indexes, unemployment and underemployment, commute times, et cetera
Identified basic quality of life needs that can be intercommunicated within any given node-based community that may encourage community members to support one another in a way that bolsters the optimism within said community, especially in times of economy anemia such as today.
Still plenty more to do; today mostly resulting in some exploration and direction rather than a demonstrable product.
James MWe worked on a tool to assess how timely the new Metro Way bus rapid transit service by comparing WMATA's "Next Bus" arrival times with WMATA's schedule for the buses. The major bottleneck with data collection via WMATA's API is the rate limit (10 calls/second), which means we can only query 10 bus stops (for arrival times) per second. Our strategy was to limit our calls to 2~3 per second but to poll constantly. Then we compare the arrival times with the scheduled arrival times (also pulled from the API).
Relate this data! Have a data set (say playgrounds) and tangible (i.e. printed out) icons like big database icons in yellow, and arrows and fields and tables.. Put some easy to follow tutorial on what all those icons mean in Database Managent Systems and let the beginnners construct their own “schema.”
Maybe an advanced exercise would be to then see how the data currently exists - both in the Alexandria plays dataset, and how it is presented in the real world.