Dear all,
Matteo - thanks for clarifications and comments (Date: 2005-09-26Z08:38:39)
A brief response:
I agree entirely with most of your points which you ahve put better than I
did. However
> 3. although a simple logical flag to highlight orbiting objects is
> surely a possible solution, I am not sure I understand why the
> "Orbit" element should make any harm. I have left it as it was in the
> original scheme, waiting for more discussion on this point.
I don;t object strongly, I suggested simplifying it for two reasons, firstly on principle, and secondly that the presnt model seems to be too detailed for my simplistic version but not detailed enough for re-observation (e.g. it does not seem to include the time/place origin on the orbit..).
Similarly on your point 4. about variable flux. "varPeriod" is fine for analysts, but observers need to know the zero time of the period.
In fact, from a purely observational point of view, it can be difficult to disentangle the sort of variability e.g. caused by the pulsation of a solitary star, from an eclipsing and/or eruptive binary. It might be helpful to look at the definitions of the various IRAS and Hipparcos flags, which was a very simple way (before XML was invented!) of attempting unbiased observational classification - although even they got some things wrong, e.g. Hipparcos assumed that all stars were unresolved and so categorised some solitary red supergiants as multiple.
> 5. it goes without saying that many - if not most - of the quantities in
> the model are wavelength-dependent. We have "Source.frequency", in
> facts
Hmm, so is each property of a source related to s specific frequency? I think that this would be clearer to me if I were to see it applied to some example sources. We could take some objects from NED or SIMBAD and see if we can model them - e.g. Markarian 273 (galaxy) or HM Sge (symbiotic binary star) - and move on to more difficult cases like star-forming regions or clusters of galaxies. I'd be happy to help, maybe we can discuss this in Madrid - I haven't time to do much before then, sorry.
As a more general point and partly in reply to Jesus, (Date: 2005-09-15Z16:19:4)
I think that if we do the above it will be obvious that we have to be very selective in what properties we explicitly include, otherwise the model will become so complex that no-one will fill it in. It should be possible to opulate the model by some kind of supervised automatic harvesting. It is not supposed to reproduce all the information in every catalogue. That is why I feel that terms like Albedo are far too specific. We stray into the area covered by ucd's...
> However, it does not solve the question of what do you need to describe
> a Source (it only leaves a placeholder to add all the properties that
> the source could have, but without trying to define them). I think we
> need something more detailed if we want to use this data model as a base
> to inter-operate in the future.
We need some use cases, the presentation mentioned at http://www.ivoa.net/internal/IVOA/IVAODMCatalogsWP/Poona_2004_Catalogue_DM.pdf has Mireille's suggestion "Is the source in this catalogue the same as the one in this other catalogue" which is not nearly as simple as it might sound in the case of e.g. a gamma ray burst with a poor position - in which case you have to identify which of maybe 10 objects in its error box is a likely host - or a galaxy with radio jet hotspots many arcmin from the optical centre...
But maybe we should start with simpler cases, e.g. as in Berndt Vollmer's SpecFind. Mireille's question has the very practical corollary, of helping when you want to observe a source e.g. in the radio, when you only ahve X-ray and optical properties known, etc.
I like the model presented at p. 5 of the Poona_2004_Catalogue_DM.pdf - I don;t think that we want to get much more complex. However, thre should be a link to the Observation DM - as I understand it, the object labled Observation on p. 5 is specifically for VOEvent use, as it omites some rather vital information for most people like Frequency.
thanks
a