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).

• 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 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.

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

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.

• 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.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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).

• Use a web browser (best if you have only very few and rarely changing records)

• 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 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.

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

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.

• 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.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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).

• 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.

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

Registration with a web browser

Registration via purx

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

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.

• 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.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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).

• 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 that change rarely, if ever.

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

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.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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).

• 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

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

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.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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).

• 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

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:

• 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.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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).

• 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).

Registration with a web browser

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:

• 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.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

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).

• 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)

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:

• 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.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Registering a service requires two steps:

• 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)

Registration with a web browser

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).

Registration via purx

• 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.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->

Registering a service requires two steps:

[1] create a resource record (this means producing an XML document valid according to a schema called VOResource) [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 do 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 few 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)

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 the one you like better). This is sufficient if all you want is just register a handful of resources.

In either case, you will 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).

Registration via purx

Here, you write a VOResource document yourself, then put the result on a normal web server, and then point a (non-standard) service to that URL. 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 pubishing registry

Even if your software has built-in support for OAI-PMH, the protocol behind information exchange within the Registry, running a publishing registry is a non-trivial effort; in particular, you'll be causing the VO's curators quite a bit of work if you later decide to not bother any more. 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.

Anyway, once you have all that, 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 RofR exactly there. Your records will be picked up by the Registry 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.

<-- 

 

 

 Set ALLOWTOPICRENAME = TWikiAdminGroup
 
 
-->