RE: [emergency] RE: OGC UoM Best Practices guidance

[creed@opengeospatial.org]

Gary -

I believe that we are in violent agreement! Just stating things a bit
differently :-) This is why I suggested that the correct approach - as you
are suggesting - is both bottom up and top down.

Also, thanks for support of OGC standards. Perhaps - to help make life a
bit easier for those implementing OGC standards, we have just released
(not even announced yet) a new community resource called OGCNetwork.
Anyone can register and participate. The Network vision is to help solve
the issues you have so correctly identified.  www.ogcnetwork.net . Check
it out. It is fledgling but collaboration is already beginning.

Cheers

Carl


> Carl,
>
> I am not arguing against you or the need for better standards.  We, in
> the DM program are using OGC standards for Web Map services.  We are
> also committed to building to the standards of both the EM-TC and NIEM.
> And we are not just "compliant."  I.e., using three tags, and claiming
> compliance.  We are trying to build real interoperability.  But real
> interoperability takes more than a mandate. It takes real acceptance of
> that mandate.  And no matter who is running the show, developer
> acceptance will be required for real acceptance. It is all a matter of
> morale.  Just like in the military, where Generals run the show, but
> troop morale and the fit of the equipment to the capability and training
> of the troops is a major factor in success.
>
> Top down mandates can work, but only if they are CLEARLY EXPLAINED and
> marketed effectively.  And then, they must actually work as advertised
> and not be so complicated that long-term costs are actually increased.
> Commercial firms use internal standards because they keep costs down.
> They use external standards if they can make more money by doing so. If
> the government mandates a standard, one of two conditions are required
> before the firm will start implementation:
>
> 1. They can bill cost plus. Even if it does not work, they make money.
> This is the normal practice of the Federal integrators. For them,
> failure is no big problem, since real success in Federal systems usually
> about a 50-50 situation anyway (and often that success has less do with
> the technology than politics, so technology risk is often ignored). As a
> result, there has been a lot of money frittered away (I am thinking
> personally of a couple of programs for the Army Reserve, but there are
> lots of others. Think of all of the systems that "built" using the DoD
> data model.)
>
> 2. They think they can sell more of their packaged software because
> standards compliance can expand their marketplace. In this case a
> mandate can motivate a vendor into doing standards to maintain or
> increase market share or enter new markets, so long as complications
> from the standard do not increase costs or competition to the point that
> profits are reduced in spite of the mandate.
>
> So, my mission is to keep the costs of interoperability down in order to
> widen the playing field and encourage more and more vendor
> participation.  For that reason, anything that appears complicated
> scares me a bit.  That said, the world is complicated, and many of our
> systems are complicated. So, many of our system-to-system communication
> has to be complicated.  But, the more complicated it is, or even appears
> to be, the slower true interoperability will happen.  If we do not keep
> that fact in mind as we go about our work, we will be far less
> successful than we could otherwise be.  I know I sound like a broken
> record on this issue. But, since my talents are closer to yours than the
> people you actually need to convince, I sincerely think that my "simple
> solution first" approach has merit. I am not against complication, I am
> just against starting with it.
>
> That said, I have no quarrel GML.  I am going to take a couple of the
> GML examples you sent me in the document and work them into content
> object in the DE as illustrations of how it can be done. (I already have
> a GML point example, but need to do some documentation.)
>
>
> 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
>
> -----Original Message-----
> From: creed@opengeospatial.org [mailto:creed@opengeospatial.org]
> Sent: Monday, April 03, 2006 10:03 AM
> To: Ham, Gary A
> Cc: emergency@lists.oasis-open.org
> Subject: RE: [emergency] RE: OGC UoM Best Practices guidance
>
> Gary -
>
> Perhaps a bit off topic, but I hear the developers pain. That said, who
> is running the show - the developers or the managers/policy makers?
> Perhaps the issue you are pointing to is more one of culture than not
> wanting to take the time to learn something new and correct. I managed a
> development staff (young, old, geeks, gurus, strange personalities) for
> many years. I gave them considerable freedom to be creative and be
> productive. BUT, and I mean BUT, their performance reviews included how
> well they adhered to very specific documentation and coding best
> practices, proper testing of the code they developed, adherence and use
> of a significant set of standard interfaces for our product line, and so
> forth.
>
> Can you imagine if Oracle or ESRI or Microsoft or any other software
> provider did not require their programmers/developers/engineers to use
> their companies internal software development standards, including all
> existing APIs, interfaces, standards, etc? There would be chaos.
>
> This issue is even more on the front burner with SOA gathering so much
> steam. SOA mandates the use of standards. SOA typically forces cultural
> changes in the enterprise - like developers and managers working more
> closely together to understand, define, and document business process.
>
> Sorry for the slight rant, but at the end of the day, implementation of
> standards is driven from the top down and the bottom up. Uptake is a
> function of both policy (top down) and getting the job done (bottom up).
>
> I would hazzard a guess that if corporate policy stating that a given
> standard will be used is coupled with resources that made it easier for
> a developer to implement, then uptake would not be an issue.
>
> Cheers
>
> Carl
>
>
>> Carl,
>>
>> At least you provided examples!!!
>>
>> All kidding aside, it is not me that I am worried about here. It is a
>> group that I tend to identify with, the journeyman software developer.
>> Only with their support is adoption by a significant, traction
>> capable, number of real vendors and government programs possible.
>> Mandated or not, developers only build what they think is reasonable.
>> (Think Ada, which was a superior language but essentially failed, in
>> spite of government mandate.) So you will have to convince those who
>> actually build software that what you are asking them to do is
>> reasonable for their cost structure and schedule.  I am in no way
> arguing correctness.
>> You are correct, or at least more so than I am. I am pointing out that
>
>> "correctness" can sometimes be so impractical that it leads to
> failure.
>> So, if you want correctness to succeed, it has to both be reasonably
>> easy to implement AND appear so to the journeyman developer.  So,
>> enough "theoretical correctness."  We journeymen need to be provided
>> with hard, real examples that meet specific functional problems.
>> Otherwise, prepare for irrelevance.  Standards geeks like Gary Ham and
>
>> Carl Reed will just be ignored, and developers will go on building
>> non-standard stuff that just "works."
>>
>> The good thing about the contents you provided is that there is an
>> example for each of the schemas provided in the document.  The bad
>> thing is that there are so many choices.  The chance that a
>> development project will cover the gamut of the choices decreases
>> exponentially with each extra choice provided. The only way to get
>> around that would be to build some kind of very complicated
>> "information hiding" software to make implementation of the choices
>> easier.  It is going to be interesting.
>>
>> Respectfully,
>>
>> 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
>>
>> -----Original Message-----
>> From: Carl Reed OGC Account [mailto:creed@opengeospatial.org]
>> Sent: Sunday, April 02, 2006 11:00 AM
>> To: emergency@lists.oasis-open.org; Rex Brooks
>> Subject: Re: [emergency] RE: OGC UoM Best Practices guidance
>>
>> Gary and Rex -
>>
>> Fully understand. The OGC UoM and related Observations and
>> Measurements work have been designed to insure that ALL metadata for a
>
>> given measurement (say from a sensor) can be accurately captured,
>> encoded, and communicated. The OGC members have determined that for
>> our standards work related to sensors etc that we must insure that the
>
>> accuracy of measurement semantics, measurement precision, and
>> measurement accuracy and so forth must be accommodated. This does not
>> mean that an application needs to use all of the capabilities - just
>> that that they must be there if needed. Much of this decision has to
>> do with the level of ambiguity that an application can live with. This
>
>> is why UoM is important.
>>
>> Anyway, attached is the latest OGC Observations and Measurement
>> document.
>> The members approved release of this Discussion Paper last month. Has
>> not yet been posted to the OGC web site but will be soon.
>>
>> There are numerous examples showing how UoM can be expressed as part
>> of a larger sensor observation encoding payload. Also shows use of
>> GML, O&M and UoM used in concert.
>>
>> Not sure if this will make Gary's life any easier :-)
>>
>> Cheers
>>
>> Carl
>>
>> ----- Original Message -----
>> From: "Rex Brooks" <rexb@starbourne.com>
>> To: "Carl Reed OGC Account" <creed@opengeospatial.org>;
>> <emergency@lists.oasis-open.org>
>> Sent: Wednesday, March 29, 2006 9:32 AM
>> Subject: [emergency] RE: OGC UoM Best Practices guidance
>>
>>
>>> At the risk of catching a ration of flame from most all sides
>>> involved
>>
>>> with this discussion, I tend to favor two ways of dealing with units
>>> of
>>> measure:
>>>
>>> 1. Specify that uom be specified either in the specification or that
>>> each implementation must specify what uom it uses, mandatory--and in
>>> web services, you just don't partner with companies whose uom in
>>> their
>>
>>> wsdl does not match up with yours; 2. Specify metric system, period.
>>>
>>> Both are aimed at letting the marketplace enforce the standard, but
>>> Darwinism has a bad name in these parts, since it inevitablly means
>>> letting chips fall where they may, and in these parts chips are
>>> people
>>
>>> so both of these are non-starters.
>>>
>>> In the choice arena between the concerns of programming realities on
>>> the ground versus getting critical information correct in critical
>>> moments, I tend to fall on the side of insisting on putting the
>>> burden
>>
>>> on the quality assurance cycles in software development and test the
>>> bleep out of every last thing and just keep testing till it works 95%
>
>>> of the time. (Reality says 80% flies, but in this case, I have to
>>> remind folks that in these parts chips are people.)
>>>
>>> Ciao,
>>> Rex
>>>
>>> At 10:42 AM -0700 3/28/06, Carl Reed OGC Account wrote:
>>>>As I mentioned.
>>>>
>>>>
>>>>Carl Reed, PhD
>>>>CTO and Executive Director Specification Program OGC
>>>>
>>>>The OGC: Helping the World to Communicate Geographically
>>>>
>>>>---------------------
>>>>
>>>>This communication, including attachments, is for the exclusive use
>>>>of
>>
>>>>addressee and may contain proprietary, confidential or privileged
>>>>information. If you are not the intended recipient, any use, copying,
>
>>>>disclosure, dissemination or distribution is strictly prohibited. If
>>>>you are not the intended recipient, please notify the sender
>>>>immediately by return email and delete this communication and destroy
>> all copies.
>>>>
>>>>"The important thing is not to stop questioning." -- Albert Einstein
>>>>
>>>>
>>>>Attachment converted: Macintosh HD:Units_of_Measure_Rec#10783E.pdf
>>>>(PDF
>>>>/<IC>) (0010783E)
>>>>---------------------------------------------------------------------
>>>>To unsubscribe from this mail list, you must leave the OASIS TC that
>>>>generates this mail.  You may a link to this group and all your TCs
>>>>in
>>
>>>>OASIS
>>>>at:
>>>>https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.ph
>>>>p
>>>
>>>
>>> --
>>> Rex Brooks
>>> President, CEO
>>> Starbourne Communications Design
>>> GeoAddress: 1361-A Addison
>>> Berkeley, CA 94702
>>> Tel: 510-849-2309
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this mail list, you must leave the OASIS TC that
>> generates this mail.  You may a link to this group and all your TCs in
>
>> OASIS
>> at:
>> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>>
>>
>>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>