[QUANTITY] Data Model for Quantity v0.5

[Martin Hill]

I'll second Alberto on the general point that it's a very difficult document to 
read, and perhaps could do with a bit of 'plain english' applied.  However I 
know technical documents in this industry tend to obfuscate (what a lovely 
obfuscating word that is :-) and

 > Moral: it's easier to criticise a document than writing it ... :-)

is very true!

Cheers,

Martin

Alberto Micol wrote:

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

-- 
Martin Hill
Software Engineer
AstroGrid @ ROE
Tel: +44 7901 55 24 66
www.astrogrid.org