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

Paola, Gary,

As the final report is taking shape we need to shape it as less of report of what is and more of a report on what the most difficult problems are.

I agree that not enough attention has been paid to composability, views or sets of use cases that represent the views of particular professions and responsible authorities, and to the levels of interoperability desired or specified.  Here's some initial thoughts on this.  Huge topics but working out how to approach them would be the primary mandate of ongoing W3 effort.

The report should state W3's intent to integrate with economic & logistical
(and medical and socio-economic) systems we know the target group will use, to design gracefully-degrading communications between compliant systems and
to define compliance in such a way that failed communications can easily be
restored and facilitated by an authority taking translation responsibility.

These are all pretty important goals to achieve resilience in emergencies.

The rest of what I have to say is detail, but if you agree, here are some of the elements that probably have to work their way into the report or an appendix.  I don't want to proceed to add such stuff without a consensus, so some feedback on what follows would help cut it back to what's needed.

=== Framing the report: "What moves and why?  And what stops it?" ===

There's probably too much framing on the current proposed draft outline.
Very structural, institutional.  I'd like to re-organize this framing to address Gary's issues more directly, and the psychology of each role/view.

"The EM and Disaster Management ecosystem" is a very poor name (the word "ecosystem" needs to be reserved for actual living evolved ecosystems or else you are giving up on ever representing these properly at all), I'd
rather see it called "Resilience actors, their capacities and priorities."

The "stakeholders, systems, professional communities, industry" do need to be enumerated but this doesn't get us closer to operational understanding of what really moves resources, volunteers, or victims to help themselves.

I don't think anyone needs a list of reasons why responders must cooperate.
The "background to the creation of the EIIF XG" should be a list of reasons
why they don't, and how to address those.  The "royalty free policy" for instance is important precisely because it removes barriers to cooperation.

=== composability and cooperation with non-compliant systems ===

I don't know how one truly achieves what Gary calls 
> composability of the underlying conceptual models.
  
However, it's a fair bet that "composability" implies mathematical/logical
coherence.  If you want two models to mesh with each other they had better
make compatible ontological distinctions.  In the ER field they'd better be 
very operational distinctions.  That is, we require tests to determine what
is excluded from each category (see "falsificationism" for why this tends to be more effective at making the definition than knowing what to try to include).  We've been edging around it but eventually one has to commit to a particular set of such distinctions, and a particular list of exclusions and scope definition.

So one thing lacking in the draft "final report" is a clear statement of which distinctions would be inherited from economic models or logistical or medical or social/economic development models.  If we aren't relying on at least a few core abstractions shared with those, we lose "composability".

==== what's out of scope ? ====

And what would certainly *not* be in the scope tackled by the eventual W3 standard.  Someone else can comment on medical or social data compatibility
but clearly we have some well-defined needs to share some types of data at least with those who are contributing resources and demand accountability, and with those who are actually in the field and accepting "our" directions
(that is, directions that the standard passes through to do certain things such as go to a certain place or gather certain data or help some person).

==== interoperability examples: capital assets & transport itineraries ====

The argument to include a capital asset model or a generic model of routes or paths taken or planned by a vehicle or shipment is that there will be away to integrate that with any spreadsheet or logistical planning system.  No economic model fails to make capital asset type distinctions and there is no logistics or transport planning system that doesn't have some concept of route or path in spacetime.  So I make a case to include both of these as it appears possible to create robust generic operational definitions any other model could adopt, or at least adapt to its own idiosyncratic model.

Why am I so sure?  Because these models can be made strictly operational - relying on non-controversial tests.  It's not controversial that a bridge is infrastructural/manufactured and so is a truck.  It's not controversial that a living human person is not the same type of thing as an instruction
manual, even though in some cases you can substitute one for the other.  It
is not controversial that money is a different type of thing than socially maintained trust, though again you can sometimes substitute one for the other.  Enabling and proposing substitutions is what makes us "resilient"
as opposed to "fragile".  So I can't see a way forward without such maps.

Domain experts such as Doctors Without Borders logisticians would be the people I'd like to consult on this.  They do this substitution every day.

