Some very belated comments - sorry!
I appreciate the way that the model was drawn up with reference to some real source catalogues. However, I think that some of the fields suggested are too 'fine grained'. I note these below. Maybe that means that there is a need for a heirachical model with generic properties at the top level and more domain-specific properties in optional plug-ins. The use case which I am thinking of arises from RadioNet discussions about a Common Proposal Tool, and what we need to specify an observing target.
What sruck me was that I imagined that the model was 'source-centred' - i.e. it should aim to provide information about an astronomical detection _or_ a generic model object - but it should not duplicate the role of the Observation and other DMs.
Detailed comments:
Morphology
Distinguish between observational properties and classifications!
Observational properties are maybe major and minor axes and position angle
(which is conventionally measured from N through E, I am sure that this is
defined in STC), or alternatively a series of vertices to define a polygon
(for very large objects like molecular clouds or 3C radio galaxies...)
This morphology is specific to a particular wavelength domain (and possibly resolution) so this needs to be tied.
Classifications like Galaxy should be a completely separate set of
elements - at the moment you have 'AGN' as a place holder, I suggest that
there is an element like
sourceClassification to hold this place - or in fact it is covered by
"type"? This should be simplified to come in one place, anyway.
Orbit
My inclination would be to just have a flag whcih says if this is relevant
- in fact, maybe it should be just "d(position)/d(time)" - to cover other
kinds of proper motion - and provide a link to an ephemeris or other
source of information. In fact maybe this should all come under the
properMotion object.
Note that, thus, no all objects have a coordinate-based IAU name (although there are other conventions)
Similarly there should be a "d(flux)/d(time)" element which just provides
a link e.g. for variable stars.
"varAmplitude" etc. are both too specific (for a generic source model) and
too vague (to actually observe you need to know the time of phase zero
etc. Also they are wavelength-specific.
Thus I just want a flg and a reference to say if I need to look at the possibility that an object moves or varies with time - not a crude summary which will probably be misleading.
We have to be careful that we are allowing people to find and use data and resources - not duplicagte them!
SED
Maybe Jonathan has some ideas on this, but otherwise I think that what we
need is
a) Flux density/wavelength data - but we don;t want to get
too complicated, maybe just one value per Registry bin (radio-mm-IR
etc...) - there should also be a reference for each value. Resolution and
limiting noise could also be given
b) If high resolution spectra (i.e. relating to molecular,
atomic/electronic, nuclear or other line transitions) are available -
links
"snr"
This is only meaningful for a specific observation and would be coverd by
SED a)
"detectionProbability" and anything that speific belong in individual
observation models.
The same goes for many of the detailed attributes lower down in the model.
I hope that this is not too disruptive, I think that we need some use cases of using the model to retrieve information, not just based on existing catalogues. Otherwise we are on the way to reproducing the whole UCD system!
thanks
a