OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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


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