RE: [huml] NYAM Portal Collaboration

[Rex Brooks <rexb@starbourne.com>]

Hi Len,

Thanks for giving it some thought..

Let's be sure we know which material you are referring to, which I 
assume is the article, which does not deal with individuals, as 
opposed to the demonstration which does, though only in a limited 
context and hypothetically. In the latter case we will make it clear 
that these distinctions in 1. are made.

In 2. individuals, such as a specific on-duty EMT can have 
permissions from a defined role in 1. and still have individual 
preferences for using those permissions in that role registered with 
the Portal/portlet in that role in a way that is doable and not 
prohibitively expensive in terms of having an existing database in 
the Portal and/or in the portlet provider for the organization in 
which the EMT works.

In another instance of 2. individuals should be able to have their 
medical histories, and specific sets of permissions for emergencies, 
including a living will, stored in a HumanML-enhanced (not required) 
profile which may or may not have references or links to other roles 
in employment, socially, etc. There are any number of ways the 
location and passcodes for this profile can be kept in wallets, on 
keychains, etc, and still require fingerprint or iris ID. This is 
doable without HumanML, but with it, much wider use of a single 
source profile is possible, provided HumanML survives and thrives and 
gets these secondary vocabularies assembled, implemented and accepted 
as useful standards.

However, you are very correct about a public portal needing to deal 
with multiple overlapping public and private jurisdictional and 
political considerations, and it would be very good if our proof of 
concept here can evolve into an early adoption of CAP, WSRP, and 
HumanML and serve as a testbed for these implications in practice, 
where we can get good feedback from experience.

Having just wrestled with the first straw-man schema for ICS201, I 
can heartily endorse the notion of making some headway into 
roles-based organization of these kinds of forms for Incident Command 
Systems that extend across the emergency management community. It 
sorta helps that this work is going to be tested on the actual 
systems that are being designed and tested to actually be used, or as 
close as is currently possible, so whatever we learn is based on 
working with good tangible resources.

Thanks again.

Ciao,
Rex

