Comments on SSAP document

Wed Jul 11 07:03:45 PDT 2007

Dear Doug et al.

I am sorry I did mess the system again by sending my mail to the  
interop.

I have been (rightly so) told off, and have put my comments on the  
RFC page.

Cheers,
P.

On Jul 11, 2007, at 12:53 PM, Pedro Osuna wrote:

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

_________________________________________
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/dal/attachments/20070711/b32cefce/attachment-0001.html>