MHonArc v2.4.5 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] Naming Conventions
Title: RE: [emergency] Naming
Conventions
Thanks for the input Len. Your experience is valuable, as usual.
My own concerns in this arena have been fairly limited to the overlaps
with HumanML (especially the Medical connection) and GEOVRML, and
providing new kinds of tools, i.e. 3D tools, that will use the
standards this TC develops, among others.
I had not given the database issue much thought, but what you say
makes sense.
Ciao,
Rex
Public safety is about:
a. Command and control of assets over real time
incidents.
b. Reporting systems that span both incidents
and
investigation and disposition of incidents (calls for
service - CFS).
c. Use of data gathered to manage asset
allocation
such that incidents that can be avoided are
(pre-CFS) and those
that cannot are managed
(post-CFS).
that is, command and control, reporting, and
analysis.
Note further, that although it appears to be
"impossible" to take
a vocabulary approach, though tedious, in some ways
this is
the best approach.
1. No standard is final. Vocabularies
drift, yes, but this is
often a problem for the standard's lifecycle, not the
actual
application. One never is writing "for the
ages" ever. It
feels good to think that, but it is not
realistic.
2. Standard vocabularies are easy to implement.
The vast
majority of us doing public safety business use
relational
technology for records management. Despite
any innovations
to the contrary, I've yet to process a single RFP in
the last
six years that requested an object-oriented database.
Public
safety is not an early adopter industry; it shuns
exotic and
emerging technologies for good
reasons.
Implementing a vocabulary is quite easy for relational
systems because we
map to the names and that is about it. It is
often just an issue
of adding columns to existing tables. That is
why I am
glad the JusticeXML is loose at the stricter levels of
the
data definition. Even real network
interfaces come down
to basic APIs, data formats, names and mostly
strings.
After that, orchestration/choreography but that is
the
protocol, not the data.
3. Even if it appears that there are large
differences
in local and state agencies, in practice, these are
not
significant as long as UCR/NIBRS/NCIC
specifications
for state to Federal reporting are honored.
Yes, there
are local agency implementation issues, but that
is
covered in implementation costs. Public safety
systems
are not yet commodities, nor are they
completely
custom systems. Otherwise, they would not be
simply
expensive, they would be
unaffordable.
So beware of creating a very abstract standard.
Those
don't often get implemented well or interoperably
at
the level where interoperation has any real
meaning
or benefit. Standards writers should be wary of
the
danger of spec'ing systems instead of standards.
It
can be deuce difficult to see the difference
particularly
where the authors are also implementors. On
the
other extreme, one shouldn't spec a system
to
which no standard can be applied. Finding
the
middle ground that suits the time and
technology
of the time is the trick.
len