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
-----Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Friday, April 18, 2003 1:48 PM
To: Bullard, Claude L (Len)
Cc: emergency@lists.oasis-open.org
Subject: RE: [emergency] Naming Conventions
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
Tel: 510-849-2309
Fax: By Request
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]