[QUANTITY] Why quantities sometimes have errors

[Doug Tody]

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