Re: composability/distinctions, substitution/degradation/views, levels of integration/translation [was] Re: 2 types of NIEM models more follow up to meeting discussion

Ultimately it's an audience issue.  This is a final report of a W3 group and it is intended to serve to define a mandate for another W3 group.  It is accordingly totally unnecessary to wax eloquent about the W3's patent and royalty-free policy, explain the benefits of free software or open content, or catalogue the various ways pre-Web-2.0 systems tended to fail.

Literally everyone who would ever read anything in or around W3 already knows all of that.  So adding a few "bullet points" to a poorly targetted outline will simply lose them.

The structure should actually outline the difficult problems that need to be solved.  I listed three of those, based in part on issues Gary raised.

Surely there are more?

The list of issues becomes the structure of the report, which is a requirements analysis, problem statement for the standard (not the entire field of ER/EM).  Since any complex engineering project probably can have no more than three major design goals, and the other goals diminish to the degree the first three are pursued, probably there's a need to outline them and stick to that as the outline of the "final report".  Any backgrounders on free software or W3 policy or problems encountered in specific disasters or types of disasters should be in appendices.  So the final report has a structure that looks something like:

= abstract

= introduction - why the standard is needed

= critical / central goals the final standard must address
== embody an internally consistent ontology of very few consistent terms
   that are suitable for use exactly as is in user interfaces and schemas
== track all assets used in emergency and resilience consistently from the
   pre-emergency planning and resilience phases to the eventual handoff of
   responsibilities to local authorities, without prejudice as to 
== track new assets including volunteer or opportunistic/ad-hoc resources,
   accepting them readily into the same schema as institutional resources
== treat victims as potential volunteers, avoiding characterizing persons
   in any way that prevents them from participating in their own recovery
== embody a robust ontology that correctly differentiates types of assets:
   individual persons (whatever their role), social relationships (of which
   fulltime staff relationships are one - and should be explicitly modelled
   as a form of social relationship between persons), instructions and all
   explicit communications (factual, corrective, medical, or whatever kind)
   plus non-human financial, infrastructural/equipment and natural capital.
== support a test suite that will reliably test compliance and report what
   level of compatibility a given system has achieved, with what "issues"

= issues not resolved (==) and positions on how to resolve them (===)
== composability/distinctions
=== rely on international standards relevant to geospatial/time information
== substitution/degradation/views
=== degrade gracefully under pressure and partial information, allowing the
   minimal implementations to defer to maximal implementations dynamically,
   so that even severe problems with data consistency become simple delays
   until accurate data can be verified using a more elaborate human process
== levels of integration/translation/compliance
=== be implementable in its minimal form on extremely low cost mobile
    devices, and available as a free software reference implementation
=== in its ordinary form, be implementable on high-end robust mobile
    devices, and as a variety of services supported by commercial parties,
    all of which cooperate using a common open set of data standards
=== in its maximal form, coordinate and translate between legacy and other
    incompatible systems, acting as a central clearinghouse for all other
    implementations and permitting them to more easily cooperate as peers

= other constraints that systems built on the final standard must satisfy
== support international human rights standards including privacy and anti-
   discrimination standards, in particular explicit protection of women in
   vulnerable situations;  this may require anonymizing or aggregating data
== integrate well with other W3, IETF, IEEE standards using common terms
== royalty-free status with obligation to re-integrate improvements ("share
   alike", "open content", "free software") for benefit of all other users
   and beneficiaries

Received on Thursday, 9 April 2009 02:42:49 UTC