[QUANTITY] Why quantities sometimes have errors
Martin Hill
mchill at dial.pipex.com
Mon Nov 17 10:40:13 PST 2003
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
More information about the dm
mailing list