Units of Measure

["Smith, Neal L. (NLSM)" <NLSM@chevron.com>]

Posting this on behalf of John Bobbitt.  

> -----Original Message-----
> From: John Bobbitt [mailto:bobbitt@posc.org] 
> Sent: Wednesday, May 30, 2001 7:14 AM
> To: Cutler, Roger (RTCU)
> Subject: Re: Units of Measure Comments from OASIS
> 
> 
> Roger,
> 
> Thanks. I even tried to reply to that message, but I keep getting bounced
> off as not being part of the mailing list.
> 
> So I gave up.
> 
> Here is the reply I tried to send:
> 
> "Here are some questions that have come up in the threads. And the
> answers.
> 
> First of all a comment. The paper that was submitted has a limited
> purpose. It is to specify how we handle a quantity type in XML. In
> particular, it specifies the use of uom as the abbreviation for units of
> measure, and specifies the form that a reference to a unit of measure
> should take. In addition, it gives a starting line for how to specify a
> unit of measure (the dictionary class). Don't try to extend the meaning of
> the paper beyond that.
> 
> Now the questions. 
> 
> Q: Did the paper consider Recommendation 20?
> A: Not directly. However, since the paper was finalized, I have read
> Recommendation 20, and find that the basic user requirement still holds.
> Namely, that there is no list comprehensive enough to satisfy the needs of
> all particular industries. Any method of handling units of measure must
> allow the specification of additional units.
> 
> Q: Are there units in use that are not in Recommendation 20?
> A: Yes. Here is an example.
> The US Government defines a meter to be 39.37 inches. Thus, a US Survey
> foot converts to a metre using the factor 12/39.37. This differs from the
> Recommendation 20 value of .3048 (the international foot) by 2 parts per
> million. Since legal measurements in the US are in US Survey feet, and UTM
> coordinates are in metres, it is necessary to convert back and forth.
> Consider a point half way to the pole (i.e., central US). It is 5000 km
> from the equator, or about 16 million feet. With an error of 2 parts per
> million, the Recommendation 20 definition of a foot will put the point off
> by about 32 feet. This is totally unacceptable in geodetics work.
> Note that this is only one of scores of examples. I don't want to go into
> deep detail on this point.
> 
> Q: If a unit is missing, can't it be generated by "composing" a new unit? 
> A: If so, please explain how to compose units to get the US Survey foot.
> It seems to me that the only way is to define it as a different unit with
> its own conversion factor. The same would hold true of a vara (of which
> there are seven types defined in US legal documents). 
> Another instance would be an API neutron porosity unit. All attempts to
> find a conversion factor for this have failed.
> 
> I stand by the two comments that have been made. First, that no standard
> dictionary is complete enough for the detailed user (and therefore we need
> to be able to extend to additional units). And referencing by symbol, with
> an assumed definition of the unit symbol, puts an unacceptable burden on
> the reading application (the reading application must understand EVERY
> symbol that might come up)."
> 
> John
> 
> "Cutler, Roger (RTCU)" wrote:
> > 
> > fyi ...
> > 
> > > -----Original Message-----
> > > From: Smith, Neal L. (NLSM)
> > > Sent: Tuesday, May 29, 2001 4:36 PM
> > > To:   Cutler, Roger (RTCU)
> > > Subject:      RE: Units of Measure
> > >
> > > Roger,
> > >
> > > I received lots of comments from the OASIS mailing list.  The most
> useful
> > > comments pointed out that there is an international standard for Units
> of
> > > Measure called UNECE Recommendation 20
> > > http://www.unece.org/cefact/rec/rec20en.htm.
> > >
> > > I see two ways POSC might handle this.
> > > *     Accept the UNECE list as standard and complete.  By default,
> > > QuantityType refers to an UNECE code, and cannot be extended.
> > > *     Accept the UNECE code list as one of the external code lists
> that
> > > can be referenced by a QuantityType.  Update the UoM documentation to
> > > indicate the availability of UNECE 20.  But - someone will have to put
> the
> > > UNECE 20 into XML so it can be referenced.  Presumably UNECE.
> > >
> > > Here's a link to the discussion thread in the ebXML archives:
> > > http://lists.ebxml.org/archives/ebxml-core/200105/msg00037.html
> > >
> > >
> > > -----Original Message-----
> > From:   Smith, Neal L. (NLSM) [SMTP:NLSM@chevron.com]
> > > Sent: Friday, May 18, 2001 9:55 AM
> > > To:   'ebxml-core@lists.ebxml.org'
> > > Cc:   Cutler, Roger (RTCU)
> > > Subject:      FW: Units of Measure
> > >
> > > Core Components Group:
> > >
> > > We have received the attached proposal for standard XML data
> > > representations
> > > for Units of Measure.  Is this something that could/should be
> expressed as
> > > ebXML Core Components?  If so, how do we achieve that?
> > >
> > > The proposal is from Petrochemical Open Systems Corp, a energy
> industry
> > > consortium.
> > >
> > > Neal Smith
> > > Chevron
> > >
> > > > -----Original Message-----
> > > > From: John Bobbitt [mailto:bobbitt@posc.org]
> > > > Sent: Monday, April 23, 2001 3:24 PM
> > > > To: XML Activity Group; GML Sig; Nicolai, Roel; Arliss Whiteside
> > > > Subject: Units of Measure
> > > >
> > > >
> > > > All,
> > > >
> > > > Attached is the recommendation paper for units of measure.
> > > >
> > > > It is essentially complete in its content, but is not complete in
> its
> > > > editorial view. In particular, it has not been formatted for any
> group
> > > in
> > > > particular.
> > > >
> > > > It is intended that this recommendation will be sent to several
> groups
> > > > (four, at present) with the request that they adopt the strong
> > > > recommendations. The four groups are POSC, OpenGIS, CSIRO, and W3C.
> If
> > > > anyone knows of other groups that should also consider adopting the
> > > > quantityType, please let me know, and we can include them also.
> > > >
> > > > [[Since it is to be sent to several groups, I have left the format
> > > > general. If any group needs the information to be put into a
> particular
> > > > format, I would encourage someone to do that (I don't intend to
> start
> > > > formatting for all the groups). Ie, I am looking for volunteers to
> > > > reformat the information contained in the document into whatever
> format
> > > is
> > > > necessary for the different particular groups.]]
> > > >
> > > > This recommendation is being sent early to members of these groups
> so
> > > that
> > > > we can work out differences of opinion NOW. It is not possible to
> have
> > > an
> > > > open forum of all these groups in order to discuss the proposal and
> work
> > > > out differences of opinions. That is why this is being done in a
> > > virtual,
> > > > open forum format, so that we can negotiate changes before the
> formal
> > > > submissions to these groups.
> > > >
> > > > Please express any concerns now, not later. And please do so to all
> the
> > > > groups in the mailing list. (Note: the mailing list includes CSIRO
> and
> > > W3C
> > > > representatives. So sending it to the above lists will catch some of
> > > those
> > > > also).
> > > >
> > > > My intent is to have all comment taken and incorporated by May 4.
> This
> > > > allows time to submit to the OpenGIS at least 3 weeks before the
> > > meeting.
> > > >
> > > > I am particularly concerned about ISO. The UML model they have for
> the
> > > > limited area of spatial and time units is entirely consistent with
> the
> > > > proposal. Yet I have seen no proposed schemas, nor have had no
> comments
> > > > from them concerning this implementation of their model. I fear that
> > > they
> > > > may come forth some day with essentially the same concepts, but with
> > > > different element names or different "element or attribute"
> decisions,
> > > or
> > > > a different units definition model. If anyone has any knowledge of
> the
> > > ISO
> > > > units model in these respects, it would be useful to share them with
> the
> > > > group.
> > > >
> > > > "Philosophic discussion"
> > > > You should note that I put a section of user requirements at the
> front
> > > of
> > > > the document. I feel that the user requirements must drive the
> ultimate
> > > > model. If a group has a particular requirement, it is up to us to
> meet
> > > > that requirement - it is NOT up to us to judge the requirement as
> > > > irrelevant. I have tried to meet every requirement given to me over
> the
> > > > last several months - sometimes with a single element or attribute.
> If
> > > you
> > > > can find some place where I have missed a user requirement, please
> let
> > > me
> > > > know, and we can change things to meet the requirement. If you find
> that
> > > > you have a requirement that is not listed (and not met), please let
> me
> > > > know.
> > > >
> > > > In some cases, the requirement is met by suggesting extensions (eg,
> list
> > > > of values, generalizing the conversion model, adding a precision
> > > > attribute). Please let me know about missing or unresolved
> requirements.
> > > >
> > > > John
> > > > --
> > > > John I. Bobbitt
> > > > Energy eStandards          Web: http://www.energyestandards.org
> > > > Off:(713)267-5174          Web: http://www.posc.org
> > > > Fax:(713)784-9219          email: bobbitt@posc.org
> > > > Many ideas grow better when transplanted into another mind than
> > > > in the one where they sprung up.    --Oliver Wendell Holmes
> > > > <<UomRecommendations.doc>>  << File: UomRecommendations.doc >>
> 
> -- 
> John I. Bobbitt
> Energy eStandards          Web: http://www.energyestandards.org
> Off:(713)267-5174          Web: http://www.posc.org
> Fax:(713)784-9219          email: bobbitt@posc.org
> Many ideas grow better when transplanted into another mind than
> in the one where they sprung up.    --Oliver Wendell Holmes