=== combining use cases into views ===

Listing use cases is critical, but those use cases each come from a view or perspective on the information.  An economic perspective for instance might
be immediate (maximizing the lives saved for the resources now at hand. the usual historical perspective of people engaged in "emergency response") or
incident-long (maximizing the lives saved including those saved via fixing
infrastructure or building victim competence - fix roads, treat flooded wells or train people in First Aid).  As the time scale lengthens you may expect to refocus on tasks that don't appear urgent but may save more lives
than focusing on direct medical aid.  Long-term-resilience priorities (fix
the school, change the electrical power source, train people in sanitation) tend to be those that make it possible for people to get by where they are with what they have.

Another thing lacking is an enumeration of some of these perspectives and how the various viewers of the same information could contribute to common data models.  A few more complex use cases are need to illustrate how this works.  Say doctors observing general patterns of medical cases discover a water contamination problem and can very quickly cause tests and treatments to occur.  Or camp operators investigating reported thefts realize that a vast majority of the victims are from one specific ethnic group or village and provision is made to isolate them from those who are preying on them.

==== graceful degradation ====

>This is a necessary requirement  for
> us, but not sufficient.  You don't see the details on
> data that you would need for interoperability.

Often the data definition is delegated to some more specific standard.  As in our discussion of routes and paths, where time and spatial location can be specified according to existing ISO time and GIS standards, and what we
are specifying is a sequence of these that represents a vehicle or person's
trajectory/itinerary/route/path/plan.

Even if a logistics system does not properly support a robust concept of a path through space and time, it will at least be able to query some other system with "where was this person intending or reporting they would be at 3PM Chinese time?" or "at 2:24AM where is the closest person with skill X?"

One minimizes communication between the different systems by supporting the higher level concept of the itinerary/trajectory but if it isn't supported,
it degrades gracefully to a higher overhead series of communications about
the specific expected or reported locations.

=== levels of interoperability ===

>  Which reminds me that we probably need to strengthen our
> discussion of interoperability itself.

That was needed long ago, I think.  One could start by defining three levels of compliance:

- a minimum level in which a high-overhead but still automatic integration of core logistical data is possible, and other elements at least have some names in common so that simple techniques like data merges tend to work - 

appropriate for municipal officials in developing countries to run on their own, and integrating easily with fax, voice or voice mail & paper records

- a fully compliant level of integration in which the abstractions are all supported and true peer interactions are possible - preferably implemented as free software with open content documentation (hard to imagine any other model that would be acceptable)

appropriate for national agencies and any developed nation or global NGO 

- a controlling, guiding or integrating level in which active translation and conversion of data is accomplished, linking legacy systems with those compliant systems that are engaging in the peer-to-peer interaction - has the potential for human intervention, real time correction, distribution of tasks potentially worldwide, and integrating fully with models of natural capital and ecological services, long term social and family impacts (for purposes of minimizing trauma and prioritizing preventative or re-uniting daughters with mothers or aunts to prevent rapes before other re-unitings).

appropriate for the largest global NGOs, developed nations' coordinating and security agencies, UN HCR, World Bank and others with primary support responsibility

