[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]