[CATALOGUE] Source Catalogue DM

[Alberto Micol]

Dear Pedro and Matteo,

I finally manage to provide the requested feedback on the 
Observation/Characterisation
part of the Catalog/Source DM you are proposing.

[Note: in the following I will type "charac" for "characterisation".]

In the first place I'd like to highlight the fact that
"Catalogue Charac." and "Source Charac" are quite different beasts,
in that the Catalogue charac is probably going to be a some kind of summary
of the characs of all the sources in the catalogue.

In the following I take care only of the Source relevant aspects, related to
charac and observation, which are:

- Source.coordinates
- Source.frequency (and bandpass?)
- Source.snr & localBackgroundNoise
- Source.observation
- Calibration accuracy
- Publications

Coordinates and frequency:
The coordinates are described using STC which cover Temporal, Spatial 
and Spectral axes.
Hence, I see the Source.frequency as a redundant field; a field that is 
there for convenience.
If that is true, then I'd suggest also to add a reference time; or 
otherwise remove frequency.
(I like too much symmetry: or we put convenient fields for each axis, or 
I'd prefer no redundant
fields at all).
BTW, I assume frequency is the rest frame frequency, is it?


Bandpass:
On the other hand, what might be missing is the bandpass name and its 
characteristics.
The fact that under Observation there is a field called Filter is not 
enough. It could
be that some transformation is applied to the extracted source, and that 
the published
flux in the catalog is no longer characterised by the filter name of the 
original observation.
Maybe we should dust off the work done by Jonathan on the bandpass DM (?)

Back to STC (or Charac [see last comment at the end of this email]):
When saying STC that implies many things which are not explicited in 
your model.
And in particular I'm concentrating on the charac aspects like 
Resolution and Sampling.
I find particularly relevant to know whether the morphological 
parameters of the source
were extracted from an undersampled or oversampled image, or otherwise 
from a low or high
resolution spectrum. Maybe that should go in the Observation box...

Observation: Spectroscopy?
The Observation diargam is probably biased towards imaging.
Spectroscopy is to be added there. Things like slit sizes, position and 
orientation
(maybe in your view accumunated under fieldOfView and positionAngle, or 
maybe Aperture?),
dispersive elements could be added.

Calibration  accuracy:
I see things like vignettingCorrection, but there are many other 
corrections one could
put in (from flatfielding to geometric distorsion corrections).
I would claim that  the source is probably extracted from a 
well-calibrated product,
where all such corrections have been performed.
Hence, I would remove the vignettingCorrection and put in  a more generic
Calibration Status, as it is done in the SSAP (Paragraph 3.3.5.2),
e.g. Accuracy.Spatial.Calibrated, Accuracy.Spatial.SysErr, etc.
I would also get rid of the gain.
To be added: the Error on the ZeroPoint.

Source.snr and localBackgroundNoise:
I see that part of the SourceDM, but I also see a localBackgroundNoise 
under Observation.
That confuses me. Could you please clarify what you mean by 
localBackgroundNoise?
In my view that belongs to the Source, not to the Observation.

Finally: Publications.
Well, maybe not. It all depends if Source means extracted source, or if 
Source means Object
(as discussed in Kyoto). In the latter case I would then add the 
bibcode(s) of the publications
from which certain quantities were derived.

An overall remark:
Should SourceDM point to STC
or to CharacDM which uses STC (and should also contemplate Accuracy)?

I would be in favour of the second approach to be inline with SSAP and 
later with SIAP.
And that would save you lot of work since you can probably 
copy-and-paste that part
into your Catalogue DM.

I think this is enough for a first pass. Sorry that it came so late!

Alberto


Pedro Osuna wrote:

