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

I don't believe these issues can be dealt with as add-ons.  At the least the following needs to be added:

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

The "framing the report" sections indicate my criticisms of the current structure proposed.  The other issues could simply be appendices to the report, but they have no context without the paragraph as stated above.

The purpose of this report is to frame some long term goals for the W3 project.

Not to restate rationale or facts that any participant already well knows.

I repeat, 
> >> not enough attention has been paid to composability, views or
> >> sets of use cases that represent the views of particular professions
> >> responsible authorities, and to the levels of
>>> interoperability desired or specified. 

It's these issues that should be the major focus of any final report, not an unnecessary sales pitch for open source software, outlining problems of incompatible or proprietary communications systems, or restating all the problems of cooperation between global, national and local ER agencies.  No value whatsoever is added to the discourse by repeating all these things.

So "adding bullet points" to a generally unfocused off-point presentation is not going to do any good.  What's needed is an entirely new outline. Of course anyone is welcome to use or post or wiki any of the material that I provided, in this post or any previous.

Craig

--- On Tue, 4/7/09, paola.dimaio@gmail.com <paola.dimaio@gmail.com> wrote:

> From: paola.dimaio@gmail.com <paola.dimaio@gmail.com>
> Subject: Re: composability/distinctions, substitution/degradation/views,   levels of integration/translation [was] Re: 2 types of NIEM models more   follow up to meeting discussion
> To: "C H" <craighubleyca@yahoo.com>
> Cc: "Gary Berg-Cross" <gbergcross@gmail.com>, "public-xg-eiif" <public-xg-eiif@w3.org>
> Date: Tuesday, April 7, 2009, 5:55 AM
> Craig
> 
> 
> I meant to say 'its going to be a treatise'
> 
> 
> Since it woule be better to keep the final report  short,
> and unless anyone
> has objections, why dont you summarise your suggested
> entries as bullet
> points, so that Chamindra can consider adding them to his
> initial outline as
> 'possible areas to discuss for future work, and maybe
> paste the whole
> exposition somewhere on the wiki where it can be referenced
> later
> 
> cheers
> 
> PDM
> 
> 
> > ...
> >
> >
> > 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
> >
> >
> >
> >
> 
> 
> -- 
> Paola Di Maio,
> ****************************************
> 
> Looking for champions
> http://www.youtube.com/watch?v=sogKUx_q7ig&feature=related
> 
> 
> Vocamp Ibiza  Vocamp.org
> 15-16 April
> 
> Advances in semantic computing,
> Book Chapter Proposals Accepted
> http://www.tmrfindia.org/eseries/cfc-sc.html
> 
> Taxonomy of fundamental Ontology
> http://www.galilean-library.org/manuscript.php?postid=77614
> 
> 
> 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 Wednesday, 8 April 2009 09:28:45 UTC