Comments on SSAP document

[Pedro Osuna]

Dear Doug,

I confess I am slightly lost with whether I have to give these  
comments through the RFC pages or at the end of them or what (I can  
not find a place for the TCG members to give the comments on the RFC  
pages for the SSAP).

Therefore, please forgive me for sending the note to the whole list  
if this is the wrong approach. Let me know if you want me to input  
these in the RFC comments as such and I'll do.

My comments to the SSAP follow.
Cheers,
P.

Comments to the SSAP document
==========================

The document is overall extremely well cared and written. It is  
certainly a very mature document whose change to PR is granted by its  
own quality.  None of the comments given below are showstoppers for  
the PR in my view, but should be taken care at some point in the life  
of the SSAP document.


1.- in "Status of this Document" section (no pages have been  
assigned... could this be done to ease interactions?), a mention is  
done to the TAP:
[...]It is expected that the SIAP spec., which predates SSA, the new  
TAP [...] will be homogenised with SSA[...]
Despite the fact that this statement is probably very justified,  
taking into account that the TAP is currently under development, I  
would appreciate the removal of this bit to not jeopardise the work  
being done on the TAP.

2.- the document makes indistinctive use of the "SSA" data model and  
the "Spectral" data model. It also makes use of other models like the  
Characterisation DM. It is clear that not all of them represent the  
same type of description: the "Protocol" specific attributes (like,  
for instance, POS and SIZE, or Access.reference, Access.format,  
Access.size) are describing elements compulsory for the protocol to  
work, while other attributes like DataID.Creator, or  
Curation.reference, or CoordSys.SpaceFrame.Name, or  
Char.FluxAxis.Accuracy.StatError are describing other characteristics  
(unrelated to the protocol) of the data. Those attributes are  
allegedly defined in other documents like the Spectral DM or the Char  
DM. In my opinion, clear identification with the proper IVOA  
identifier should be included in the document, like in  
"char:Char.FluxAxis.Accuracy.StatError, or ssa:Access.reference, etc.  
This ensures that the data provider and the people in charge of  
building software know clearly what the different connections are  
between the different models being handled by the protocol.

3.- an extension of the above comment is the fact that the comment  
(last paragraph after point 1.1Architecture): "A spectrum confrming  
to the SSA data model[...]" is misleading in this context, as the  
protocol document is mixing the fact of being "compliant with the  
protocol" with the fact of being "compliant with the protocol AND  
exporting data in the Spectral DM form". This comment is repeated  
several times throughout the document.

4.- due to previous comment, I would modify opint number 2 in  
"1.4.1Levels of compliance", where it says "[...]MUST be capable of  
providing at least one of the SSA-compliant data formats[...]".  If  
by SSA-compliant Data Formats it means "SpectralDM compliant data  
formats" this would leave out all legacy data. I understand this is  
clarified later in the paragraph, but I still consider it highly  
deprecative for legacy data, and in my humble opinion might make  
legacy data providers to step back from publishing in SSA format.

5.- due to comment 2.-, I think paragraph on 2.1Data Model should be  
rewritten to not talk indistinctively about SSA Data Model and  
Spectral Data Model (and others, lke Characterisation, possibly  
Provenance, etc.).

6.- Paragraph 2.3Virtual data states "Most data access in the VO is  
to virtual data". This is arguable, and the currently existing  
(around 15) data services are all over non-virtual data. Also, the  
survey done at the beginning of the creation of the SSAP showed a  
high number of non-virtual data archives. Also, the continuing  
sentence "Physical data sets can also be accessed, but this is far  
less powerful technique" albeit how potentially true, looks  
deprecative with already existing legacy data, and might discourage  
data providers to buy in to the VO. Again, most of the currently  
existing services are legacy data, and are not published in the  
Spectral DM format. Clearly, implementation of the Spectrum DM will  
make software clients more powerful in the analysis, etc., but active  
mediation can be an expensive service that should not drive whether a  
data provider plays the VO or not.

7.- The inclusion in the doc of the SpectralAxis and FluxAxis  (see  
comments by Jesus on June 22 2007) are necessary.


_________________________________________
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/interop/attachments/20070711/1cbbb04a/attachment-0003.html>