> Gary Berg-Cross,Ph.D.
> gbergcross@gmail.com     
> http://ontolog.cim3.net/cgi-bin/wiki.pl?GaryBergCross
> SOCoP Executive Secretary
> Principal, EM&I Semantic Technology
> Potomac, MD
>  301-762-5441
> 
> 
> On Thu, Apr 2, 2009 at 12:01 PM, 
> <paola.dimaio@gmail.com> wrote:
> > Mandana and all
> >
> > here is the glossary for this work
> >
> > http://www.niem.gov/topicIndex.php?topic=file-glossary
> >
> > their jurisdiction seems US,
> > it would be good to have a conceptual model
> >
> > is this a standard that we should reference?
> >
> > following up with Chamindra's assignment today, I
> have entered a few
> > additional thougths to the sectin
> > 'standards' and a table that I have not yet
> managed to paste into the wiki
> >
> > in summary
> > we need to define what we consider a standard
> > and list and analyse the standards that we refer to,
> in order to identify
> > gaps
> >
> > i dont know how to make a table in our wiki (maybe
> will work something out
> > later)
> >
> > feel free to amend/correct
> >
> > cheers
> > PDM
> >
> >
> >
> >
> > On Thu, Apr 2, 2009 at 3:27 PM, Gary Berg-Cross
> <gbergcross@gmail.com>
> > wrote:
> >>
> >> Mandana  et al,
> >>
> >> Here is a liitle bit more on NIEM 2.0.
> >>
> >> A good site to start is with there Documents and
> Download page:
> >> http://www.niem.gov/library.php#rcanchor
> >>
> >> >From there you might go to:
> >>
> >> http://www.niem.gov/niem-2/niem/index.html
> >>
> >> This has the schemas, which are hard to follow
> without an XML tool...I
> >> think the excel version however provides most of
> what we need.  They
> >> have a tab for Emergcy Management.  Here's an
> example of what one sees
> >> there. We were talking about contact info like
> telephone numbers.
> >>
> >>  There is an Alarm event that is a type of
> Activity and has the following
> >> info.
> >>
> >>
> >> extends nc:ActivityType A data type for an alarm
> event.
> >>
> >> em:AlarmEventCategory   <abstract element, no
> type>     A kind of alarm
> >> event.
> >>
> >> Substitutable Elements:
> >>    + em:AlarmEventCategoryCode
> apco:AlarmEventCategoryCodeType A kind
> >> of alarm event.
> >>    + em:AlarmEventCategoryText nc:TextType    
> A kind of alarm event.
> >>
> >> em:AlarmEventCallBackTelephoneNumber  
>  nc:TelephoneNumberType  A
> >> telephone number of the alarm event requestor.
> >>
> >> It would take a few days perhaps to map this
> spreadsheet of entities
> >> to things we are taling about.  They have lots,
> for exampe on
> >> Organizations, Resoureces and People.  Below is
> the section on
> >> Organization.
> >> --
> >> Gary Berg-Cross,Ph.D.
> >> gbergcross@gmail.com
> >>
>  http://ontolog.cim3.net/cgi-bin/wiki.pl?GaryBergCross
> >> SOCoP Executive Secretary
> >> Principal, EM&I Semantic Technology
> >> Potomac, MD
> >>  301-762-5441
> >>
> >> Organization locxation Relation extends
> nc:AssociationType      A data
> >> type
> >> for an association between an organization and a
> location.
> >> nc:LocationReference    nc:LocationType Details
> about a physical location.
> >> nc:OrganizationReference      
>  nc:OrganizationType     A unit which
> >> conducts
> >> some sort of business or operations.
> >>
> >>
> >>                A data type for a body of
> people organized for a particular
> >> purpose.
> >> Click here for object properties
> >> Click here for sub-types
> >> nc:OrganizationAbbreviationText nc:TextType    
> An abbreviation, acronym,
> >> or code for an organization name.
> >> nc:OrganizationActivityText     nc:TextType  
>   An activity that an
> >> organization is known or thought to be involved
> with.
> >> nc:OrganizationBranchName       nc:TextType  
>   A name of the chapter or
> >> branch
> >> by which an organization is known within a larger
> group of
> >> organizations.
> >> nc:OrganizationCategory <abstract element, no
> type>     A kind or
> >> functional type of organization.
> >>    Substitutable Elements:
> >>    + nc:OrganizationCategoryText      
> nc:TextType     A kind or
> >> functional
> >> type of organization.
> >>    + j:OrganizationCategoryNCICORIAgencyCode  
> fbi:ORIAgencyCodeType   A
> >> functional kind of an organization.
> >>    + j:OrganizationCategoryNCICTYPOCode      
>  fbi:TYPOCodeType        A
> >> functional
> >> kind of an organization.
> >>    + j:OrganizationCategoryNLETSCode  
> nlets:OrganizationCategoryCodeType
> >>      A
> >> functional kind of an organization.
> >> nc:OrganizationDayContactInformation  
>  nc:ContactInformationType       A
> >> means
> >> of contacting an organization during daytime
> hours.
> >> nc:OrganizationDescriptionText  nc:TextType    
> A description of an
> >> organization
> >> nc:OrganizationDoingBusinessAsName    
>  nc:TextType     A name an
> >> organization
> >> uses for conducting business.
> >> nc:OrganizationEmergencyContactInformation    
>  nc:ContactInformationType
> >>       A
> >> means of contacting an organization in the event
> of an emergency.
> >> nc:OrganizationEstablishedDate  nc:DateType    
> A date an organization was
> >> started.
> >> nc:OrganizationEveningContactInformation      
>  nc:ContactInformationType
> >>       A
> >> means of contacting an organization during evening
> or early night
> >> hours.
> >> nc:OrganizationIdentification  
> nc:IdentificationType   An identification
> >> that references an organization.
> >> nc:OrganizationIncorporatedIndicator  
>  niem-xsd:boolean        True if an
> >> organization is incorporated; false otherwise.
> >> nc:OrganizationLocalIdentification    
>  nc:IdentificationType   An
> >> identification assigned at a local level to an
> organization.
> >> nc:OrganizationLocation nc:LocationType A location
> of an organization.
> >> nc:OrganizationName     nc:TextType     A name
> of an organization.
> >> nc:OrganizationNightContactInformation
>  nc:ContactInformationType       A
> >> means of contacting an organization during
> late-night hours.
> >> nc:OrganizationOtherIdentification    
>  nc:IdentificationType   An
> >> identification assigned to an organization.
> >> nc:OrganizationParent   <abstract element, no
> type>     An entity that
> >> owns,
> >> controls, or operates the organization.
> >>    Substitutable Elements:
> >>    + nc:OrganizationParentAffiliate  
>  nc:OrganizationType     An
> >> organization that owns, controls, or operates the
> organization.
> >>    + nc:OrganizationParentOrganization
> nc:OrganizationType     An
> >> organization that owns, controls, or operates the
> organization.
> >> nc:OrganizationPrimaryContactInformation      
>  nc:ContactInformationType
> >>       A
> >> preferred means of contacting an organization.
> >> nc:OrganizationPrincipalOfficial      
>  nc:PersonType   A chief or high
> >> ranking
> >> executive of an organization.
> >> nc:OrganizationStatus   nc:StatusType   A status
> of an organization.
> >> nc:OrganizationSubUnit  nc:OrganizationType    
> A division of an
> >> organization.
> >> nc:OrganizationSubUnitName      nc:TextType  
>   A name of a subdivision of
> >> an
> >> organization.
> >> nc:OrganizationTaxIdentification      
>  nc:IdentificationType   A tax
> >> identification assigned to an organization.
> >> nc:OrganizationTerminationDate  nc:DateType    
> A date an organization
> >> went
> >> out of business.
> >> nc:OrganizationUnitName nc:TextType     A name
> of a high-level division of
> >> an organization.
> >>
> >>
> >>        extends nc:AssociationType      A
> data type for an association
> >> between an
> >> organization and another organization or unit.
> >> Click here for object properties
> >> nc:OrganizationReference      
>  nc:OrganizationType     A unit which
> >> conducts
> >> some sort of business or operations.
> >> nc:OrganizationUnitReference  
>  nc:OrganizationType     A unit of an
> >> organization.
> >>
> >
> >
> >
> > --
> > Paola Di Maio,
> > ****************************************
> > Forthcoming
> > IEEE/DEST 09 Collective Intelligence Track (deadline
> extended)
> >
> > i-Semantics 2009, 2 - 4 September 2009, Graz, Austria.
> > www.i-semantics.tugraz.at
> >
> > SEMAPRO 2009, Malta
> > http://www.iaria.org/conferences2009/CfPSEMAPRO09.html
> > **************************************************
> > Mae Fah Luang Child Protection Project, Chiang Rai
> Thailand
> >
> >
> >
> >

Received on Thursday, 2 April 2009 23:41:09 UTC