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