At 1:03 PM -0500 10/20/03, Bullard, Claude L (Len) wrote:
>An attempt at applying HumanML to the issues
>listed in that article would focus on the
>roles of the communicating individuals, not
>the individuals.  To do otherwise is to profile
>the person instead of the role.  The culture
>is the enterprise/business model first, and
>then the culture of the individual.
>
>1.  The role has less data collection requirements.
>That makes it doable, and is isomorphic to the
>requirements for role playing games.   A role
>play based system enables individuals to be
>changed (say, a shift change in a hospital
>or a police station).  Business rules apply
>predominantly to the role.
>
>2.  Collection of data on individuals is not
>only very extensive, expensive and noisy (people
>lie), it is a non-starter in
>many environments and for many people.  A
>public portal has to deal with this problem
>directly and with cognizance of the political
>implications.
>
>Particularly when combined with disaster
>management and planning, a role based model
>is required.  One then augments that with
>personnel/master name indexed data for
>deriving relationships among individuals
>with respect to their assigned role.
>
>len
>
>
>From: Rex Brooks [mailto:rexb@starbourne.com]
>
>Dear Colleagues,
>
>(Note that I am posting this subsequent to
>sending it out to the originally intended
>addressees. I want to provide it to our lists
>now, with many thanks to Chandra and James for
>their proofreading and feedback, and, of course
>to Russell and Ranjeeth for their usual
>contributions to the overall effort as well as
>this specific project. So please feel free to
>offer your own informaton, comments or
>suggestions.)
>
>Please excuse my metaphorical dust, as we assess
>reconstituting the effort to produce a "Proof of
>Concept" example Web site for the New York
>Academy of Medicine, (NYAM), Public Healthcare
>Preparedness Portal Project. This project was
>originally conceived to take advantage of the
>opportunity to participate in a group booth
>sponsored by the Emergency Management XML
>Consortium and DMI-Services featuring a
>multi-participant distributed network (LAN)
>demonstration of the Common Alerting Protocol
>(CAP) and DMI-Services.  The demonstration
>project focused on LAN-based distribution of an
>alert based on a hypothetical scenario: a
>terrorist attack employing a chemical agent
>impacting municipal, county, state and federal
>agency jurisdictions in the city of St. Louis.
>Unfortunately, this  project was terminated prior
>to presentation due to inadequate scheduling and
>preparation, uncertainty regarding on-site
>equipment availability, and Web connectivity.
>
>The participants who have indicated a willingness
>to continue this project will be acknowledged in
>all materials supplied by this project for public
>dissemination and include NYAM, Humanmarkup.org,
>Inc., Oracle Corporation, and DMI-Services.  This
>acknowledgement will include the collateral
>contributions of The Fund for the City of New
>York, through whose technology consulting program
>the participants were introduced.  Similarly, The
>Organization for the Advancement of Structured
>Information Standards (OASIS), whose Web Services
>for Remote Portlets v1.0, (WSRP v1.0) standard
>and whose Common Alerting Protocol v0.9n (CAP
>v0.9n) Committee Specification will be featured
>as a demonstration of both the interoperability
>of these specifications and of the potential for
>a national infrastructure to employ such open,
>public standards in the public interest. Thanks
>will also be acknowledged to the OASIS Emergency
>Management Technical Committee, the OASIS Human
>Markup Technical Committee and the OASIS Web
>Services for Remote Portlets Technical Committee
>for their work in producing the specification,
>and supporting the overall collaboration effort.
>
>The New York Academy of Medicine,
>Humanmarkup.org, Inc. and Oracle Corporation form
>a qualified Collaborative Operations Group, (COG)
>for the purpose of beta testing the
>Interoperability Services component of the
>Disaster Management Interoperability Services
>protocol as designated by that governing body.
>
>What I would like to do is to review the goals,
>roles and responsibilities of the parties who
>expressed willingness to continue with this work
>after the public demonstration at the Global
>Homeland Security Conference September 24-26 in
>Washington, D.C., which this COG elected to
>forego. I also want to include an update of the
>scenario I want to play out in the demonstration
>portal, powerpoint presentation and paper that
>will accompany the presentation. Therefore, I am
>putting that report in a separate attachment with
>this e-mail.
>
>I have delayed my attempt to reconstitute this
>effort until I had at least one new opportunity
>to make a presentation of this effort and until
>after a key participant of the effort, Mr.
>Michael Freedman, of Oracle Corporation, has had
>time to recover from his recent bicycle injuries.
>
>I am pleased to announce that Mr. Russell
>Ruggiero and I as representatives of both
>Humanmarkup.org, Inc., and the OASIS HumanMarkup
>Technical Committee have obtained an invitation
>to make a presentation to the Federal Enterprise
>Architecture, Collaboration Expedition Workshop
>scheduled for December 9, 2004. This is a well
>focused and strategic venue, which can be
>publicized within the federal agency communities
>and should attract interest from a broad audience.
>
>In addition, we may also have an opportunity to
>make a late-breaking news presentation and/or
>participate in a Town Hall Meeting on Emerging
>Technologies at XML 2003 Conference, which is
>scheduled for that week as well. This could
>require a condensed version of the workshop
>presentation.
>
>This may be a logistically difficult proposition
>since the Workshop is in Arlington, Virginia,
>while the Conference is in Philadelphia,
>Pennsylvania. It is also somewhat unlikely that
>this second presentation can be accomplished
>without undue haste given that the purpose for
>that presentation could only be fulfilled by a
>fortunate series of developments allowing key
>components from other, related efforts, such as
>the Map Symbology working group, chartered by the
>Homeland Security working group of the  Federal
>Geographic Data Committee (FGDC).
>
>However, having said that, there is a distinct
>lack of any Emergency/Disaster Management-related
>topics or seminars being offered at the XML 2003
>Conference, and it may be such a timely
>presentation that some resources presently not
>earmarked for that venue might be allocated, and
>that would virtually necessitate that we put
>forward the effort necessary to prepare and
>deliver this version of our presentation. I will
>be outlining my own thoughts about the necessary
>emphasis for each of these presentations using
>the same general material for both.
>
>At least in part, the impetus for obtaining the
>invitation to make a presentation to the
>Collaboration Expedition Workshop came in
>response to the article published in Direct
>Marketing Review that Mr. Ruggiero and I wrote,
>entitled, iAre We Ready for the Next Web?" and
>which was published 17 October, 2004. See DM
>Review online:
>
>http://www.dmreview.com/editorial/dmdirect/dmdirect_article.cfm?EdID=7548&is
>sue=101703
>
>Participants in this effort might want to
>familiarize themselves with the specifics of the
>article in order to understand more thoroughly
>how this article serves as a springboard for both
>the Workshop presentation and the potential
>Conference presentation.
>
>I am respectfully requesting reconfirmation from
>active partners with some indication of how best
>to coordinate this effort with each of you
>considering your respective schedules and the the
>presentation date, December 6, 2003. I am also
>requesting from all addressees your comments,
>suggestions, issues and concerns, and, of course,
>any aid you think you might be able to contribute
>to this effort.
>
>Best Regards,
>Rex Brooks
>--
>Rex Brooks
>President, Stabourne Communications Design
>Executive Director, Humanmarkup.org, Inc.
>Co-Chair, Secretary, OASIS HumanMarkup Technical Committee
>Chair OASIS Human Physical Characteristics
>Description Markup Language Subcommittee
>Member Web Services for Remote Portlets Technical Committee
>Chair Web Services for Remote Portlets-Markup Subcommittee
>Member OASIS Emergency Management Technical Committee
>Member, OASIS Emergency Management Geospatial Information Services
>Subcomittee
>GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
>W3Address: http://www.starbourne.com
>Email: rexb@starbourne.com
>Tel: 510-849-2309
>Fax: By Request


-- 
Rex Brooks
GeoAddress: 1361-A Addison, Berkeley, CA, 94702 USA, Earth
W3Address: http://www.starbourne.com
Email: rexb@starbourne.com
Tel: 510-849-2309
Fax: By Request