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

["Ham, Gary A" <hamg@BATTELLE.ORG>]

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.php
>
>
> --
> Rex Brooks
> President, CEO
> Starbourne Communications Design
> GeoAddress: 1361-A Addison
> Berkeley, CA 94702
> Tel: 510-849-2309
>