Reprint of: Client interfaces to the Virtual Observatory Registry

Abstract

The Virtual Observatory Registry is a distributed directory of information systems and other resources relevant to astronomy. To make it useful, facilities to query that directory must be provided to humans and machines alike. This article reviews the development and status of such facilities, also considering the lessons learnt from about a decade of experience with Registry interfaces. After a brief outline of the history of the standards development, it describes the use of Registry interfaces in some popular clients as well as dedicated UIs for interrogating the Registry. It continues with a thorough discussion of the design of the two most recent Registry interface standards, RegTAP on the one hand and a full-text-based interface on the other hand. The article finally lays out some of the less obvious conventions that emerged in the interaction between providers of registry records and Registry users as well as remaining challenges and current developments.

Introduction

In Demleitner et al. (2014a), henceforth Paper I, we described the design and maintenance of the Virtual Observatory (VO) Registry as a distributed information system. Conceptually, it is a collection of, by now, about 15 000 registry records. To give the Registry’s users–astronomers, the library community, or even the general public–access to this collection, facilities have to be provided that allow focused queries against it. This includes common bibliographic constraints (by author, title or abstract term, year, etc.), but also constraints specific to a registry mainly concerned with data services (e.g., supported protocols or query parameters, metadata of published tables). In the design of such facilities, several challenges have to be addressed:

• different users have very different expectations and requirements

• the underlying data collection (i.e., the set of registry records) is changing over time

• the underlying data structure is fairly complex, and evolves itself as new standards and techniques are introduced in the VO

• as many uses require only a small subset of the types of metadata contained, partial resource descriptions should be retrievable

• the total data set cannot efficiently be transferred to clients as a whole

• registry records are frequently authored by persons not entirely familiar with the data model, resulting in inconsistent quality.

In consequence, no single user interface to the Registry can be sufficient. Instead, the VO community designed client interfaces, i.e., network endpoints with rigorously defined behavior and semantics, designed for use by programs that then present the actual user interfaces to Registry data.

We will begin this paper with a brief review of the various client interfaces that are or were used in the VO (Section  2). In Section  3, we proceed to describe the use some selected clients make of these facilities and the ways they apply and expose information obtained from the registry. A major part of the paper, Section  4, is devoted to a thorough discussion of the Registry Relational Model (RegTAP for short), one of the two registry interfaces currently being developed and deployed in response to the deficiencies of previous standards. In Section  5, the other new-generation interface is described.

While laying out some common use cases of Registry data in Section  6 we also point out common query patterns. Section  7 concludes with some speculation about probable future developments.

In the following, we refer to common Registry standard texts by their abbreviated names as introduced in Paper I, and again the capitalized word “Registry” refers to the abstract concept, while concrete services are written in lower case (e.g., a “publishing registry”). Concepts from VOResource and its extensions are written in small caps.