MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] Groups - EDIT of emergency-CAPv-1.1
I don't have any objections to this practice for design. My concerns are:
1) Where do we get our external code lists/tables? We already know
that there will be more than one single source since CBRN is a
category unto itself, as are several GJXDM-proxied/imported
standards/code lists (some of which we need to pay for unless there
is an agreement between standards bodies that provides for sharing
these resources of which I happen to be unaware) and then there is
IEEE 1512 which also entails acquiring three (3) standards. We can't
refer to black boxes, after all, not if we wish to perform due
diligence, and even if it were possible to extend blind trust for our
fellow standards bodies, I would dig my heels in on that for my own
peace of mind.
2) How do we reliably reference these external code lists/tables? I
can guarantee that I will recommend against any proxy mechanism that
contains the chokepoints I have already identified, and I don't think
we really want to incur the network messaging overhead required to
convert and validate 1512 alone, notwithstanding the other little
black holes into which our parsers and validators can disappear.
My points converge on a conclusion I have been coming to for quite a
while now as I explored the twists and turns of these various
vocabularies. That conclusion is that we need a reliable way to
abstract these code lists out of our work and confine the whole
distribution element to a slightly higher level of abstraction,
somehow.
Of course, it is the somehow that has me stumped. All I really know
at this point is that if we continue attempting to cover details of
vocabularies for every constituency in the distribution header, the
darn thing is going to be so complicated as to be inoperable period,
let alone interoperable.
We have neither the time nor the resources to do that, so we might
want to focus on how to solicit aid from the other standards bodies
and governmental offices to resolve some of these issues so that we
can reliably reference these external code lists/tables and harmonise
the top level base or core ontology of Event/Incident Types in such a
way that the distribution element only needs to include those
references while the particular taxonomies for specific
incidents/events that belong to those top level types can safely be
relegated to the body of the message.
This same advice applies to the simultaneous discussion we are having
in regard to the area/areaDesc components.
Ciao,
Rex
At 8:33 AM -0500 3/18/05, Ham, Gary A wrote:
>I agree with Mike, assuming that the actual XML messages remain human
>readable (with the possible exception of the polygons.) Encapsulation
>of concerns is a good idea, particularly for unstable categorization
>lists.
>
>Rrepsectfully,
>
>Gary A. Ham
>Senior Research Scientist
>Battelle Memorial Institute
>540-288-5611 (office)
>703-869-6241 (cell)
>"You would be surprised what you can accomplish when you do not care who
>gets the credit." - Harry S. Truman
>
>
>