Simple Spectral Access RFC

The RFC period for SSA V1.0 is closed.

---

About this RFC

This document acted as RFC centre for the Simple Spectrum Access Protocol. Comments of the RFC- and TCG-reviews refer to SSA v1.01 and resulted in v1.02.

Further information on the SSA protocol and associated Spectrum data model can be found on the 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 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.

---

Implementations

We don't know about SSA-related implementations unless we hear from them, so this is undoubtedly an incomplete list. We do not know the current status of many of these implementations nor have all the implementations mentioned here been carefully tested at this point. Nonetheless it is enough to demonstrate considerable early experience with SSA V1.0. (Most or all of these will need minor updates to the latest spec since it was only just released).

• Libraries and Toolkits
  • DALServer Java toolkit (NRAO, NVO). Does both queries and datasets.
  • Spectrum Java library (SAO, NVO). Spectrum data model.
  • C# SSA toolkit (JHU, HVO). Used for SDSS DR6 services.
  • Perl implementation (VO-Paris, Igor)
  • PHP implementation (STScI)

• Services
  • NRAO (DALServer based) JHU/SDSS proxy service sample query
  • Selected GOODS/FORS2 spectra at ESO (DALServer based): metadata, sample query
  • JHU/HVO SDSS DR6 spectra native service
  • INAF (Milan-Marseille) VVDS-DEEP spectra
  • ST-ECF grism spectra (DALServer based)
  • VO-Paris (Russian 6m, LSPEO) - SpectrumDM; not sure of SSA service status
  • NOAO has a partial SSA implementation (getData for Coude Feed spectra)
  • LAEFF/SVO have an SSA service that is used for TimeSeries light curves

• Clients
  • SPLAT Java client (Starlink)
  • JHU Spectrum services Java Web client
  • Specview Java client (STScI) - just coming up; VOTable support incomplete
  • VOSpec (ESAC) - Not sure of level of support for SSA V1.0
  • VirGO v1.2.1 beta (ESO)

---

Latest Updates

• new appendix: Theorectical Spectral Access Use Case (.pdf)
• replacement for appendix: Sample Metadata Query Response (.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.

Omitting both values indicates an infinite range which accepts all values.
(sect. 8.7.2)

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.

---

• Page 49, Query response example, 3rd line: there is "//" missing in the schema location (by IgorChilingarian)

• • Response by MarkusDolensky: Thanks for spotting Igor.

---

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

---

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

---

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

---

(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 DataID CreatorDID, Date, and Version for a dataset created from multiple parent sets.
  5. In Appendix A on p50: In <Group ID= "Association" &> <FIELDref ref ="AssocID"> :Is this correct? Are AssocKey and 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 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?
     1. Specifying datatype=char and arraysize=* does not give the actual allowed syntax, see the case for POS.
     2. 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 (CreatorDID, DatasetID, and 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 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. DataID.DatasetID is defined in the data model document, but we should probably clarify it here as well. - DT

• Associations
  1. 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
  8. 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 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)

---

---

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 SpectralAxis and 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.
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.
( on behalf of Chair, Keith Noddle )

Matthew Graham (Grid & Web Services WG)

I approve this document.

Bob Hanisch (Data Curation & 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)

I approve the document.

Francois Ochsenbein (VOTable WG)

I approve the document -- which is really well written and where all components of the model can easily and quickly be located.

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

Ray Plante (Resource Registry WG)

I approve this document.

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)

---