Registry Upgrading

Notes of meeting 2006 June 7 Leicester

1. Present KevinBenson SilviaDalla AnitaRichards GuyRixon
2. Motivation
   1. Science workshop users repeatedly say that they want to be able to identify suitable data by more than just position.
   2. Several priority science cases require such searches, for example locating data in specific wavelength ranges at arbitrary sky positions or seaching by time or for a specific column/UCD.
   3. We want to make it easy for data providers to register the required information.
   4. Helioscope needs the registration of solar data.
3. The problem
   1. Most data sets in the Registry have no or inadequate coverage information and often almost no details apart from name.
   2. The entries are presently automatically generated and even if additional information is provided manually it is likely to be overwritten.
   3. Schemata need updating.
   4. We have a commitment to the IVOA to be consistent by end August 2006.
4. Functionality the DSA should support/provide
   1. Tool for data provider to generate metadocs describing service
   2. Facility to generate additional description especially coverage
      • Basic immediate need: absolute URLs for schemata to generate documents to allow manual xml editing
        • Local validation essential
        • Pretty e.g. html viewer useful (Chinese VO?)
      • Next step: XForms which can be saved and redited
   3. Data provider requests Registry to pull in metadata
5. Registry querying
   • Need to be able to search by spatial region and by interval on spectral and temporal axes
     • Minimum service (e.g. for AstroScope, HelioScope) - predefined fixed coord system e.g. J2000 for extrasolar astronomy; predefined fixed units; predefined fixed shape for spatial region e.g. circle.
       • This implies that registry entries must include information in the fixed units etc.
       • Eventually wish for coord and unit conversion tools * Also want to search for specific columns e.g. redshift (i.e. by UCD) and by other allowed element values

Implementation

We need to be able to provide a means of improving the coverage information in the registry as soon as possible. In the short term this will probably be implemented by people already familiar with AstroGrid, probably employed by it! by manually editing xml. In order to allow the results to be validated and to be uploaded to the Registry in a stable way, we need:

• Change in architecture including from push to pull registration
• Implement new schemata
  • 1 week
• Make xml schemata available for data publishers to use and publish to registry
  • 1 week
• Testing, integration, documentation
  • 1 week + scientists time

The next step is to provide XForms for people to fill in as an alternative? replacement? for direct XML editing (ideally both, interconvertably).

• Implementation of registry entry Xforms
  • 1 month+?
• Integration using test rig and documentation
  • 1 week + scientists time

Future refinement

Improve ease of registration of CEA applications i.e. tools as well.

The Registry contains descriptions of data, data access services tied to specific data sets and separate tools. Ideally, there should be separate searches for tools like crossmatcher, HyperZ and for data, and a single search for data should seamlessly return an suitable access interface without a separate search (i.e. if I enter ranges in space and time and the INT-WFS has potentially suitable coverage, the only further choice might be ADQL or Cone; for MERLIN the choices might be ready-made images v. MERLINImager).

-- AnitaRichards 07 Jun 2006

KMB has made a thorough investigation of XForms including the technology choices available for rendering them. Due to his workload he's handed this over to JDT, since JDT is also interested in using XForms to ease deployment of applications into CEC-CL servers. -- JohnTaylor - 09 Jun 2006

--

Clarifications

"Make XML schemata available for developers": make sure that the schemata for registration documents are correctly published on software.astrogrid.org such that service providers can use them in XML editors when altering resource documents.

"Change in architecture from push to pull registration" has two parts.

• Have the registry read the registration document from the registering service as a web page (HTTP download) rather than uploading it as a SOAP part.
• Cache the registration document, as generated by service software, inside the service configuration such that deployers can edit it before downloading it into the registry.

These are independent goals. Pulling the documents from the registry controls makes it easier to secure the registry against tampering. Caching the documents in the services of origin lets the service providers add metadata that are missed out by the automatic registration.

"Implement new schemata" means to make a registry service (and delegates) that can handle the v1.0 registry schemata. These latter schemata allow better description of coverage than the current schemata.

Once we have a registry that handles v1.0 schemata, we can experiment with better interfaces for searching on these metadata in the Workbench.

-- GuyRixon - 08 Jun 2006