Re: [unitsml] Groups - Teleconference Minutes for Nov 14-23, 2007, Meeting (telecon20071114a.pdf) uploaded

["Gary W. Kramer" <gary.kramer@nist.gov>]

Hi folks,

I just listened to the audio of the November UnitsML meeting, which I missed 
due to a scheduling conflict.  It is encouraging to see that some folks from 
NPL will by joining and that Stuart Chalk might as well.  Stuart has been a 
participant in the AnIML adventure for several years.

I have a specific comment about a couple of points brought up in the meeting.  
The first concerns the definition fields and applies to those fields for both 
quantities and units.  These fields are essential and should contain the 
location of "the" authoritative definition of the term.  This is critical 
because term meaning differs across fields of interest.  Only a reference need 
be provided so that the user can look it up if necessary.  In AnIML we often 
just cite an ASTM standard or an IUPAC document.  If the definition we need 
cannot be found in standards, be do the best we can using a journal article or 
even technical information from vendors.  In these cases the call as to 
whether such a definition is "the" authoritative reference becomes that of the 
subcommittee.  If someone wishes to challenge that call, well, that's what 
five year revisions are for.  The fact that the location of "the" 
authoritative reference may change as such references are updated means that 
there will be a maintenance issue for UnitsML, but the good news is that these 
seem to change about once a decade, so this should be manageable.

My second comment concerns "QuantityML."  While the notion of dealing with 
quantities in a second markup language seems attractive (primarily so we can 
duck having to do this in this UnitsML TC), I don't believe that this is a 
workable solution.  Units and quantities are just "too joined at the hip."  If 
we had a UnitsML and a QuantityML, each would be rather useless without the 
other, updates to one would likely require updates to the other, and if they 
ever got out of sync, we'd have a mess.  I'm convinced that we have to include  
the markup for quantities in UnitsML.  The treatment of quantities will be 
different from our treatment of units largely because we have no hope of ever 
enumerating all possible quantities in a database such as UnitsDB.  Our 
treatment of quantities probably will consist only of delineating how quantity 
information should be marked up, but that's likely all that can be done for 
quantities anyway.

Cheers,

Gary