>Dear all,
>
>Matteo Guainazzi (ESA-VO and XMM-Newton Archive Scientist) has compiled
>information on several source catalogues on different wavelengths and
>together with Jesus Salgado an myself we have compiled a tentative
>Source Catalogue Data Model, that would plug in the general Catalogue 
>Data Model that we discussed back in Pune.
>
>We attach a UML diagram of the model to serve as a starting point for
>discussion. 
>
>You will see in the model that certain of the Source specific
>characteristics that Matteo has identified correspond to other Data
>Models that are being worked by other sub-groups.
>
>With my Catalogue DM coordinator's hat, could I ask Jonathan (for the
>SED) and Alberto (for the Observation/Characterisation) to cross check
>which of the relevant items boxed in the diagram correspond to items in
>their respective models? And in case they are not there, would it be
>possible to add them?
>
>A small description -by Matteo- of each of the physical attributes 
>in the model follows together with a description by Jesus and myself 
>on the model itself. 
>The attributes' types in the model have been put for reference and 
>should not be taken as definitive. 
>
>Please do have a look to the Model and send your comments; this is the
>only way to have flexible and powerful Data Models fulfilling all the
>needs.
>
>Feel free to send comments to the whole Catalogue dm group
>(dm-catalog at ivoa.net) or, in case you send them to the general DM group
>, do it with a subject containing the word [CATALOGUE] so that the rest 
>of DM-ers can filter properly.
>
>
>Cheers,
>P.
>
>
>++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
>UML diagram
>===========
>Objects:
>-------
>Source
>------
>We have decided to have a quite general and big-ish object called Source
>with as much information as possible inside. Smaller or finer grain
>could have been obtained by separating the attributes on the Source
>object to smaller objects. However, in view of the fact that the source
>is just but one item in the possible "Catalogue entries", we thought
>that there are already too many subdivisions, and hence decided to build
>only one.
>
>Certain attributes of the Source object will, obviously, only apply to
>some sources (a clear example being, e.g., the visualAlbedo). 
>
>The idea of the "id" is to leave a place for specific IDs for specific
>projects. The standard naming for the sources should be filled in (if
>known) on the SIMBADName and IAUName.
>
>Wherever STC appears, it makes reference to certain item in the Space
>Time Coordinate Data Model from Arnold.
>
>Orbit is obviously only related to objects following an orbit, like
>binary systems. In this case, a specific object has been isolated as it
>might become quite big if we decide to add more specific attributes to
>the orbits of the objects (some of which are very well known). In this
>case, we have doubted whether any effort exists in the Data Model groups
>to describe orbits in general (Jonathan: would it need to be considered
>separately?).
>
>
>Morphology
>----------
>Morphology has been separated to account for possible extended source
>information. In the case that a Source is identified to be of a certain
>type (for example, a Galaxy) this Galaxy model should extend the
>Morphology and add more specific attributes to it (in the case of a
>Galaxy, for example, whtehr the galaxy is Sprial SB, or Sa, elliptical,
>irregular, etc.).
>
>Orbit
>-----
>We have decided, as mentioned above, to isolate this item as it might
>grow easily if we decide to give very specific information for orbits,
>some of which might be very well known. For the time being, we give only
>a reduced set of attributes.
>
>
>STC
>---
>Relevant items to the Source model are specified there. Arnold should
>revise their validity.
>
>SED
>---
>Jonathan should revise which of the items inside this box are present in
>the SED, and in case they are not, decide if they can be created.
>Otherwise, we might want to create an isolated object for this.
>
>Observation
>-----------
>Alberto should revise this bit and give information (as above).
>
>
>AGN
>---
>This is not an object as such. It is a place holder for any possbile
>AstronomicalObjects that we might want to describe in the future. We
>agreed in the past that in many catalogues, the type of source is either
>unknown or irrelevant, therefore not neededing an identification.
>However, other catalogues will consist, e.g., of only galaxies, for
>example. In this case, a Galaxy model should exist to which we could
>point the "type" attribute of "Source". This AGN object represents one
>of those future objects.
>
> 
>Physical Description of attributes
>==================================
>
>- "id":		Name of the source 
>
>- "IAUName": 	IAU name of the source
>
>- "SIMDABName": SIMBAD name of the identified counterpart
>
>- "type": 	Source class. It may reflect a standard object
>		classification as in e.g.: 	http://simbad.u-strasbg.fr/guide/chF.htx
>
>- "coordinates": The sky coordinates of the source
>
>- "frequency": 	The frequency, at which the flux/magnitude/count ("flux"
>  hereafter) measurements in the catalogue were taken
>
>- "snr": Source significance in terms of signal-to-noise ratio
>
>- "detectionProbability": Source detection probability
>
>- "distance": Distance of the source from "distanceOrigin". The
>cosmological redshift is a possible instantiation of this attribute
>
>- "distanceDeterminationMethod": Method employed to determine
>"distance". "Spectra", "Photometric", "Parallax" are possible values of
>this attribute
>
>- "distanceOrigin": Origin from which "distance" is being measured
>
>- "properMotion": the source proper motion on the sky vault
>
>- "radialVelocity": the radial component of the source velocity
>
>- "varAmplitude": the amplitude of the "varType" amplitude variability.
>It can be expressed either in physical absolute, r.m.s, or in fractional
>units
>
>- "varPeriod": the type of source variability: "Periodic",
>"Quasi-periodic",  "Burst of Type I", "Aperiodic" are possible values of
>this attribute
>
>- "polarisatinDegree": degree of source polarization
>
>- "polarisationAngle": positional angle of the source polarization
>
>- "visualAlbedo": source visual albedo
>
>- "minorDiameter": size of the minor diameter of the source
>
>- "majorDiameter': size of the major diameter of the source
>
>- "inclination": angle between the line-of-sight to the source and the
>  normal of the main source symmetry plane
>
>- "positionAngle": apparent position angle of the source on the sky
>vault
>
>- "stellarityIndex": parameter ranging from 0 (galaxy) to 1 (star),
>related to the probability that a given object is extended or point-like
>
>- "form": string describing the geometrical shape and/or symmetry of the
>   source. "Boxy", "Patchy", "Ring", are possible values for this 
>attribute
>
>- "perihelion": minimum distance from a reference point along the orbit
>
>- "perihelionTime": time of the source passing through the orbit
>perihelion
>
>- "afelion": maximum distance from a reference point along the orbit
>
>- "inclination": angle between the line-of-sight to the source and the
>  normal to the plane containing the orbit
>
>- "eccentricity": fraction of the distance along the semi-major axis at
>which the focus lies (e=c/a, where c is the distance from the center of
>the conic section to the focus and a is the semi-major axis)
>
>- "positionAngle": apparent position angle of the orbit on the sky vault
>
>- "period": orbital period
>
>
>
>  
>
-- 
Alberto.Micol at eso.org                         Tel: +49 89 32006365
HST Archive Scientist     ST-ECF              Fax: +49 89 32006480
ESA/RSSD/SN               c/o ESO             Karl Schwarzschild Str.2,
http://archive.eso.org/                       Garching bei Muenchen,
http://www.stecf.org/                         D-85748 Germany