Data Model for Quantity v0.5
I keep it as short as I can, and go directly to the main comments. Many other detailed comments are available (read: scribbled onto the print out).
0.- Overall, I was expecting a document describing what a quantity is,
how a DM on a quantity could help out in various scenarios, how people will solve
otherwise unsolvable problems by using it. Hence I would have liked to see
what are the problems to be addressed, and what are the suggested solutions.
And all that, much before discussing "classes", "instances",
"interfaces", etc.
0a.- Context
A use case mentions: "Describing a scalar value and its context" I found weak the way the context gets described, since it relies completely on a UCD.
(In that sense, the model is not very far from the "FIELD" definition in the VOTable)
0b.- Compatibility issue (context-related)
How do I know whether two quantities (fetched from different providers) are "compatible"? Of course "compatibility" first needs a definition ... In the document such problem is mentioned, but not addressed, and I think it is
a problem which has probably the highest priority, if we want to exchange quantities.
UCDs are referred to, but "compatibility" is a different matter; example:
I got two quantities, one is the isophotal diameter of a galaxy at the limiting
surface brightness of 25 Bmag/arcsec2 the other is the diameter but at a limiting
24Bmag/arcsec2. They have the same units, and, correct me if I'm wrong, the same UCD.
But they are incompatible. I cannot take the average of those two quantities,
'cause they physically mean something else.
0c.- UTYPE is not mentioned (could be the solution to the compatibility/context issue)
UTYPE is thought to be the solution for "compatibility" issues (in the VOTable context at least). Maybe the Quantity DM is not the right place
to define this, but then, where?
1.- Language English and OO-speak are intermixed
I love the RM (registry) document; it's in pure english, hence it is not implementation/philosophy-driven. If you cannot really abstein from using terms like "classes, interfaces, instantiations"
at least define them in the introduction.
2.- UCDs are briefly mentioned here and there; UCDs and their relationship
with the Quantity DM probably require more attention, and deserve a full chapter.
Only then we will be able to identify flaws or unnecessary redundancy.
3.- When speaking of coordinate systems, what's the relationship with STC?
4.- Requirements (chapter 3): could you group/highlight different kind of requirements?
I can see High Level Quantity reqs, Architectural reqs, Tool reqs ...
5.- May I propose to introduce all the various quantities (Core/Basic/Standard)
before they get referred to? It would greatly improve the readibility of the document.
6.- In the example 2 on page 26 the Magnitudes are given without reference to a bandpass,
and its zeropoints. How would you see that done properly?
7.- In the various examples various units are given (eg, "km s^-1", etc.)
We should have a standard set of allowed units and a standard set of operators.
At CDS (or is it the standard SI?) a blank is not allowed, multiplication is a dot "."
exponent is just concatenated, etc.: the right spelling would be
"km.s-1"
We have to have a common set of rules and names to interoperate. This should
be mentioned in the document.
Moral: it's easier to criticise a document than writing it ... :-)
Alberto Received on 2004-05-03Z17:44:40