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

Thanks Craig for the looong and interesting post
I have skimmed through half of it, and it would be nice to see your
suggestions discussed and incorporated accordingly, its going to be a
treaty......

On Fri, Apr 3, 2009 at 12:40 AM, C H <craighubleyca@yahoo.com> wrote:

>
> 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
> > >
> > >
> > >
> > >
>
>
>
>


-- 
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