RE: [emergency] Naming Conventions

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

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

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