[DM] Plea for constructive progress (Was: Re: [QUANTITY] Plea for pragmatism)

[Brian Thomas]

	Hi Alberto!,

	I'm sure you (and others) will appreciate that I will try to limit myself to 
	one (dm mailinglist) email on this subject.

On Wednesday 29 October 2003 05:52 am, Alberto Micol wrote:
> [snip]
> At this point my feeling is that we are going nowhere.
> All these discussions about quantities  are too phylosophical for me.

	But not for me, and I believe others on this list. Would "silence" be a measure
	of progress then?!?

	I think this is a difference in software design approach between us. It *does* 
	take a significant amount of time to go through the steps of use-case/requirement/
	analysis (URA) before getting to "design". However, once done, the design goes 
	quickly, and, more importantly, does not have as many re-designs over time.

	For small projects, or even medium ones which are geographically isolated,
	you probably don't need to do these things in part because agreement comes 
	quickly, or the structure is simple. But in the case of large projects, and/or complex
	algorithms, like the overall data model for the VO, it is highly important. This
	*is* an established method of software design, and, *is* shown over and over to
	work. I have personal experience with the success of this approach in this
	environment (distributed complex software project).

	You have already asked, along with others, "why haven't we made	
	any progress?". One possible conclusion is that the step of URA is
	wasting time. But that is not my conclusion, rather, I hope, without offending too many
	people on this list, I say that I see an incomplete, and unrigorous approach to URA 
	modeling going on here in the past. What evidence of this? 
	1) there are no gathered use-cases in one place for all to look at 
	2) there are no gathered requirements either
	3) there has been no comprehensive analysis of said requirements
	As far as I can tell, no actual URA work, for any step, has actually been brought to 
	completion (yet). Thus I further conclude that its premature to actually design
	"the" data model. You can't skip steps and expect success.

	I *have* seen a lot of highly specific, disconnected statements about what
	a Data model is. Occasionally a data model, targeted at some random domain
	pops up, is often "dissed" or ignored, and then disappears from view. This type 
	of "work" (as we all have found) is extremely hard to  string together to make into a
	comprehensive model. 

	For all these reasons I conclude that starting from a more general, and abstract, 
	direction  using URA is needed. Otherwise, we all descend rapidly into implementation 
	arguments on various minutia or just ignore the others needs. In my opinion, and 
	experience, a formal design process is the only way to make such a project "work". 
	Otherwise we tread the path of FITS and will see a data model in about 10-20 years.

	Having said that, I DO agree that the observational models are "king", and 
	will have the most important role as they shape the "component" level as well as 
	the basic (quantity) level. I don't believe its rocket science that we can't (at the quantity
	level) anticipate what these models will look like (certainly some are already
	extant in the form of "FITS"). If I may speak for the quantity "community", we
	DO have a common understanding that the scope of quantity includes numbers
	which must be scientifically described. The "argument" going on right now,
	(and I assure you that much of it has been off the list), is about whether this
	scope is too limited (expand quantity to include strings..higher dimensional 
	structures, etc) and what exactly is needed for "scientific" numbers and their
	exchange. 

	Also, there is nothing that is preventing the design of the observational models 
	right now (which I suppose embodies everyones "local" set of use-cases), or 
	from people coming forward with their designs so that they may be compared, 
	requirements derived, and further analysis done (especially to identify components).
	As I am not designing any of those models (my archive is for published, not
	"observed" data)  I do not present them.  

> We need to focus on what we want to achieve, provided that it is clear
> to everybody what the goal is. I might be wrong, but I do not think that
> the goal is well identified within the group. (After all, this is why I
> called
> for user cases).

	I completely agree with this. I am willing to help collate cases too. 
	Please let me know how I may help you.

>
> Requirements should describe what is to be achieved, and not
> which class is associated with what, or who inherits from who.

	No. That is not the CS definition of a requirement and the last part
	sounds more like what a design diagram does.

>
> In all cases, I do not find useful to start from the Quantity level.

	That is fine. We all don't all work the same way however. Please present 
	your observation model. Others should too.

>
> I thought that it was decided that we start with Observational Data Model,
> and not with Quantities. That is certainly a much more pragmatic point
> of view,
> am I wrong ?

	That was not my exact understanding. My understanding was that we
	could, and would, start from both ends. With the "quantity" end having 
	the requirement that it "serves" the "observation" end of the model.

	You all in the "observation" camp, please get going, those of us on the 
	other end need to hear from you.

	Best Regards,

	=b.t.

>
> Alberto