[QUANTITY] Why quantities sometimes have errors

[Martin Hill]

Agreed entirely that not everything should be created/thought of using 
an *inheritance* structure.  But a defined association of classes *is* a 
class structure...

(Mr Picky picky)

At first site it seems that [QUANTITY_WITHERR] *is a* [QUANTITY] and 
*has an* [ERROR] ?


Doug Tody wrote:

> Another thing to keep in mind here is that everything does not have to
> be done via some formal class structure.  A rigid class structure leads
> to an attempt to define an all-encompassing global data model which will
> never work at the scale of the VO.
> 
> An alternative to a class or subclass is association.  Association means a
> "has a" relationship rather than "is a".  An "Image" "has a" data array
> and it "has a" WCS which we associate at a higher level to model Image.
> A measurement "has a" value and it "has an" associated error.  A measurement
> value "is a" Quantity.
> 
> Both subclassing and association are needed to model data.  Subclassing
> binds classes very tightly together.  Association is much more flexible
> as the relationships do not have to be predefined and can be many-to-one.
> This reduces complexity and encourages reuse.
> 
> In general we want to rely upon subclassing mostly at the lower levels,
> preferring association at the higher levels where we attempt to model
> entire complex datasets and reuse components.
> 
> Doug
> 
> 
> 
> On Mon, 17 Nov 2003, Martin Hill wrote:
> 
> 
>>If at the design stage we can see a set of situations where a component 
>>of a class will be unused, we should remove that component and place it 
>>in a subclass.  It seems we agree there are places where this is so (for 
>>example, in constructing a cone search?)
>>
>>So it makes sense to me (as a developer) that you have a quantity 
>>without error, and a subclass that includes error.  Errors too will 
>>require a heavy duty definition and no doubt a lot of discussion on this 
>>forum...
>>
>>I do understand that we need to encourage people to include errors. 
>>That however must be done at the stage where we define our particular 
>>data models where errors are important.  By having with and without 
>>error classes, we can force errors to be included - by including the 
>>[QUANTITY_WITHERR] class.   If we use instead our generic [QUANTITY] 
>>class that has an optional error, we do not enforce anything - people 
>>can (and will) just set that error to null.
>>
>>Cheers,
>>
>>Martin
>>
>>DIDELON Pierre wrote:
>>
>>>>From brian.thomas at gsfc.nasa.gov Mon Nov 17 18:31:06 2003
>>>
>>>>From: Brian Thomas <brian.thomas at gsfc.nasa.gov>
>>>>To: DIDELON Pierre <dide at discovery.saclay.cea.fr>
>>>>Subject: Re: [QUANTITY] Why quantities always have errors (Was: Re: [QUANTIT] Use-cases, role in larger scheme)
>>>>Date: Mon, 17 Nov 2003 12:30:22 -0500
>>>>User-Agent: KMail/1.5
>>>>Cc: dm at ivoa.net
>>>>MIME-Version: 1.0
>>>>Content-Transfer-Encoding: 7bit
>>>>Content-Disposition: inline
>>>>
>>>>On Monday 17 November 2003 12:14 pm, DIDELON Pierre wrote:
>>>>
>>>>
>>>>>If you have to pass a parameter to an application, to specify some input
>>>>>value, you may need to transmit a value (without error), it can even be a
>>>>>flag. This is a very immediat example, and we can not rule out in VO (IMO),
>>>>>the usage of numbers without error, once for all,
>>>>>even if today it seems more natural to you,
>>>>>SOME PEOPLE outside here want to use numbers without errors,
>>>>>and ask for that possibility several times on the list (and off the list),
>>>>>and it would certainly be appropriate in some cases.
>>>>
>>>>	This can be resolved by simply choosing a sensible default meaning
>>>>	for the error == NULL.
>>>>
>>>>	I suggest that if an error isnt present (e.g. returns null), then its meaning 
>>>>	is "error, unknown". If you want to create a 'constant' then you would get
>>>>	something else, e.g. quantity->getError() returns "ExactNoError" class.
>>>>
>>>>	And its a pretty trivial detail of construction of the class, I think in terms
>>>>	of implementation. Say you want to create 2 classes that embody "hardwired"
>>>>	errors (so implementer doesnt need to thinik about the errors), such as 
>>>>	"constant" and "parameter",  then, assuming a quantity interface, we have:
>>>>
>>>>	class Constant implements Quantity {
>>>>
>>>>	ErrorType getError () {
>>>>		return new ErrorExact();
>>>>	}
>>>>
>>>>	}
>>>>
>>>>	and for your "parameter":
>>>>
>>>>	class Parameter implements Quantity {
>>>>
>>>>	ErrorType getError() {
>>>>		return new UnknownError();
>>>>	}
>>>>
>>>>	}
>>>>
>>>>	Regards,
>>>>
>>>>		=b.t.
>>>>
>>>>
>>>>-- 
>>>>
>>>> * Dr. Brian Thomas 
>>>>
>>>> * Code 630.1 
>>>> * Goddard Space Flight Center NASA
>>>>
>>>> *   fax: (301) 286-1775
>>>> * phone: (301) 286-6128
>>>>
>>>>
>>>>
>>>
>>>WHY?
>>>why trying to complicate the smallest and simplest things?
>>>Why not admitting the co-existing of 2 classes, one using the other?
>>>Why not let the one who want to play without error to do so?
>>>Pierre
>>>PS: last mail of today... I'm going home.
>>>
>>
>>
> 
> 

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