I
see this in GUI design where the GUI is made to represent the absolute space
of
all
of the information required rather than answering the first questions of the
GUI:
who,
what, when, where and sometimes why.
Information space does not equal time and intention. It is
easy to spot a GUI
developed without answering those questions because the user gets lost
in
space fast.
The
answer, anyway, to Joe's questions will be in the development of the
IEPs
(Information Exchange Packages) at both the reference and the
local agency level. I expect that to occur as a result of RFP
processes,
not
standardization although standardization of the reference packages
will
be very useful.
[JMC] Although the term "standardization" is broad,
we will be standardizing exchange packages in that they will be represented
according to the DRM metamodel. Not sure what you mean by "reference packages"
and the "reference level" - is this synonymous with
"federal"?
I
don't expect the FEA to be adopted any time soon
for
technical reasons including the application of RDF within them. RDF
is a
non-starter.
[JMC] Would be happy to hear more about
these technical reasons, and why RDF is a non-starter (note that we only use
rdf:id in the DRM XML Schema).
I
expect Daconta's NIEM's work to get rapid uptake
once
they get past the pilot stage and the modularization of GJXDM is
accomplished such that the local agencies can cite them in
RFPs.
[JMC] I should clarify that the NIEM is
a joint effort between DHS and DOJ, it's not solely a DHS
initiative.
Joe (end of
comments)
No
contract == no messages. The devil of the DHS/DOJ work is too
many
separate efforts are being harmonized and that takes too much
time
and energy given the separate loci of control. It will take some
very
hard nosed managers to keep it from being a CALS redux
because the consultancy feeding frenzy is fully on. So from
where
I
sit, the IEPs are where the results will be had. Reports are easy
to
understand.
len
(my
opinion only. Not that of my employer.)
I'm interested in how you tackle the problem of
translating from business object definitions into message definitions. I'm
working with an organization that has designed schemas to represent its
(many hundreds of) business objects, and is now struggling with the question
of how to design messages for application data interchange that are based on
these object definitions. The problem is that messages exchange information
about a business object, and different messages exchange different subsets
of the information. Making all the information mandatory and thereby forcing
the sending application to populate the message with data that the recipient
doesn't want to know seems unproductive; equally, making all the data
optional seems to defeat the purpose of validation. So it seems that one
needs a message definition (=type) for each message that is somehow related
to the schema for the business object, but isn't related to it by one of the
recognized mechanisms of restriction and extension. It needs some kind of
concept of being "derived by projection".
Any thoughts or
advice?
