After detailed feedback during the Victoria meeting, the Technical Coordination Committee expects to finalize this document.

Comments (please include your name) ......

Roy, Of course I don't entirely accept your description of DM...

I think that with our experience developing the spectrum DM and the SSA DAL, we now have software implementations and we have what Doug calls 'component data models' that are small bits which can be reused in different contexts. The Curation, DataID, and soon Characterization/Coverage models are pieces that are relatively simple and can be reused elsewhere.

The Spectral Line model, which is rapidly heading to 1.0, is a nice example of a DM which is relatively simple and on which we have achieved convergence quickly. So I think we have learned how to do it.

- Jonathan

From your description of the GWS work-packages:

VOStore should be carefully defined so that data store can be indirect, not controlled by VOStore, yet the metadata still well synchronoized with the data store.

If we replace "VOStore" with "VOSpace" (since VOStore being dropped), then I agree with you in general. I think that where we have two interfaces to a data-store, e.g. VOSpace and SkyNode talking to the same RDBMS, then the ensemble is responsible for keeping coherence, and we should write that into the spec. If you had some other requirement or use case in mind then maybe you could explain in more detail; perhaps a note to the Friday GWS session?

-- GuyRixon

Hi Roy, a few comments on the IVOA in 2006 doc.

• I think the document should have the word 'Technical' in the title - thus, 'Technical Assessment'
• In terms of layout - it would be good to number the sections/ subsections.
• Is it possible to give an indication of what WG areas impact on which others?
• I think we need to be clear as to the role of the IVOA Exec: I think that under your general recommendations section - the Tech Coord Committee should come to agreement on these issues - as they have the technical know-how. The Exec then just needs to endorse - but not decide.
• stds and docs group - i think that this should be re-instigated - as you note it oversees the process. (if it isn't re-instigated - you'll need to remove reference to it in the doc).
• As to maintaining support for older versions of standards - this isn't tenable longer term - c.f. how long did MS keep support for windows 95 going? Thus we need to be clear that support of older versions of the stds will cease at some point (or just bite the bullet and expect support only for the newer (=better) versions).

Under specific working groups - there is also the 'Astro-RG IG' of which I am chair.

Text for this would be:

'The Astro-RG IG' is a forum to provide formal cross representation between standard development in the wider 'Grid' computing world and the IVOA community. This occurs through cross membership of this group with that of the Astronomy Applications Research Group of the Global Grid Forum (GGF) (see http://forge.gridforum.org/projects/astro-rg/)

It provides a forum to discuss relevance of grid and web service standards for the IVOA, and conversely provides a conduit to feedback example usage experience of standards to the GGF. A recent workshop at GGF17 was held - see GgfIvoaMay06WorkShop - which addressed a number of common standard areas.'

Table 1 - add entry for astro-rg IG:

Yours, NicholasWalton

Concerning the use-cases for VOSpace, yes, let us have a document presenting them. However, should this not be written (or at least co-written) by the original proponents of VOSpace? It doesn't seem like something for the exec to set in isolation.

We should note that VOSpace is a standard for interfaces to existing storage system. The assumption is that many existing systems provide the facilities for one use case but none of them provide for all use cases, even the ones already known. Therefore, by adding a common facade to existing systems we get to use them without too much custom client-code and we get to combine them.

-- GuyRixon

This is a welcome report and contains much useful information. I have some comments.

I am concerned about 3 primary issues:

1) We need the vigorous partnership of major data providers to make the VO useful to astronomers. At CADC we have chosen to provide as much of our highest-quality content (from HST, CFHT, JCMT, Gemini) as possible through VO compliant channels. It has become perfectly clear to us that this is a major undertaking even when we are targeting largely SIAP access. SIAP is a modest and lightweight protocol but still requires serious effort to implement for a multi-mission archive like CADC.

We believe that the IVOA needs to devise a strategy to ensure that the “take-up” of VO standards by data centers (and other major data providers) takes place in the immediate future. Once we have a strategy we can have a debate about where the responsibility of the IVOA begins and ends. But we cannot simply say “Its not our responsibility” without being sure that the problem is effectively addressed. Failure of major data centers to fully buy into VO would be fatal to our endeavor.

2) The “levels-of-compliance” approach to DAL services needs to be re-thought. The reality for SIAP appears to be that the majority of data providers implement minimally compliant services even though full compliance still provides only a modest level of functionality. This compromises the usability of the services and is related to point 1, above. With minimally-compliant SIA services we get very weak functionality. Furthermore, the “levels-of-compliance” approach is a way of avoiding the production of “standards”.

I would find it far better to think carefully about what is necessary to produce a useful service and then require complete compliance. One could take into consideration both the issues of what is “minimally compliant” but still useful and could also consider the burden on data providers of full compliance. But at least we would be facing these questions directly and not avoiding them as the “levels-of’compliance” approach does.

3) We need to quickly develop more powerful standards for DAL services. SSAP is a very good step in the right direction and should be strongly supported. Other more powerful protocols need to be made available quickly. We need to show some real and substantial successes with VO and we can produce more powerful applications with more powerful (and more demanding) standards.

It might appear that these three points are in conflict. On the one hand I want to see more powerful standards and on the other hand I am pointing out that even simple standards like SIAP impose significant burdens of labor to implement them. There is no conflict. If we want powerful services we need to produce powerful standards and such standards are likely to impose costs on data providers. Data providers who want to give their users the benefits of VO must accept those costs and go forward. Those who choose not to do so will become obsolete.

-- DavidSchade - 14 May 2006

• IVOARoadMap-20060510.pdf: The IVOA in 2006: Draft 20060510