 |
 |
|
|
Configuration
VO curationVirtual Observatory services are usually services that respond to special http queries with a document in a particular XML format named VOTable. In these VOTables it is important to include information about the origin of the data, authors, etc. In the configuration application a short explanation of the meaning of these fields has been given. For a better explanation you can take a look to the SSAP VO Standard (sections 4.2.5.5 and 4.2.5.6 mainly).
These fields will be used in the metadata header of all the VO query responses for this service. If, for instance, you take a look to: http://www.mylab.org/catalogues/exfilters/cs.php?format=metadata (where, remember, http://www.mylab.org/catalogues/exfilters/ should be the main URL that corresponds to your installation) in the first lines you will see a series of PARAMS giving the information that we have writen above.
Given that these values must be included in XML responses like the ones above and that XML has some restrictions about it, please, try to use plain text here (no html tags, no & symbols...). ConeSearch optionsConeSearch is a very simple protocol that is used in the Virtual Observatory for giving information about astronomical catalogues. You could want to take a look to the Simple Cone Search IVOA specification for more details (it is a very simple protocol, so it is a good point to start if this is the first time that you read a VO 'standard' document). As a summary, the main idea of this protocol is that it allows to search for objects in a catalogue around a given point (specified by its RA and DEC coordinates in decimal degrees) and within a Search Radius (SR) also in decimal degrees. Thus, a typical ConeSearch query would be something like: http://.../cs.php?RA=1.01&DEC=10.04&SR=0.1 meaning that we want objects in the catalogue around RA=1.01, DEC=10.04 (degrees) and within a radius of 0.1 degrees. The answer will be a VOTable (special VO document in XML format) containing the info in the catalogue for objects that match the conditions. In practice, this does not make sense if your catalogue does not include RA,DEC columns. But in the version of ConeSearch implemented by SVOCat we have included aditional options that allow to restrict the queries using other catalogue columns if you want to allow it. We will explain that later. In this configuration section we only ask for very simple information:
SSAP optionsSSAP (Simple Spectra Access Protocol) is a VO protocol designed to offer information about available spectra. You could want to read the IVO SSA standard for more information about it. If your catalogue does not include spectra you just won't active SSAP.
If you have spectra to offer and you want to activate SSAP you need also to choose one of the catalogue fields as 'object unique ID' (after you configure the fields) and you will also have to cofigure how to access your spectra and their properties in the Spectra section later. VO AvailabilityVO applications can query a VO service about its availability. If you configure it here as "Not available" those applications that query for this information will probably not query your service for data. But take into account that this won't make you service really unavailable. In principle, we recommend you to let this configuration option as 'Available' and don't worry about this.
|
