emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] Naming Conventions
- From: "Bullard, Claude L (Len)" <clbullar@ingr.com>
- To: 'Rex Brooks' <rexb@starbourne.com>
- Date: Fri, 18 Apr 2003 14:08:42 -0500
Title: RE: [emergency] Naming Conventions
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
Yep. That's about it.
Ciao,
Rex
Got
it, Rex. The usual meta-meta problem: do a data design a
la abstract interface
or
create a vocabulary. I like the VRML solution to that: do both
with the
encodings and vocabularies as optional features. It's more
work but one
can
nail down the semantics and give the user community a chance
to
converge at the level of efficiency most appropriate to the local
contracting
situation. When volunteer groups sit down to create specs and
standards,
they
should keep in mind the problem for the actual industry of
changing
horses. We're glad to see the work being done by OASIS
in public safety,
but
until it shows up in an RFP, it's just nice-to-have, Sounds Good Maybe
Later,
kind
of work. DOJ can't drive it down from the top without funding it
too. And
technical standards that don't account for medium constraints
don't have a
snowball's chance anyway. Thus, we use the RFP to guide
us and cost
accordingly.
I
note reading through the JusticeXML dictionary that they have wisely
left
open
most aspects of the data definition (eg, loose types, loose
occurrence
constraints, etc) and stayed mainly to a labeled tree. Much
easier to live
with
that way.
len
-----Original Message-----
From: Rex
Brooks [mailto:rexb@starbourne.com]
Sent: Friday, April 18, 2003
11:48 AM
To: Bullard, Claude L (Len)
Cc:
emergency@lists.oasis-open.org
Subject: RE: [emergency] Naming
Conventions
Hi Len,
Please see my reply to Eliot's post.
--
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]