[QUANTITY] Pulling it all together - missing some things
David Berry
dsb at ast.man.ac.uk
Mon Jun 2 04:10:47 PDT 2003
On Fri, 23 May 2003, Brian Thomas wrote:
> David, all,
>
> After reading this, I saw that it is missing some important meta-data. To illustrate,
> I fall back on XDF, where "quantity" looks like "parameter" which holds one or more
> "values". Parameter has the means to specify things like inequalities and special
> computer-oriented meta-data like NaN, which you can see in this snippet of the
> XDF dtd for example:
>
> <!ELEMENT value (#PCDATA)>
> <!ATTLIST value
> valueId ID #IMPLIED
> valueRef IDREF #IMPLIED
> special (infinite | infiniteNegative | noData | notANumber | underflow | overflow | disabled) #IMPLIED
> inequality (lessThan | lessThanOrEqual | greaterThan | greaterThanOrEqual) #IMPLIED
> positiveErrorValue NMTOKEN #IMPLIED
> negativeErrorValue NMTOKEN #IMPLIED
> >
>
> You already have errors taken care of, but are missing the "special" and "inequality"
> stuff. Special numbers are those which the computer may represent by a certain string,
> say "-9.99" but wont be recognizable as "notANumber" without the meta-data to point it out.
> Ditto for doing any "censored" data that involves upper/lower - limits. This is handled by
> the "inequality" meta-data.
> ...
The document I produced describing the Starlink approach to Quantity was
intended to outline the main points of the scheme. As you say, there are
many other points which it doesn't mention, such as bad value handling
and documenting limits on the numerical quantities. There are also some
others such as how to format and unformat values, preferred labels, etc.
I kept all these things out in order to simplify the document and focus
attention on the principle of producing a hierarchy of classes describing
different physical domains.
To answer your two specific points:
1) Bad value handling: for numerical values in memory we use agreed bit
patterns to represent "missing" or "bad" values. These bit patterns are
in general specific to the machine architecture. For transportation
between machines, we use a text-based format in which an agreed string
("bad") is used to represent bad numerical values.
2) Data limits: Each Domain can (optionally) have a specified upper and
lower bound outside of which values are treated as if they were "bad". I
agree that in general, you may want to specify constraints in a more
general way, but as yet we have found no pressing need for it in the
applications we have produced.
David
More information about the dm
mailing list