These are all interesting comments, and since they are in response to the
RFC, they should be part of the RFC log on the twiki. Please.
Thanks,
Bob
On 6/22/07 11:41 AM, "Jesus Salgado" <Jesus.Salgado-at-sciops.esa.int> wrote:
> Dear Doug,
>
> I fully agree with the fact that SSA can/should not impose any output
> format. I (with my VOSpec developer hat) would prefer to have a single
> format so the implementation is easier in the client but We (with my
> data provider hat) cannot accept I am forced to change to a format that,
> for my particular project/archive, it is not the better one to
> characterize my data.
>
> In fact, all the data producers consider their format is the optimal for
> their data and, even when some could consider the SED data model (both
> XML or FITS serialization) better, I do not know any data producer who
> share this opinion. On the other hand, the resources necessary to
> transform the legacy/original format to the SED DM one could result in
> many data providers never wanting to be part of the VO effort.
>
> So, in my opinion, we should live with legacy/native data and we should
> add the necessary info in the SSA VOTable output to enable a VO
> application to deal with this format (if possible)
>
> This is why, in case we have a native format referenced in the SSA
> output, some fields should be set as compulsory for foreign data, i.e.
>
> Dataset.SSA.SpectralAxis
> Dataset.SSA.FluxAxis
> (WARNING! The previous two fields which define the columns where the
> spectral coordinate and the flux are stored have disappeared from the
> SSAP spec 0.97 (they are in version 0.91)! We assume this is by mistake)
>
> (Note: In case it is assumed the VO client is forced to get the project
> datamodel from Dataset.DataModel and then, in some way, understand the
> structure of the file to allow the data parsing, etc., that would open
> another debate)
>
> Dataset.SpectralSI
> Dataset.FluxSI
>
> Using this very basic information we have been able to parse native data
> from ~18 different data providers without major effort.
>
> Best Regards,
> Jesus
>
> On Fri, 2007-06-22 at 07:19 -0600, Doug Tody wrote:
>> Two points here: >> >> 1) SSA does not impose any format; FITS is fully supported as an output >> format. >> >> 2) We are confusing the standard VO interchange format with the >> native project format as produced by the project and stored in the >> remote archive. Pass-through of native project spectra is already >> supported (this is format=native) and could make things easier for the >> minimally-compliant data provider - although metadata generation is >> probably the harder problem. >> >> In the ideal case, a service will read native spectra into an in-memory >> implementation of the Spectrum data model, and dynamically output whatever >> format the client application prefers (we already have software which can >> can do this). A good service implementation will support pass-through >> of native data as well; the client may or may not be able to do anything >> with this, but native data may be preferable for some analysis. >> >> The issue we are discussing here, is if there should be a recommended >> format for the VO interchange (wire) format, where the data has already >> been converted to be compliant with the Spectrum model. >> >> - Doug >> >> >> On Fri, 22 Jun 2007, Anita M. S. Richards wrote: >> >>>>> - 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 may be a controversial point, but my opinion is that VOTable may >>>> prove to be a better choice as an interchange format (not necessarily for >>>> archive storage) for metadata-rich VO spectra, especially since an SSA >>>> client already has to support VOTable for queries. Astronomy software is >>>> already adapting to support VOTable. I suspect that most new spectral >>>> services and client software will prefer to support VOTable over FITS. >>>> I think it is useful to suggest a format for those who will only implement >>>> one format. If there is sufficient disagreement we can reconsider the >>>> point though. >>>> >>> >>> I'm afraid that I am with Randy on this. Yes, VOTable is very convenient >>> for some things, but the danger is that if we emphasise it too much for >>> spectra, service providers may think that they don't have to support >>> anything else. In fact the majority of spectra at present are probably >>> FITS or ascii or goodness knowns what, and in future large data volumes >>> may be xml/binary. Why should we impose a format on spectra when we don;t >>> for images? VO tools can handle FITS perfectly well. If I had a large >>> collection of FITS spectra with numerous >>> extension tables giving the processing history etc., I would not want to >>> convert the whole lot to VOTable. Before someone says that it is >>> possible, yes, maybe, but that isn't the point - we should impose the >>> minimum requirements on data providers. It is much better to make sure >>> that there are tools which can handle at least the few commonest formats >>> and convert them if necessary - which may often involve converting a >>> sub-set or cutout. More importantly, the metadata must be preserved. But >>> that is not really the province of this discussion. >>> >>> >>> best wishes >>> >>> Anita >>> >>> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - >>> Dr. Anita M. S. Richards, AstroGrid Astronomer >>> MERLIN/VLBI National Facility, University of Manchester, >>> Jodrell Bank Observatory, Macclesfield, Cheshire SK11 9DL, U.K. >>> tel +44 (0)1477 572683 (direct); 571321 (switchboard); 571618 (fax). >>>Received on 2007-06-22Z16:03:37