[QUANTITY] Quantity "arguments"

[Doug Tody]

On Fri, 14 Nov 2003, Steve Lowe wrote:
> I think what is missing is requirements.

Component-level requirements are needed, but we need to back up one
step further and define an architecture which lays out what the data
model components (such as quantity) are, and what their role is in some
larger scheme.  What keeps happening in these discussions is that people
have very different views of the scope or role of a component and start
trying to include functionality which belongs elsewhere.  Pretty soon
what started out as a simple component has morphed into some grand vision
(more likely several) that encompasses far too much.  It is possible to
make some progress without a fully developed architecture, but only if we
focus on defining some simple components for which we have some immediate
use in mind.

On Fri, 14 Nov 2003, Pierre Didelon wrote:
> I totally agree, and that's why I am in favor of a VERY simple
> QUANTITY DM, like the one you proposed at the beginning,
> otherwise we will never converge.
> Make the simplest object possible, on which agreement will
> be reach faster than on beautifull (but complex) one.
> Complexity will be introduced via composition or
> agregation, like your measurement and othres concept.
> I tink it is the best path to real DM progress.

Exactly so.

	- Doug



On Fri, 14 Nov 2003, Steve Lowe wrote:
> I think what is missing is requirements.
> 
> What I don't see in these discussions is a process that starts by 
> listing in detail what the model has to do. What seems to happen is that 
> we start with a vague idea of some desirable features, then jump 
> immediately to a specification of classes and attributes. This starts to 
> lock in design decisions too early, which leads to arguments. In many 
> cases, the argument seems to be just about the *place* in the model 
> where a given capability is locked in.
> 
> What is needed are written, detailed requirements derived from examining 
> data analysis algorithms and existing data sets (use cases). The 
> documents of this sort that I have seen so far seem superficial and 
> short. Much more detail is needed. No doubt much of this information is 
> out there in the heads of the folks in the group. But it is not out 
> there on the table so that all the case can be in everyone's heads.
> 
> And if producing this documentation seems like a big job---well, yes, it 
> will be. But why can't it be considered a tangible work product in 
> itself, at least as valuable as the next demo?
> 
> Steve
> 
> Patrick Dowler wrote:
> > While I'm sure all this is very interesting, it seems way off topic to me. I 
> > am sure that's why only two people are left standing.
> > 
> > In the simple Quantity model that I put forward (somewhat privately, but that
> > didn't last long :-( I tried to draw from all the available approaches and 
> > ideas to make a "consensus". Of course, some ideas did not get included 
> > because they were logically inconsistent with others that were more commonly 
> > held, more valuable, more aesthetic, etc. 
> > 
> > The problem with this whole discussion is that it has degraded into "here's MY 
> > model - see how I did it right" with a response like "yeah, but here's MYYYY 
> > model, and it's pretty cool too". This gets us nowhere. 
> > 
> > At some point, people have to leave their models at home and provide 
> > constructive criticism of the idea on the table. If something is missing, say 
> > exactly what is missing. If something is wrong, by all means point it out.
> > But bringing a whole new model to the table doesn't help.
> > 
> > So far, I have seen nothing on this list since ADASS that hasn't been said 
> > before - either during the summer, at the Cambridge meeting, on a poster as 
> > ADASS, or private communication. Yet my dm at ivoa.net mailbox is filled with 
> > messages (on average 20KB!!!) not discussing the same thing.
> > 
> > my 2c (and 2c canadian isn't very much),