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)

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 either NAVO or ESAVO (it doesn't matter which, choose whatever interface you consider nicer). This is sufficient if all you want is just register a handful of resources.

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

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.

Run a publishing registry

Even if your software has built-in support for OAI-PMH, the protocol behind information exchange within the Registry, running a publishing registry makes you part of a fairly complex, distributed bibliographic database; in particular, you'll be causing the VO's curators quite a bit of work if you later decide to not bother any more and just let the thing rot.

So, before you go down this road, ensure that the other two options won't work for you. Also, you should at least have had a brief look at the underlying VO standard, Registry Interfaces.

Having said that, OAI-PMH is not overly hard to implement, and starting from examples, writing VOResource records from whatever metadata you have isn't rocket science either. Also, some software (e.g., DaCHS) has built-in support for both VOResource and OAI-PMH), so once you're wrapped your head around what an authority is (see above), it's not so bad.

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:

Topic revision: r3 - 2017-11-23 - MarkusDemleitner
 
This site is powered by the TWiki collaboration platformCopyright © 2008-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback