| 18 | | === Scenarios (use cases) === |
| 19 | | * value click |
| 20 | | * build on their previous code-fest experience |
| 21 | | * combine with the alert advertising consortium |
| 22 | | * Google pubsubhub test - talk to Steve and Nigel to help set up a test base, consider bogus alerts linking through rss/atom ??? |
| 23 | | * high wind event setting - window sellers want to warn of sever wind alert to their clients, some coding with adding a <param> to an existing CAP temple |
| 24 | | * pictographs - towards a '''Sahana Pictographs database''' |
| 25 | | * is essentially a thesaurus (not an Ontology???) |
| 26 | | * consider for broader and narrower casting ('''Eliot - pls elaborate''') |
| 27 | | * take advantage of caching |
| 28 | | * use RESTfull call for receiving the "pictograph" object with images, sound, and text (e.g. action oriented words, what fonts and what languages to use: UN 5 main languages?) |
| | 18 | === Suggestions of Coding Needs === |
| | 19 | * Google AlertHub Testing facility - Need to allow test-only use of the AlertHub for implementors of CAP feeds and during alerting exercises (talk to Steve Hakusa about this) |
| | 20 | * Notice of Direction facility - Need to allow posting of notice of works-in-progress for use by implementors, such as harmonizing CAP parameter values, promoting particular best practices for CAP feeds, etc. These are intended for efforts that are less formal than profiling, although some may progress to that over time |
| | 21 | * Symbol Sets facility - Need to have a source of well-known sets of symbols (pictographs) relevant to alerting. This might be organized simply as a thesaurus (entries related to each other by "broader", "narrower" and "alias for" relationships), with a simple network service for fast access to symbols |
