The Registry is the collection of metadata on the services in the Virtual Observatory. See IvoaResReg for more information about why you want your service in.

Registering a service requires two steps:

1. create a resource record (this means producing an XML document valid according to a schema called VOResource; example)
2. add the new resource record to the Registry (which in the end means that someone, possibly you, will have to offer your record through a protocol called OAI-PMH).

There are several different ways to do that; which one is the right for you depends, in particular, on how many services you want to register and how often their descriptions are expected to change (yes, you should keep your Registry entries up to date...). Below, we discuss three options:

• Use a web browser (best if you have only very few and rarely changing records)
• Use purx (best if you can machine-generate your resource records but only have a dozen or so resources)
• Run a publishing registry (all other cases)

In all three cases, note that the searchable registries (which are what clients generally use), it takes about a day for them to notice any changes you make. For the Heidelberg RegTAP registry that is used by many clients, you can speed up re-harvesting by using the harvest trigger.

Choosing an authority identifier

Unless you use purx, you will first have to choose an authority identifier.

That's a short string that will be the “host part” of the identifiers of your services (the “ivoids”), for instance ivo://my-authority/foo/bar. Ideally, use an abbreviation of your institute or organisation, perhaps with your country added. If your DNS name is short enough, that's ok, too.

Consider, however, that the authority identifiers must be globally unique. The web interfaces won't let you create an authority that's already taken, but please don't be too generic (“astro” or “star” for instance, would probably not be appropriate authority identifiers).

Once you have chosen an authority id, make sure it is not taken already. The Registry contains a resource record for every authority taken, so this can be established by querying the Registry itself. You can use a WIRR query to do that (replace "org.gavo.dc" with what your new authority id in the form above).

With the browser interfaces discussed below, your authority id will be your login, and the services will claim the authority for you.

When, on the other hand, you run run your own publishing registry, the record for your authority should be the first thing you publish (that's “claiming the authority”). You can start from a ( sample record to write the record.

Registration with a web browser

To register your service, the easiest way is to use one of the web-based Registry publishing interfaces by using ESAVO. This is sufficient if all you want is just register a handful of resources that change rarely, if ever.

A little walkthrough of the process was given at the first ASTERICS European Data Provider Forum.

To make the harvest trigger pull your changes, use ivo://esavo/registry in “Registry's ivoid”.

Registration via purx

Here, you write a VOResource document yourself, then put the result on a normal web server, and then point a “proxy” (to the rest of the Registry) service to that URL; the only such proxy service available right now is at http://dc.g-vo.org/purx/q/enroll/custom.

Writing valid (and search-friendly) VOResource documents isn't trivial, so you will very typically start from example records or rely on publishing software to generate them.

Most of this (including links to sample records) is explained on PURX' info page: http://dc.g-vo.org/purx/q/enroll/info.

To make the harvest trigger pull your changes, use ivo://purx/registry in “Registry's ivoid”; however, there is no way to force purx to look at your record again. Complain to gavo@ari.uni-heidelberg.de if this bites you.

Run a publishing registry

If you have many (say, 10 or more) resources to register, or if these change often, you should definitely run your own publishing Registry. Some publication software has code to do that built in; if you run something else, ask around on the registry mailing list, as multiple data centres have already implemented at least the OAI-PMH part. Even when running off-the-shelve software, at least skim the underlying VO standard, Registry Interfaces, to have an idea of how all this is supposed to work togeter.

With a set of records and some OAI-PMH service, making sure your registry records are in the VO and updated whenever you update them then is as easy as going to the RofR validator (there's nothing wrong with also testing against the OAI Repository Explorer for non-VO interoperability) and then adding your OAI-PMH endpoint (a “publishing registry” in VO-speak) to the Registry of Registries (or RofR for short), which the validator will let you do when you pass (but no earlier). After that, your records will be picked up by the searchable registries and hence the clients in a day or so.

If you want or have to write your own software to produce VOResource and/or speak OAI-PMH, here are some pointers:

• At CDS they have started with the “official” OAI-PMH Perl server and extended it to fit their needs
• At STScI there is a C#/aspx-based implementation
• https://www.openarchives.org/pmh/tools/ contains a large variety of non-VO OAI-PMH tools.
• In particular when you are running a JSP infrastructure, having a look at NCAR's OAI-PMH implementation might be a good idea.
• We are currently trying to get one or more reference codes into https://github.com/ivoa/publishing-registry. In case you are starting something new: please have a look at this.