The workshop was the first meeting of Opticon's working group on Interoperability. These were the partipants:
(q.v. on-line, hyperlinked list of participants).
This group is effectively a super-set of AVO's WA2 on Interoperability; both are led by Françoise Genova of CDS. Any decisions made bythe Opticon group are likely to count as AVO decisions and vice versa.
Since there were many people at the workshop, there was much wide-ranging discussion and few firm decisions.
There were presentations on interoperability plans for AVO, NVO and AstroGrid, presentations on individual projects and technologies currently independent of the VO projects, and detailed discussions of the VOTable proposal and of the GLU.
The meeting coopted one person from each of AVO, NVO and AstroGrid to be a contact for on-going work on interoperability.
The slides from the presentations will be on the web soon, so here I just list the subjects with very sparse notes.
The AVO planning is focussed on the production of limited prototypes in their phase A. These will by based on Vizier, Aladin and other tools developed at CDS.
NVO emphasizes interoperability without forcing any changes in the archives that interoperate. This seems to be a political necessity in North America.
Since we're not planning major prototypes, our "plans" are mainly a list of areas where standardization is needed.
This project has integrated (federated?) all of Vizier "seamlessly" with an existing HEASARC archive by using the AstroRes (i.e. XML) output built into Vizier. The integration has been made without changing the user interface of the HEASARC system.
This project is now ended. ISAIA attempted the integration of astronomy and space-physics data at a very deep level: e.g. common metadata dictionaries. By trying to serve a very broad community, ISAIA bogged down and the project was stopped. There are obvious comparisons with AstroGrid.
This project has been examining use cases for federated archives. A list of ~20 representative queries is sought.
GLU is the Générateur de Liens Uniformes, and is an important part of CDS services such as Vizier. It generates URLs for data-services, and for specific queries to those services (i.e. with the query parameters encoded in the URLs) starting from a form of resource catalogue.
Uniform Content Descriptors (UCDs) are a namespace of standard labels for astronomical quantities. They are part of the metadata we need to add to tabular data to make the tables intelligable to VO software. The concept of UCDs is generally accepted, but the existance of the actual UCD namespace seemed to come as a suprise to some of the audience. The current UCDs are the union of all the types of columns in all the tables in Vizier, and there is some doubt as to whether the namespace is properly optimized yet for VO work.
A talk on authentication issues generated a lot of questions and comment but no immediate decisions. In general, the European workers seem to be more concerned about authenticated use of the VO whereas the Americans don't consider it a priority. Bob Hanisch suggested that NVO would be happy to adopt a working design demonstrated by AVO/AstroGrid. Coffee-time discussions suggest that there will be some initial resistance amongst European archivists to moving away from their existing UID/password schemes. AVO/AstroGrid will, at some point, have to "sell" a new system for authentication to the community, so I guess we will need to design one and test it up-front.
Roughly a thrid of the meeting was spent discussing the VOTable proposal. V0.4 of the VOTable specification was current at this time.
The community is split, with one faction welcoming the new format (but not necessarily approving the details in the current proposal) and another preferring to enhance or extend the use of FITS for tables.
There is as yet no agreement on where VOTable should be used. Four viewpoints emerged:
There may also be grounds for rewriting the VOTable DTD as an XML schema. This would allow automatic, semantic checking of the content of the encoded tables.
The variety of encodings for the table data was brought into question. There was a consensus that embedding CSV in a VOTable document is not good (but linking to an external CSV document is OK). There was a suggestion, but no consensus, that all the table data should be external to the XML documents unless the data themselves are written in XML (this only works for small tables).
The decision of the meeting was that VOTable should be progressed (i.e. FITS is not sufficient), but that the first actionable version of the specification should cover only representations of concrete tables, not resource catalogues or queries. V1.0 of the VOTable specification is to be prepared in time for the Munich VO conference in June. V0.5 is to be released a few weeks after the Strasbourg meeting.
Contact persons were co-opted to coordinate interoperability work in each of the three VO projects: Françoise Genova for AVO, Ray Plante for NVO and Guy Rixon for AstroGrid.
GLU is fairly well known and is used at various sites around the world. The discussion in Strasbourg concerned how GLU works, what it limits are and how it might be fitted into a VO architecture.
I intend to present a separate report on the structure and application of the GLU in the next few days, so the notes here will be brief.
GLU translates Uniform Resource Names (URNs) into Uniform Resource Locators (URLs). The URNs are known as "GLU tags" and can be embedded in HTML documents; the translation to HTML anchors quoting URLs is invoked by a web-server when it serves the HTML document. GLU tags can also be held in other documents and the translation can be done by an explicit call to a GLU library.
URLs from GLU can point to either static or dynamically-generated data. To support the latter case, GLU has a rich and complex mechanism for subsituting variables into the URL, and this is typically used to set query parameters.
GLU translations are specified by a "GLU dictionary", which is a file local to the node doing the translation. The dictionarys are written in "parfile" format, not XML, but viewers for the dictionaries are available that display the contents as XML.
GLU translations do not need to involve the network; all the dictionaries can be local. However, dictionaries are normally shared between sites by mirroring, and the GLU package provides GLU daemons to do the mirroring.
GLU translations allow more than one site for a given service, with intelligent choice amongst the replicas. A GLU translator can be set to pick the fastest-responding site amongst a set of replicas based on fairly up-to-date measurements of response times.
A GLU dictionary has to be a form of metadata catalogue and a form of resource catalogue, both of which are functions that we need for the VO in addition to name translations and managment of replicas. However, the metadata it stores are very focussed on the ASU-like URLs it normally generates. There is no standard way to generalize the GLU metadata to the level likely to be needed for the VO.
It is not clear whether or not GLU can format a URL for a query plus a set of query parameters as a document (e.g. in VOTable) to send to that URL.
There seem to be several ways GLU could be used in the VO:
GLU is almost certain to be used as-is in VO prototypes made for the summer of 2002.