[Passband] a useful self-contained model? modelling data vs implementing

[Martin Hill]

Hi David -

This approach (ie finding a generalised *implementation* to be put in the 
*model*) is actually what I'm trying to avoid! Instead I'm trying to discover 
the different forms that our data takes, and how it needs to be presented for it 
to be useful.  Thus we model the data.  If that data in practice is routed 
through some generalised mapping system that is fine, but it's not part of the 
*data modelling* process - though it might be presented as a proposed 
*implementation* model.

I realise some of these terms are now getting overloaded; 'implementation' for 
example occurs at several levels right down to the instantiating the structures 
in code.  Similarly we can 'model', using UML, right down to class & method 
level.  Here however I'm considering 'data models' as representations of the 
concepts we have of our data, not how it is actually stored in this or that 
database, or how it might be coded.

 From the point of view of modelling (as I rather quickly presented at the end 
of the DM3 meeting in Boston), the generalised bit should be placed in the 
'Interface'.  The interface defines what the passband will look like to things 
that use it.  When it comes to describing the different 'Classes' of Passbands 
(eg SimplePassband, GraphPassband) these are implementations of the interface 
and represent our *concepts* of varieties passbands.  The code (the 
implementation of the data model) does not have to follow these classes, and 
could well be written using a generalised Mapping model as you have done.

But to model our data, we first need to write down the way our Passbands are 
stored in databases, in documents and in our heads.  This is the bit I want to 
write down in the data model; we can look at generalised approaches separately 
(and concurrently!).

 > want to use in a PassBand. Your current definition of a PassBand
 > effectively restricts PasssBands to using a specific list of Mapping types.

Hmmm not really.  We can create *any* new Passband-implementing class we like as 
long as it conforms to the Passband interface; so the bit we need to check is 
whether the interface is Good Enough.  Not Perfect, just Good Enough...

 > Another consequence of this approach is that it requires a whole new
 > subclass if someone wants to use a Mapping which you havn't thought of.

Yes - just as we would need a new Mapping of some sort if something comes up we 
haven't thought of.  Because Passband is an interface, we can add anything we 
like and it won't affect the rest of the structure.

Again, I emphasise that here I am attempting to model the data.  It may be that 
Mapping is so general it will cope with anything any Einstein ever comes up 
with; but first I would like to see us write down as fully as possible what data 
we have and expect, and how it relates & interacts with itself.

NB, the following are *all* implementation issues.  Even the change of passrate 
-> transmission is to do with how you build a code library rather than model the 
data.  Of course, it is preferable to match the code to the model, but if the 
library is being written for use only by people who use the term 'transmission' 
rather than some other one, it makes sense to use that term.

Particularly think about what happens if someone writes a library to represent 
these models in FORTRAN - there may well be many changes of terms, and some 
things that cannot map directly to the model.

Similarly think about how Passbands might be stored in existing databases - 
these too are likely to use different terms

So first lets consider how to model our data.

(Comments on your implementation below)

Cheers

David Berry wrote:

> To illustrate my ideas I have knocked together a quick Java implementation
> of PassBand based on the JNI interface to the Starlink AST library
> (serialisation not yet included). The JavaDocs are at:
> 
> http://www.starlink.ac.uk/~dsb/VOpassband/
> 
> and the code is at:
> 
> http://www.starlink.ac.uk/~dsb/VOpassband/PassBand.java
> 
> It compliles and runs and passes the simple tests in the "main" method. I
> have based it on the current contents of your PassBand page, but I have
> taken a few liberties:
> 
> 1) Some trivial names changed (e.g. "passrate" goes to "transmission")

Interestingly some people seemed to prefer passrate because it was 
discipline-neutral - ie, no-one used that term :-).  I'm not sure it's better to 
have something that belongs to one discipline or something *no-one* understands!

> 2) My API is neutral about the spectral system in use, so I have changed
> Max/MinWavelength to Max/MinSpec. The calls indicates what spectral system
> they want to use by invoking the modifySpecFrame method on the PassBand.

What happens when a Passband instance is held by two different objects, one of 
which sets the SpecFrame and gets a value, the second sets the SpecFrame to 
something different and gets a value, and the first gets a value expecting the 
SpecFrame to remain the same?

I agree that Max/MinWavelength is too specific, and would normally have left 
them 'Fravergy' based but that's difficult when you want a Min/Max! The concept 
remains sufficient for the model however, and implementors might well add 
Max/MinEnergy, Max/MinFrequency, etc depending on their area. Perhaps a 'Limits' 
that returns a pair of Fravergies.

> 
> 3) There is only a single PassBand class, instead of having many different
> subclasses for simple, graph, formula, chained, etc. All these types are
> modelled in the same way - as a Mapping and a Frame - but each type has a
> dedicated PassBand constructor.

Hmmm no... all these types are *implemented* in the same way...

> 
> 4) I have also done away with the idea of the Photon and Wave classes.
> Instead, each PassBand expects input spectral values in a user-specified
> spectral system which may be changed at any time by invoking the
> modifySpecFrame method. This means that arrays of primitives can be used
> instead of arrays of Objects to hold the spectral positions.

See above about problems of state with objects.  Also, submitting 
'Fravergy'/'Photon' objects as parameters doesn't stop us using primitives 
internally; a Passband could well be implemented as a set of primitive points 
representing probability vs wavelength, and internally it would use the 
Wavelength property of the submitted Fravergy to work with.

Cheers!  And thanks for your effort on this, I think it will be useful as a 
particular implementation approach.

Martin

-- 
Martin Hill
www.mchill.net
+44 7901 55 24 66