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

 


Help: OASIS Mailing Lists Help | MarkMail Help

unitsml message

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


Subject: Re: [unitsml] Identity of units


Stuart, thanks for the input.

Quoting Stuart James Chalk <schalk@unf.edu>:
> I agree that this kind of issue needs to be resolved before 1.0 is   
> released. (...)

IF we can resolve it, that is :)

> The work that was done on development of the InChI string by IUPAC  
> has  done a lot to show the importance
> of having a unique identifier for something that can be represented  
> in  a number of ways.  Can we not do the same
> thing for units?  I think so - consider the following as a   
> representation of the Newton
>
> m[+01]kg[+01]s[-02]K[+00]A[+00]mol[+00]cd[+00]
> (...)
> m[+01]kg[+00]s[-01] (m/s)
> m[+01]kg[+00](6.0E+01)s[-01] (m/s)
-> m/min ?
> m[+01]kg[+00](3.6E+03)s[-01] (m/hr)
> (...)
> (1E-06)m[-03](1E-03)kg[+01]s[+00]K[+00]A[+00]mol[+00]cd[+00]#conc
> (1E-06)m[-03](1E-03)kg[+01]s[+00]K[+00]A[+00]mol[+00]cd[+00]#density

Well, I see what you're aiming at, but I think there's a misunderstanding
here. What you have described so far are canonical representations
of the dimensionality of quantities, and with the final two examples,
quantities themselves. As your concentration and density example
shows, (see, physicists, it not always has to be torque!:) we cannot
decide on units being "alike" by just looking at their dimensions.
But I am referring to units, which take part in different quantities.
When are two units themselves the same? This brings up another
tangent issue: Do we want users to markup their numerical values
with units only, or do we want them to mark it up with unit and
quantity measured? I.e. is that what the guidelines say a user
SHOULD do? Because I somewhat agree: with having unit and quantity
the issue of comparing the two things gets easier.

But then again: What would you do in face of, say, different versions
of the same unit? Say, we have the kilogramme unit and the
new-fancy-kilogramme which no longer is defined by an artifact
(yeah, a bit of SciFi here), and we have two measurements of the
'weight' quantity, same dimensionality obviously, one using the
ancient, the other using the modern kg. Can we combine the two? By
the strategy so far, the algorithm would say "yes". Another tangent
point: will we extend the EnumeratedRootUnits list? What about
versioning? What will the EnumeratedRootUnits thing "kilogram"
point to, once the new kg comes out? The new one? the old one? will
the string change? Do we want a stance on that before "1.0" ?


> OK, so maybe this would be useful but how to implement?  Well, any   
> validator used to work with OM or UnitsML
> would need to convert the representations to this common format.    
> Rather than code this on a case by case basis it
> would be much better to have a web service that would take in both   
> formats and send back the unique string format above.

actually I think calculating the above by using a stylesheet is
easy enough. If there is interest in using this representation, we
can offer a stylesheet which can be downloaded from the tools
section on the unitsml homepage. We can also include any number of
helpful stylesheets (to text, to html, to canonical text representation,
for conversion, ...) in any unitsDB returned content btw.

> Of course it could also have a compare feature and return yes/no if   
> they are the same.

when having a stylesheet like this, comparing the two outputs then
is trivial...

...whereas, of course, having a webservice invoke that stylesheet can
be helpful at times, too!

-Martin

PS: to sidestep the reply of Bob: Indeed xml:id does not allow for
punctuation characters from within ASCII other than _, - and .



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