[Observation] draft observations

[Martin Hill]

Hi all, 

Comments on [Observation] v0.2:

Personally I'd like a little more in the Scope section about where 
Observation starts and stops, and where this particular document starts and 
stops.  Eg, it will model the data used to describe an observation, rather 
than model the measurement's made from the observation (if I have it right!)

More generally, I think we need to be careful about using the term 'metadata' 
- one application's data is another application's metadata.  Perhaps wherever 
metadata is used we should add 'of Xxxxx' so we know what data it's 
meta-ing....

Excellent diagram on p8 for non-techies like me; can it be placed near the 
table on p6?  And/or a reference to it in the text at the beginning of 2.3 
would make it easier to work through the prose.

I don't understand how the equation on p9 was built; what are the subscripts 
i and j? Are they just dimensions (position/time/energy, so we need more 
subscripts...) of some Photon measure x?  Which ones are which and how does 
subscript j turn up in the equation when it's not in the prose? I take it 
it's trying to say that the number of photons measured with a particular 
characteristic (pos, time, energy) is dependent on the number arriving, the 
proportion of those detected and the proportion that are smeared to other 
values of the same characteristic.  Is this enough?  Don't things get smeared 
between axis for example (ie pos might smear in both spatial axis, high 
energy photons might cause smears in pos).

(p13, para 5) If Calibration is a Mapping that changes UCD/Units/Accuracy 
then this could be difficult to implement under the current Quantity model.  
Is this a case for a QuantityMapping?

p13/14 bullets 1-3 - Can we leave modelling the Universe until later?!  We 
need to model our data first :-)  But seriously, this seems to be drifting 
into modelling object catalogues.  I agree that object catalogues should be 
related to Observations, so that we can search/process based on object 
characteristics as well as observations, but can we model it separately?

(p14 sec 3) Is this just a way of saying that an Observation 
might be made up of other Observations ('Composite' design pattern)? And we 
might want to add ObservationCube and ObservationSomething as particular 
types of Observation?

(p17) two different diagram languages and they don't quite seem to match up 
:-) A few things:
    1) I'd rather the ObsData illustration wasn't there - it starts 
introducing a different model to the wrong document.  It works OK as a place 
holder.
    2) If Resolution and Precision really might 'belong to' many different 
Characterisations, we need to make sure they are immutable.  On the other 
hand, we could say one Resolution/Precision instance can only belong to one 
Characterisation which might be neater and seems more correct somehow - 
presumably Characteristics normally have different resolutions?
    3) Is ObservingConfiguration itself the ObsEltList?  What benefits do we 
get from having a separate List?

My apologies if some of this has been covered, I've had a run through my 
email box and didn't see anything like these.

Otherwise it makes sense to me as far as my astronomical knowledge goes, 
which is not all that far...

Cheers!

Martin

-- 
Martin Hill
Astrogrid/AVO, ROE
Tel: 07901 55 24 66