Comments to the Spectrum DM

[Pedro Osuna]

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 and  
the 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.



_________________________________________
Pedro Osuna Alcalaya

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
_________________________________________
European Space Astronomy Centre (ESAC)
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN




================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/dm/attachments/20070711/57ec68f8/attachment-0001.html>