SsaRFC < IVOA

<H1>Simple Spectral Access RFC</H1>

%TOC{depth="2"}%


---
---++ About this RFC
This document acts as RFC centre for the [[http://www.ivoa.net/Documents/PR/DAL/SSA-20070604.pdf][Simple Spectrum Access Protocol]], PR V1.01.  Further information on the SSA protocol and associated Spectrum data model can be found on the [[http://www.ivoa.net/twiki/bin/view/IVOA/SsaInterface][Collaborative Page for the SSA Interface]].

Note that although early SSA implementations included a _getCapabilities_
operation for returning service metadata, specification of this has
been deferred to SSA V1.1.  The V1.0 specification being reviewed here
mentions getCapabilities (and getAvailability) but does not specify
the contents of the metadata returned.  The older FORMAT=METADATA
construct is specified instead.  This will eventually be deprecated,
but allows SSA V1.0 to go forward immediately while we work to specify
these additional operations for V1.1.

To add a comment to the document, please edit this page and add
your comment to the list below in the format used for the example
(include your TWiki.WikiName so authors can contact you for further
information). When the author(s) of the document have considered the
comment, they will provide a response after the comment.

Discussion about any of the comments or responses should be conducted
on the data access layer mailing list, dal@ivoa.net.

---
---++ Latest Updates

   * new appendix: Theorectical Spectral Access Use Case ([[%ATTACHURL%/theory-appendix.pdf][.pdf]])
   * replacement for appendix: Sample Metadata Query Response ([[%ATTACHURL%/SsaUsagePR1.02.xml][.xml]])

---
---++ Community Comments
   * Concerning input parameter BAND: In a band range: Is the first parameter expected to be smaller than the second one or can a service accept e.g. band=2000/1000? Is band=/ considered as a valid band range? (by UlrikeStampa) 

      * Response by _MarkusDolensky_:

Yes to the example of the open interval for BAND.
<verbatim>
Omitting both values indicates an infinite range which accepts all values.
(sect. 8.7.2)
</verbatim> 

A specific order is not required except that a list of ranges is processed from left to right and any matching values in any interval shall be returned (logic OR).

      * Response by _DougTody_:

Since many parameters can accept ranges or range-lists, the detailed
semantics of range list parameters are specified once in section
8.7.2 rather than for each parameter.  As this section specifies,
if numerical ordering of the range-list is required for query
processing, it is the responsibility _of the service_ to sort the
list, or re-order the range values.  In the case of BAND it is clear
that such an expression says the same thing regardless of the order
in which the elements are given.

<br>
---
   * Page 49, Query response example, 3rd line: there is "//" missing in the schema location (by IgorChilingarian)

      * Response by _MarkusDolensky_: Thanks for spotting Igor.

<br>
---
   * Section 4.1.1 expressly states that valid queries don't have to specify all mandatory parameters. Some of them are thus defaulted when missing (i.e. SIZE, FORMAT) but how to deal with POS, BAND and TIME when omitted (especially POS)? Second, does a POS=, (empty list, section 8.7) and a missing POS situation have to be considered as equivalent? In general, how to deal with irrelevant parameters (eg for theoretical spectra)? (by HerveWozniak)

      * Response by _DougTody_:

This is an important and subtle point.  Most parameter values are used only
to constrain the query.  There is not necessarily any default value if a
parameter is not given.  If no value is specified for a parameter, e.g.,
SIZE, then all it means is that it is not used to constrain the query;
other parameters must be used to constrain the query instead.

The case of theory data is discussed in section 4.1.  A service must
support a mandatory parameter, like SIZE, but this does not necessarily
mean that the parameter is valid for the data in question.  If the
query specifies an explicit position (or TIME etc.), and this quantity
is undefined for the data in question, then the service should not find
any matching data.

The case of something like PARAM=, with no value given, has not been
addressed.  This would appear to be the same as PARAM="".  In general
specifying the empty string is not the same as unset, although it may
not matter for a parameter such as POS.  This needs more thought.  In
the meantime, it has not been addressed by the current spec.

<br>
---
(_Comments by Randy Thompson, originally posted to the DAL mailing list on June 21._)

   * Section 1.3.4 states that more information on error responses is
   given in section 7.4. Section 7.4 actually discusses data retrieval
   errors. Although its referenced in 7.4, the real information is
   found in section 8.10.

Good point, 8.10 is a better reference.  We will change this.  - DT

   * Section 1.4.1 states "VOTable is preferred if only one format is
   supported".  I would suggest not preferring one data format over
   another and leaving it to the data providers to decide. For an
   "archival" SSA service, which is the more likely type of service
   to offer only one format, FITS may be a better choice.

This was discussed on the DAL mailing list, and quickly morphed into
a discussion of support for pass-through native data in FITS format.
These discussions are summarized separately below.   - DT

   * Section 2.4.2 mentions that "the full creation type can be
      more than one of these operations, for example, both projection
      and filtered...". Does this imply that the dataset creation type
      metadata value can be a list? Is this true in general (i.e., that
      metadata can be defined as multiple (comma separated) values)?

Yes, the intention was that the creation type could be a list.
In general a parameter can be a list, range, or range-list, but only
if the specification says so.

It would be nice to simplify this and have the values be fixed, but the
concern was that, since <nop>CreationType describes what was done to
the data, it might be necessary to describe independent operations.
For example a "mosaic" may or may not recompute the pixel values.
"filtered" means that the pixel (sample) values were recomputed in
some fashion.   - DT

   * Section 3.1 typo Add an "an" before "explicit parameterized operation".
   * Section 4.1.2 typo - recommended parameters are indicated in
      the tables by "REC", not "REQ" as stated.

Will fix.   - DT

   * Section 4.1.2, 2nd sentence after table "The spatial resolution
      is important as it is usually comparable to the diameter of the
      spectral aperture on the sky...".  I don't think this is why
      spatial resolution is important.  Note the wording in the SDM
      paper (section 4.6.3) "the spatial resolution may be useful to
      know if it exceeds the aperture size; the default is to assume
      it is equal to the aperture size."

Reporting the spatial resolution in the dataset metadata is a different
matter than using it for a query parameter.  I agree though that we
should see if this can be phrased better.  What the text was trying
to say is that, for most data, the spatial resolution is _probably_
comparable to the aperture, and for the purposes of a query they can
be considered similar, but that the actual values will be returned
in the dataset metadata and can be used to refine the query further
if necessary.  The point here is merely to simplify the interface.
 - DT

   * Section 4.1.2.2 typo? defines spectral resolving power as dW/W,
      while the SDM paper section 4.6.3 defines it as W/dW, as does
      the table in 4.1.2. I assume the text just needs to be corrected.

Will fix; this instance was a typo and is incorrect.   - DT

   * Section 4.1.2.10/4.1.2.11 - FLUXCALIB and WAVECALIB are
      true/false parameters defined as "Specifies whether only
      flux/wavelength calibrated data is to be found".  It's not
      clear to me from the wording whether a value of "FALSE" means
      return only uncalibrated data or return both calibrated AND
      uncalibrated data.  Perhaps this can be clarified. There are
      really 3 logical possibilities, return calibrated, uncalibrated,
      or both. I assume the default is to return both.

Will rephrase.  Yes, the default is to return both calibrated and
uncalibrated data, with the detailed metadata describing the situation.
 - DT

   * Section 4.2.6.2/4.2.6.3 shows metadata names in a different
      font, but some were listed with the same font as the text
      which makes it confusing (i.e., "Collection", "Creator", and
      "PublisherDID" ). Also, I believe, the first reference to
      "CreatorDID" should really be "DatasetID".

Agree the fonts are inconsistent; will fix.

The <nop>CreatorDID is the identifier assigned by the dataset Creator;
it is like a manufacturer's product number (in the shopping cart analogy)
and is not the ADS (or whatever) Dataset Identifier.  Will clarify.
 - DT

   * Section 8.10 3rd paragraph add "the" before "senses described below".

Will fix.   - DT

   * General, The SDM paper states that UTYPE's and UCD's are
      case insensitive but I didn't see this mentioned in the SSAP
      paper. There was some confusion about this for the SIAP UCDs. If
      it's not already mentioned somewhere, perhaps it would help
      avoid confusion to state this in the SSAP paper as well.

Good suggestion.   - DT


<br>
---
_Support for Native Project Data_

As noted above, the mention of VOTable and FITS as output formats
quickly morphed into a discussion of support for pass-through of native
project data, which is often archived in FITS format.  Anita Richards,
Jesus Salgado, Bob Hanisch, and Roy Williams contributed to
[[http://www.ivoa.net/forum/dal/0706/date.htm][this discussion]],
which is archived on the DAL mailing list.
While this was an important discussion, it should be recognized that
support for native data is a separate matter from the available output
formats supported for SSA/Spectrum compliant datasets.  Our intent here
is to summarize the conclusions reached in the mailing list discussion.

Regarding pass-through of native project data, the conclusions reached
are that:

      * All agree that it is essential to support pass-through of native
      project data; the current SSA interface already does support this.
      * While pass-through of native format data may lower the bar
      for service implementors, the main reason for supporting this is
      to give client applications direct access to the native project
      data, which will often contain project-specific information which
      may be lost the the process of mediating to a standard model.
      * Mediation to a standard data model (Spectrum in the case of
      SSA) is nonetheless necessary in the general case to deal with
      the great variety of spectral data existing within astronomy,
      and enable or at least simplify multi-wavelength analysis for
      client applications.
      * To improve support for native data, we agreed to restore
      the optional <nop>SpectralAxis and <nop>FluxAxis parameters.
      While not fully general, these parameters plus the existing
      parameters specifying the dimensional units of the spectral and
      flux axes allow basic analysis of native format spectral data
      in many cases.

- DougTody 3-July-2007.


<br>
---
(_Comments by JaiwonKim and GerardLemson_)

Here is the list of questions, suggestions, and typos. We understand
that some issues may not be resolved in this version of SSAP, but
still think useful to be considered for a future version. We hope we
have made ourselves clear as sometimes the issues are rather tricky
to explain.

Jaiwon, thanks very much for the careful and very thorough review and
comments.  Since this is so detailed I won't respond to every point,
but we will note all points and take them into account in
revising the specification after the RFC period.  - DougTody

   * Query response metadata: 
      1   We suggest adding the datatype of each output metadata
      element, including the allowed cardinality, in the corresponding
      tables in the specification document. This makes it much easier
      to find this information, which now is spread out through
      the text.
      2   For Associations, we would like to see an example how to
      deal with the case of a single row belonging to two or more
      different associations. Do the values of each of the different
      attributes (Type, ID and Key) get listed in their respective
      column and in the same order? Seems natural but should be
      specified formally. See 3) and 4) below.
      3   Also on Associations. In the examples an Association gets
      a GROUP in the VOTable. If we have multiple Associations we
      will have correspondingly multiple groups. Should all of these
      have FIELDRef-s to the same column (Association.Key)? Is
      that allowed in VOTable? Should there be an indication
      which "sub-column" inside this column is referred to by the
      Association? Is it allowed in the SSA query result to have
      multiple Association.ID/Key/Type columns?
      4   Similar questions as for the Association apply to other
      "multiplicity > 1" elements such as <nop>DataID <nop>CreatorDID,
      Date, and Version for a dataset created from multiple parent sets.
      5   In Appendix A on p50: In  &lt;Group ID= "Association" &&gt;
      &lt;FIELDref  ref ="AssocID"&gt; :Is this correct?
      Are <nop>AssocKey and <nop>AssocID mixed up here or do we
      misunderstand this?

We agree that providing the information in 1) is necessary, but it is
difficult for space reasons to include all the details in the tables,
and would make the document harder to read.  In any case the SSA
document does not fully specify all fields of the Spectrum data model.
The data model spreadsheet may provide a more effective way to detail
this information.

Regarding associations, there is an example of this in the reference
implementation (http://webtest.aoc.nrao.edu/ivoa-dal), and also in
Appendix A, which may help clarify the points you raise.  We will
consider adding an example to the specification document as well.
If there are multiple associations they have their own id's and keys.
Each just adds one or more fields to the table.

Regarding 4), the example in Appendix A is correct.  The table FIELD
<nop>AssocID provides the unique ID of the association, and "AssocID" is
the VOTable ID of the FIELD definition (this may be confusing, but it
is simple enough).  Do not confuse the Association ID, which is data,
with the ID-Ref stuff in VOTable, which is specific to VOTable.   - DT

   * Query input parameters: 
      1 We think that it would be helpful if the syntax for each
      input parameter were expressed in a concise, and precise form in
      the tables. Possibly even using regular expressions in complex
      cases. Currently the precise format is spread out through the
      text, e.g., the description of BAND is almost a page.
      2   (Similar comment by H. Wozniak) We think the document needs a
      proper description of how the service should act when the value
      of a request parameter is not specified properly, i.e. how to
      handle syntactic errors. Related to this we think the document
      needs a description (or rethink) how to handle nulls and how
      to handle the case where a parameter is supported, but not all
      its possible values. For example, our service supports only
      numerical specification of the BAND parameter, what should we
      do when someone submits BAND=J. In the latter case the document
      specifies that no rows should be returned. We believe that a
      better result would be an error/warning message indicating that
      the service does not understand the request.
      3   How to handle unsupported parameter: It is mentioned in
      sec 4.1 on p17 that the service should allow a query to the
      request including an unsupported parameter, assuming a logical
      value ALL  Should the service first do syntax checking?
      4   How should we specify the allowed syntax of custom input parameters
      in FORMAT=METADATA?
         i. Specifying datatype=char and arraysize=* does not give the actual
         allowed syntax, see the case for POS.
         i. How can we indicate to a client that a certain parameter allows
         range-list values? 

Item 1): Much of the description of BAND (for example) deals with
the semantics, not the syntax, which is simple.  The syntax is the
standard range-list syntax, as is noted in the first sentence and
detailed in 8.7.2.  Many/most parameters share this same syntax.

