Dear Jonathan and Mireille,
please find attached my comments to the Spectrum Data Model, which I will immediately put under the corresponding RFC pages now that I have finally learned how the process works :-(
Cheers,
P.
Spectrum DM comments
The document is very well thought-of and easily readable. The huge effort spent on it can be clearly seen. I think it is in the correct status for PR. Some minor comments, which don't constitute a show- stopper for the PR approval in my view but which should be taken into account at some point, follow.
1.- In page 5, the rules for "Mandatory, Recommended", etc. are given as in other Data Model documents. I have this general comment: that the Data Model should not define what is Mandatory or otherwise, as it does not make sense in the context of a Data Model, but in the context of "Access" to that Data Model, i.e., in the DAL context. To illustrate what I mean with a small example, a "Person" mini-model with name (String attribute), height (double attribute) and address (a complex object of type Address) can represent a person. It can not be said that something is not a Person because it does not have a name. It might a priori seem necessary to know the name of a person ("mandatory" attribute) but, for instance, a statistics company making a survey of numbers of people working in Aerospace jobs in Spain (this would be the "protocol") does _not_ care about the name of the person. They only care about "how many" regardless of the attributes. In the other case, the "White Pages" collecting information about people living in Madrid would _certainly_ need to know their name and Address, regardless of. e.g., their height. While the NBA looking for basket players would probably only be interested in the Height regardless (initially) of the name or address. In the context of the Spectrum DM/ SSA Protocol, the SSAP would define the Mandatory attributes for the protocol to work, while the Spectrum DM would just describe an abstract representation of a Spectrum. Even future Services (e.g., an eventual Crossmatch service) would define their own "mandatory" sets to be able to work with certain data. As can be seen, the Mandatory or Recommended nature appears when one "makes use of the data" and not for the qualification of the data themselves. Therefore, in my view, the Data Model group documents should avoid introducing Mandatory parameters in the models, and leave that to the Access Protocols.
2.- Page 7 desrcibes a UML for the SED. There are words like "SpectralCoord" and "Accuracy". I understand the former belongs to the STC and the latter to Characterisation. Should this be the case, it should be made clear. Otherwsie, an explanation of why it is not the case should appear clearer as well.
3.- Section 3.3. mentions UCDs as attribute identifiers. I think we have finally agreed on the issue of UFIs vs. UTypes and UCDs. Maybe some words on the distinction among them would be useful
4.- Section 4.6 on Position Coordinate should make explicit reference to STC, isn't it? (see comment 2.)
5.- Same as above in 4.7 with CharDM 6.- Same again in 5.1 7.- Section 7 should be reviewed. It mentions the Observation DM andthe Quality DM which evolution is yet not clear. It is too lose a chapter that should either be expanded to tell how the different DMs interact or possibly removed until this is better clarified in a future.
European Space Agency (ESA)
European Space Astronomy Centre (ESAC)
Research and Scientific Support Department (RSSD)
Astronomy Science Operations Division (SCI-SD)
e-mail: Pedro.Osuna-at-esa.int
Tel + 34 91 813 13 14 Fax: +34 91 813 11 72