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

 


Help: OASIS Mailing Lists Help | MarkMail Help

egov message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [egov] Re: [skewed] RE: Starting Discussion to Get Your Advice andHelp wi th E-Forms for E-Gov


Dave,

We have a saying in my organization that I think is fitting here. When we
use "overloaded,  ill-defined, or simply new and different vocabulary
without sharing the context or semantic meaning (up front), we typically
realize after much heated discussion that we are "in violent agreement." :-)
I think that my use of the word "atomic" might have done this. Let me try
and rephrase some of my thinking and see if more discussion helps you and
probably others out there watching this thread.

First, I am definitely lobbying for a VERY narrow scope. We are a small
group of people facing an enormous challenge. Therefore, I'll reiterate my
first point (that I made in other messages). I believe first and foremost
that our focus must be on establishing vocabulary that is inherently
governmental in nature. Some good examples of these area could include the
following: 

1. Nonproliferation
2. Confidence Building
3. Sanctions
4. Terrorism
5. Counterterrorism
6. War Crimes
7. Negotiations
8. Consequence Management
9. Laws
10. Taxation

These are just a few ideas and could be organized into tighter, and better
representations for conceptual modeling, but I think you get my point. These
are topics, domains, namespaces that are exclusively "owned" by governments.
Industry may participate, but we should not confuse a parties participation
with ownership issues. I believe that if we can separate those things that
are "owned" by industry versus those things that are "owned" by government,
we can significantly reduce the amount of work that any group (or other
organizational element) needs to address. I also believe that the eGov TC
would be able to make much better use of work done by other group, helping
to accelerate the prototypes that many people are talking about doing
already.

<HUMOR>Second, with regards to having spent $50M CAD, if this were easy, it
would have been done already. I am expecting this to be just as difficult as
it has ever been, but with the help of technology, human flexibility, and
strong wills, I am anticipating that we can make the same mistakes faster
than previous attempts but recover faster too. </HUMOR>

Third, I completely agree that we should be looking at (UML) collaboration
patterns (if I understand you correctly) to help accelerate our work. This
will greatly help us understand how certain concepts align with one another
within the larger OASIS framework and other international organizations.
However, knowing the people, places, things, events, transactions and their
relational collaborations does not obviate the need to decline and define
the relative vocabulary that sufficiently describes diplomatic
communications, for example. Knowing that collaborative patterns are
available to help define the relationships and define their "data scope" is
only half the battle. Having usable, meaningful, and fully articulated
vocabulary is essential. The last thing that we want is to have 3 TCs use
different definitions for the same concept. Conversely, we do not want to
have a single TC use 3 different terms to refer to the same concept. Clearly
we would have a data integrity problem. This is the danger that I see using
some of the approaches and suggested "outlines" mentioned in the list
lately. I can easily imagine this as a likely outcome using less that
accurate approaches to solving this problem. As I mentioned before, simply
calling one of our subcommittees "Services" is loaded with the assumption
that our definitions and work and surround an activities model. With this
approach, I think that it fair to say that we could easily end up with
outcomes like I described above.

Fourth, I think too that we need to respect the fundamental differences
between government and industry. For years, I have silently groaned when I
hear my government colleagues use business terms to describe their work and
experiences. IMHO these terms that have semantic meaning only when used in a
true business setting, not a governmental one. Why? Primarily because the
roles and responsibilities of government are different from those of
industry. Therefore when a government person says something like "I have
10,000 customers." This does not accurately reflect the situation. There is
a fundamental difference between the recipients of government services and
the recipient of industry services. The expectations of each party are
different, roles are different, and the transactions and conditions are
different. There is data that we need to define to express this relationship
(from a governmental perspective), BUT this is an opportunity to use other
definitions like those defined in CTML and UBL. While we could spin this
topic into an entire Ph D. program, I hope you see my point. Here is a
classic example of 2 groups using the same term to mean 2 different ideas.
So if we (blindly) adopt UBL, CML, or other TC definitions of these terms,
we are not going to be communicating vital information, especially if we are
talking about subtle domains like Law and Diplomatic Communications -- let
alone the procurement activities that others have suggested within B-G and
G-G.

