Emergency Management RIM SC Meeting Notes

01/17/2017

Attendees:

Rex Brooks

Jeff Waters

Emergency Management Reference Information Model Subcommittee Report/Discussion

We had a quorum, and approved the meeting notes from 01-17-2016 as amended.

We continued our discussion of the points in the emailS Rex sent out Jan 2, 2017 and January 30 about a possible EDXL Framework-Toolkit to help developers implement our specifications. Please note that we are keeping an ongoing record of our discussions in the bulleted outline that follows, adding dates to track our discussions.

·  What would it look like (features wish list)? We suggested

o  JSON and/or JSON-LD versions of our specifications and/or profiles of our specifications linking data objects across web-based application. This because they’re currently popular

§  (1-17-2017) We want users to adopt our standards so the standards must be flexible enough to represent standardized emergency information-in machine and human-readable form.

§  (1-17-2017) Rex asked if Jeff had reviewed the sample JSON conversion he sent in an email to Jeff. Jeff did note that and explained how those JSON files can be converted easily as JSON-LD. Jeff said he could provide an example that Rex can use as a model for other EDXL specifications.

§  (1-31-2017) Jeff continued discussion of his email to Rex 1-22-2017: He noted that the example he provided in which he noted that the way he converted a CAP alert message from xml to JSON-LD and we discussed it in some depth. Rex said that he understood the explanation.

§  (1-31-2017) There are two main efforts that we are moving forward with: Jeff is investigating the particulars if the Google CAP validator/protocol buffer wherein CAP data is converted to a binary format that can be output to several different formats, such as XML or JSON; and Rex is looking at ways to produce the flat list of JSON key-values from Jeff’s email example in JSON from our hierarchical EDXL XML Schema.

o  Libraries for Microservices?

§  (1-17-2017) Jeff noted that he was attracted to the CAP Validator https://cap-validator.appspot.com/ by Google, which puts values in a table with a geographic map that references a CAP library that can read in a CAP message and translate it into JSON using a small protocol buffer. He said that they use a binary format with instructions to developers on how to use that, so if we had the same sort of binary library similar to the CAP Validator which uses Google’s protocol buffer to enable reading and writing CAP messages for our EDXL standards, it would be a big help.

o  What information/Microservices?/features do developers need to know about and use for their new Apps?

o  Can we make our emergency-based information usable in an everyday context and what can we do to provide this

o  Relational Database schemas

o  Look at innovation in the open source arena for a model for grass roots adoption

o  Think about working with Gary on an IPAWS model.

·  What would developers actually use? (If we build it, will they come?)

·  What can we actually produce? (Libraries, Profiles, Reference Implementations, Database Schema, etc).

·  Can we find a host for persisting any framework-toolkit components we produce?

·  This is all in addition to the work we need to do to identify and communicate with as many stakeholder groups we can.

There being no further business, the meeting was adjourned.

Respectfully Submitted,

Rex Brooks