Item 2): I agree that the issue of how to handle illegal values needs
to be clarified (probably this should result in an error response).
This is separate from the issue of ignoring parameters which are are
not implemented by the service (item 3).  If the service does not
implement the parameter it should ignore it.

Item 4): I think this level of detail on interface may be better
addressed later with getCapabilities.   - DT

   * We find the description of the various data set identifiers confusing. 
      1   Must all such identifiers in this spec (<nop>CreatorDID,
      <nop>DatasetID, and <nop>PublisherDID) adopt the IVOA Identifiers standard
      (http://www.ivoa.net/Documents/latest/IDs.html)? Is it what was
      intended by the "IVOA" in statements such as "The IVOA dataset
      identifier &" (p32,  p33).
      2   What is the  <nop>DataID.DatasetID ? It is introduced in a table
      on p.32 but not described in the text as far as we can see.

All dataset identifiers have the same IVOA identifier syntax.
<nop>DataID.DatasetID is defined in the data model document, but we should
probably clarify it here as well.   - DT

   * Associations
      4.   Note on p34: "If the same dataset is replicated at several
      locations with multiple publishers, it is possible to set up
      an association group to indicate this fact." : This seems only
      relevant if all of these datasets are published by a single SSA
      service instance, can therefore show up in a single query result,
      and such an association can be useful. Otherwise it seems only
      to complicate matters.

This came from an actual use-case, where a service (SIA in the actual
case, but it doesn't matter) was describing datasets replicated on the
Teragrid.  That is, a single service instance describing replicated
data - the datasets were all the same, but had different acrefs and
were stored in different locations.  Not to belabor the point, but this
was just an example to illustrate the range of things which can be
described by associations.   - DT

   * Other Comments
      1.   A typo in the table on p33: "Data curated" should be "Date curated"
      2.   There is description on version negotiation for SSAP, but
      no mention of which version of datamodel should be used. Is it
      arbitrary, or is there a one to one relationship between SSAP and
      Spectrum DM? Or something else?
      3. In sec 4.1.2 on p21 table of recommended and optional query parameters:
      inconsistency in the datatype of a parameter whose value is true/false:
      FLUXCALIB false string, WAVECALIB true string, COMPRESS true boolean
      4.   Typo on p26: In an example of service protocol there is an extra "/".
      5.   It is not explicitly stated in the text that it is mandatory
      to repeat the query parameters in the result. Should it be ? (See
      the example in Appendix A)
      6.   Does service metadata require UCD? See sec 4.2.3-4.2.5. Tables
      have UCD column without any value in it.
      7.   In sec 4.2.6.8 on p36: In the table "Calibrated", in the
      following text it is "calibrated". It is stated that parameter
      values are case sensitive in 8.7.1
      7.   Text in sec7 on p39, starting with "is required to obtain
      an acref," to "implementation of existing services" is almost
      literally replicated in section 7.1. Is this necessary?
      9.   In sec 7.1: If the client issues a HTTP GET request using
      this URL, and the request is successful, the client will receive
      a document of the type given in query response column with the
      UTYPE Access.Reference.: Should it be UTYPE Access.Format?
      10.   In sec 8.2.2 on p40: "shall comprise no more than two
      integers separated by decimal points": Should it be "three"
      integers instead of "two" as there are three levels of versioning?
      11.   In sec 8.3.2 on p.42: In Table 1, "/" is missing.
      12.   In sec 8.3.3 on p 43: In Table 2
      http://host[:port]/path[?{name[=value]&}]: Should this be
      http://host[:port]/path[?[name[=value]{&name[=value]}]]  ?
      13.   A consistent style of references/citations is suggested.
      For example, the following different ways of referring were encountered:
         1   p3 (Rixon et al. 2007).
         2   p11 <nop>McDowell, Tody, et.al, 2007
         3   p19 [RSM, Hanisch et.al, 2005]
         4   p25 [Dolensky 2006]
         5   p43 Internet Assigned Numbers Authority(IANA) [2], etc
         6   Also some of RFCs referred in the text are missing in the
         reference list or some references in the list are not referred
         in the text, for example, [Allen et al. 2003]

Item 2: Version negotiation refers only to the SSA service version.
A given SSA version supports only a single (down to level 2) version
of Spectrum, as they are closely linked.

Item 5: Echoing input parms in the result is not required for the correct
functioning of the service hence is optional, but we should recommend it.

Item 6: Other than in a very few cases UCDs are not required for the
correct operation of SSA, but we try to provide them.  Not all have
yet been defined.

Item 10: It should be three, but unfortunately IVOA mandates two, e.g.,
"1.01".   - DT
 
---

   * Section 4.2.6.7 states that spectral coordinates are specified in units of meters, but in the table above the description for *Char.SpectralAxis.Coverage.Bounds.Extent* says "Width of spectrum in A or other unit" (by MarSierra)
---




</br>
---
---++ Comments by TCG

Chairs should add their comments under their name.   

---+++ Mark Allen (Applications WG)

I approve

---+++ Christophe Arviset (TCG vice Chair)
I approve this well thought document and I appreciate the summary by Doug about the native project data and the restoration of Dataset.SSA.SpectralAxis and Dataset.SSA.FluxAxis fields.

As a minor comment, tt would be useful to have page numbers for the document.

For section 4.2.3, 4.2.4, 4.2.5, the UCD column is always left empty as the UTYPE is already indicated. Probably, it would be better just to remove the UCD column.


---+++ Markus Dolensky (Data Access Layer, Vice Chair)

Approved.<br/>
The given document with above amendments is the best currently achievable standard for the given purpose. Particular feedback has already been considered during the RFC period and has been channeled into the specification throughout the past years.<br/>
( _on behalf of Chair, Keith Noddle_ )

---+++ Matthew Graham (Grid &amp; Web Services WG)

I approve this document.

---+++ Bob Hanisch (Data Curation &amp; Preservation IG)

I approve this document.  I think it is important to agree on what we have now and get implementations going.  We will follow this rather quickly with a V1.1 and can make further updates then.

---+++ Gerard Lemson (Theory IG)
I will approve the specification, though I hope that some changes can be made
according to the comments below. These deal mainly with what I think will 
improve the readability of the document, which, for a standard specification, is 
rather wordy and could be made more precise.

Together with Jaiwon Kim I have made comments during the RFC phase.
I will therefore comment on the responses here only.

In his response to our comments Doug states that where he does not 
comment these may show up in the next version of the document.
We need to wait till that before we can evaluate whether the comments 
were actually addressed.

On the issue of irrelevant parameters, also brought up for example by 
Herve Woznaik, Doug says he agrees that this is has
to be addressed. Especially for theory this is very important of course 
and we feel it MUST be addressed explicitly and in more detail in this 
version of the document.
I have some issue with Doug's statement that in case someone send us a 
parameter one does not support, it should be ignored.
I wonder if that is from a user's perspective the best solution. 
For example, in the spec it is stated for BAND query parameter that: 
"If the service does not support specification of the spectral frame the syntax 
should be permitted but may be ignored." 
I understand that a query result depends on the spectral frame value. So is 
it a proper way to handle if spectral frame is not supported?
Shouldn't an error or a warning be issued? 
But I think this all is part is a bigger discussion item that can probably not be handled here.

Regardless of differences in the opinion how to handle unsupported, 
unspecified, not applicable, should it be made mandatory to echo input parameters 
that were actually used in query, in addition to echoing the inputs in the INFO
for example as in the examples? 

I still believe it would be useful to have a more formal way to 
describe the possible form an input parameter has, in a single 
location such as the table of input parameters. We proposed to use a 
regular expression for the more complex ones such as BAND, or POS. We 
feel this will be helpful even if in principle this info can be
extracted from the text.
For example, re-examining the BAND definition seems to indicate 
that the spectral frame qualifier is to be associated to the whole 
list, not to a single item. This is easy to miss, as we did, but would 
not have been missed when a formal description would have been given.
I see no reason why something like this could not be added. 

Same is true for the datatype of return fields/parameters.
Even if in principle the datatypes are somewhere mentioned in the 
text, they could easily be added to the tables.
This would make it much easier to get this information that is 
important for implementers.
Doug refers to a separate data model spread sheet containing this 
information. This seems indeed to contain the information that we ask 
for, but it can only be "normative" if it is part of the specification 
document itself, which it currently is not.
I do not understand the argument that for space reasons this can not 
be done, as for the query parameter tables it clearly was possible.
Again, I see no reason why this suggestion could not be added. 

As to associations. First, it is no good to refer to reference 
implementations or examples when someone does not understand the 
specification document itself. Only the latter is, or should be 
prescribing the standard.
Our problem was that we think the description of how to deal with a 
single row being in multiple associations is not well enough 
specified. Doug's response does not cure this.

I think it is useful to have the theory use case provided by Pedro as 
part of the document.
It does lead however to the same question we stated before, regarding 
how to specify (in FORMAT=METADATA), that a particular custom 
parameter could be queried by a range for example. Pedro's example 
only shows enumerated values.
A theory implementation we are working on at GAVO would prefer that users can select 
a range in temperature for example.
But how do we specify that this is possible ? Could use regexps again 
I guess. Or can we assume that for all floating point numerical 
parameters a range is always allowed?
I think though that Doug is right that this should probably be handled 
by the getCapabilities approach and can therefore not be handled by 
the current spec.

 


---+++ Mireille Louys (Data Models WG)

---+++ Francois Ochsenbein (VOTable WG)

---+++ Pedro Osuna (VOQL WG)

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 <nop>DataID.Creator, or Curation.reference, or <nop>CoordSys.SpaceFrame.Name, or <nop>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 "<nop>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 <nop>SpectralAxis and <nop>FluxAxis  (see comments by Jesus on June 22 2007) are necessary.

---+++ Ray Plante (Resource Registry WG)

---+++ Andrea Preite-Martinez (Semantics WG)

I approve the document.

---+++ Rob Seaman (VOEvent WG - Vice-chair)

YES I approve but I also wish to say:

   * It's refreshing to see tabular attributes presented as tables, rather than opaque UML class diagrams.

   * Given the several luminaries in the list of authors, expectations were high - and not slighted.

   * VOEvent may borrow the Spectrum Data Model to represent time series.  Perhaps SSA can similarly inform SEAP.

   * The "status of the document" still describes a working draft.

(as requested by Roy Williams)
<br/>
---

<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
xml	SsaUsagePR1.02.xml	r1	manage	11.5 K	2007-07-11 - 16:12	MarkusDolensky	updated metadata sample
pdf	theory-appendix.pdf	r1	manage	190.5 K	2007-07-11 - 16:26	MarkusDolensky	new appendix: theoretical spectral use case
This topic: IVOA > SsaRFC
Topic revision: r29 - 2007-09-09 - MarkAllen