So I hope that in this long winded way, I have simply said, "I agree with
you." At the same time, I hope that this note serves as an impetus to get
others thinking about what they *should* be doing versus "just getting
something out there." Does this help? I'm interested in what others have to
say.

On 1/10/03 11:21 PM, "David RR Webber - XML ebusiness"
<Gnosis_@compuserve.com> wrote:

> Todd,
> 
> I have to inject a reality check here.  Does anyone have any idea
> how tough this is?
> 
> Example:  Canadian Government has been looking at this for
> 3 years now, and have spent $50M on consulting.  And the
> US Gov is approximately 50 times more than that in diversity.
> I think we need to set some realistic scope here.
> 
> What I would say is attainable is to set some guidelines
> on approach - for instance DFAS is working on a
> Business-Centric Methodology - to enable eGov teams
> within their own domains to have a concrete roadmap
> that they can use.
> 
> Another example - Addresses - the OASIS CIQ work has
> been widely praised.  Within a typical USGov department
> there are hundreds of address formats being used.  But
> OASIS CIQ is not looking to become the "master" address
> format for USGov.  Far from it.  Looking at postal addresses
> worldwide (because the USGov has to be able to address
> things from Kabul to Rekjavik to Terra de Fuego) - there are
> currently 207 in-country postal systems, and each has about
> 5 different postal address formats (USPS have four other
> formats - not just the familiar Street/City/ZIP).  So this makes
> about 1,000+ postal address formats.  And so the list goes
> on.  Lesson learned - we need to identify the stake holder
> (i.e. USPS in this case for USA) and work with them on
> positioning OASIS technologies to help them meet their
> needs.
> 
> So while it may sound great to say "let's just sit down and
> work out the list of "atoms" that the USGov should be using",
> we have to look at what is practical and what does not.  Also
> I'm reminded here of the past CALS and UDEF efforts to
> be the master atomic dictionary system.
> 
> Anyway - there is a solution here that I'm seeing makes
> sense.   Again - reiterating - we need a set of coherent
> guidelines and tools - that departments can take - to
> implement a cross enterprise, open architecture
> solution.  "Atoms" at that level can be understood
> and the approaches used.
> 
> I'm not going to attempt in this email to
> spell out that depth of detail.  I've been involved
> over the past six months in many pieces of work that
> add together in this area, and there are white papers
> and presentations from the last couple of months
> that teams have.  I can say that one such key piece is
> collaborative semantic registries - as an example
> of great work going on in OASIS that provides
> a vital component.   I'd suggest our better effort
> would be in understanding all this for people
> and delivering a coherent architecture story.
> 
> Again, simple steps, set attainable scope, produce
> clear means to achieve that, identify some small
> sample areas (such as Address) where you can
> show real results, set schedule, work a pathfinder with
> departments that are clearly the stakeholder
> (such as USPS) - and then present these findings
> for others to take forward.
> 
> My thoughts turn to soccer.  We can coach
> soccer, we can run coaching sessions for
> coaches, we can print up coaching manuals,
> but at the end of the day - the players have
> to play the game and call the shots on their
> fields.
> 
> A good coach can enable players to
> discover and grow faster and better than
> without coaching, but trying to laydown
> moves for every team, everywhere to
> follow and work from is not the approach
> that wins.
> 
> Or are we talking about the same
> "atomic" things here?!?
> 
> Thanks, DW.
> ===================================================
> Message text written by Todd Harbour
>> 
> Instead, I believe that our work should primarily focus on identifying the
> vocabulary that is exclusively within the governmental domain. All else is
> something that other experts are most likely working on. If we focus on the
> "atomic" level, we can define the building blocks that will enable other
> TCs
> and domains to effectively communicate with governments.
> <
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


=========================================
Todd Harbour                            571-276-2196 (Cell)
45245 Business Court              703-478-9881 (Talk)
Dulles, Virginia 20166              703-478-9883 (Fax)




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC