) next to the
“Run query” is a link to the currently configured query. Use this
(e.g., with your browser's bookmarks) to pre-configure searches you
want to redo later.The Virtual Observatory (VO) is a worldwide network of data and services (“resources”) in Astronomy, comprising some 30000 such resources. All of these are described through fairly detailed metadata records. Taken together, these form the Registry (cf. 2014A&C.....7..101D) that, hopefully, will let you find data relevant to your research without undue manual labour.
There are various ways to query the Registry; for instance, there are built-in interfaces in clients like TOPCAT or Aladin, there's the pyvo.registry module for searching for data from within Python, you can use RegTAP directly with a TAP client – and there's WIRR, which sits somewhere between the relatively limited interfaces of the general clients and the full (but raw) power of writing RegTAP queries.
There's a (currently somewhat outdated) worked-out use case for data discovery with WIRR available in the VO tutorial repo.
WIRR's query form lets you construct your discovery query using one or more constraints. These come in various types, which are briefly discussed below and come with in-line info (which you should at least briefly peruse when using a constraint for the first time). All constraints configured must match for a resource to show up in the results – hence, it's relatively straightforward to, say, look for Image services in the Radio band covering the Lockman Hole.
The star () next to the
“Run query” is a link to the currently configured query. Use this
(e.g., with your browser's bookmarks) to pre-configure searches you
want to redo later.
Search results come in a compact display showing the title, the “capabilites“ (that's the odd coloured links next to the title, with anchor such as SIA, TAP, or whatever), contact info, and possibly related services.
WIRR cannot query the services itself; it does not speak any of the VO protocols. It will forward you to “Web“ capabilities (which are just web pages), though. For everything else, you will have to take the links in the capabilities and paste them into your script or client. Or transmit them by SAMP.
As you fold out a result, you will see the resource description as provided by the data provider, a link the the full resource record below the ivoid (which may look a bit scary but is really helpful for advanced users), the source (something you should cite when you use the resource in published research; this will link to ADS if it's a bibcode), and the reference URL, which is where the publishers should say a bit more about the resource.
In the top right corner of the search results, there is a “SQL“ button. Hit it, and you'll see the query WIRR executed against the RegTAP tables. This is not pure ADQL, but it ought to be close enough to derive actual ADQL queries runnable against RegTAP servers. Click anywhere outside the query box to dismiss it.
Most VO clients can communicate among themselves and within reason also with web pages using a protocol called SAMP. You can use that with selected clients (TOPCAT can do that, for instance) to send them the links you have found.
To do that, run a WebSAMP-enabled SAMP hub (TOPCAT and Aladin have one built-in, for instance), and then hit “Connect to SAMP hub” in WIRR's lower right corner. Depending on what services you have discovered, you can then transmit the various service types and query them using the receiving clients. Note that TOPCAT as of this writing needs to have the corresponding window from the VO menu open to receive such messages, and Aladin does not support the SAMP mtypes WIRR needs yet.
In the Virtual Observatory, there may be relations between resources. These can be things like mirror-of or derived-from, but more importantly served-by (and service-for). The story behind the latter two is that some resources are just data – the data center says, essentially: "Look, I have this wonderful data collection with this description, and the table structure is this." For users, that's not too useful, since there's no information on how they can get that data.
To fix this, the data provider declares that the data collection is isServedBy some other service, TAP, for example, or maybe SIAP if a single image server exposes data from multiple collections.
In WIRR, if a resource has relations, we show an icon –
![[Related Icon]](related.png)
– if a resource has any related resources at all. Click on that
icon, and the form will be changed to show all related
resources.
Since the isServedBy relation has a special role – for
resources without capabilities, it's the only way you'll get at
the data –, we show a special icon,
![[Served Icon]](related-served.png)
,
when at least one of the relationships is such a isServedBy one.
Click on those to figure out
the access options for the data.
The remainder of this page briefly describes the constraint types available (the things you can pick from the “Add Constraint” button or in the selector on the left of each constraint).
This matches words somewhat loosely against the title, description, subject, and creator of resources. This is the closest you'll get to google on this service. Which is why it is the default constraint type.
The VO, somewhat regrettably, was built such that certain types of services were tied to certain types of products. These service types (“capabilities“) are still useful to constrain queries to certain data types (object, spectra, images…).
Note that in the days of Obscore and SIAv2, that in general is no substitute for a smart all-VO search for certain product type any more. Until someone has written a client for doing this, searching for “all SSAP services matching X” is a reasonable substitute, though.
The Unified Astronomy Thesaurus UAT is a hierarchical organisation of the concepts in Astronomy – a common keyword scheme, if you will. This constraint lets you pick from these concepts by typing a few letters you would expect to appear in the label of such a concept. When you actually select the concept, the thing in the input box will typically look like something-lower-case-with-dashes. That's all right, it is how the machine-readable identifiers for the UAT concepts look like in the VO.
Note that in the 2021 VO, many of the UAT concepts are inferred from conventional (as in: a wild mixture of legacy journal schemes with pure fantasy) subject keywords by the operators of the GAVO RegTAP network.
“Blind discovery”, finding data by physical constraints (rather than “I'm looking for Gaia data” is the holy grail of research data discovery. And it's surprisingly hard to get right, in particular as long as the data providers don't consistently provide good, expressive metadata. Still, it's worth a shot – and it is quite likely you discover interesting data you didn't know about if you try.
This constraint will only return resources claiming to cover a sky position (in ICRS), given as comma-separated decimal RA and Dec (or use an object name and use "Resolve name", or type something else and hope for the best). Note that not all services give a useful sky coverage yet, and services without sky coverage will be excluded by this constraint.
You cannot use this constraint for non-celestial (e.g., planet surface) coordinates yet. On the other hand, nobody is yet declaring such a coverage in the VO. We're working on it.
This constraint will only return resources claiming to cover a point in time; don't expect extreme precision here, but in case of doubt, the times should be for the barycenter in TDB. If you write a float, it is taken as MJD, except if it's between 1000 and 2100, in which case it's taken to be a Julian year. Youc an also put in a DALI-style date/time (YYYY-MM-DD[Thh:mm:ss]).
Since time input is always painful, the input will be red as long as the service will probably reject it, black otherwise.
Note that as of 2021, very few services give their time coverage, and with this constraint all others will be excluded.
This constraint will only return resources covering the specified spectral location (pick a unit convenient for you and complain to the operator if the spectral unit convenient to you is missing).
Note that as of 2021, very few services give their spectral coverage, and with this constraint all others will be excluded. It's a lot more robust to use the Waveband constraint.
Before there was proper spectral coverage declaration, people could already give a rough spectral coverage using the (predecessors of) the IVOA messenger vocabulary. Many do, but still you will exclude a few resources whose curators couldn't be bothered to properly declare their metadata if you use this constraint.
Match (with SQL wildcards, i.e., % is zero or more characters)
against UCDs, i.e.,
descriptors of physics. For instance, src.redshift would
look for resources serving redshifts, phot.mag;em.opt%
for any optical magnitudes.
To find UCDs, there is the “Pick one“ button; type a few words you would expect in the description of a column you are looking for and hit “Search“. This will show (potentially compound) UCDs and machine-generated descriptions pulled from the registry (i.e., some data provider had your words in descriptions for columns with the respective UCDs).
Note that not all curators publish column metadata to the Registry, and of those that do, few really do a good job.
This does a fulltext search (as for “Text Fields“) in the descriptions of the columns belonging to resources (note the difference to the text field search, which only looks at the resource-global description).
Note that not all curators publish column metadata to the Registry, and of those that do, few really do a good job.
These are some constraints that are probably only interesting in odd cases (e.g., an author called “Star”). Still, when you need them you'll probably be happy you have them.
Look for resources related to what the operand (an ivoid) refers to. This is what's behind the relationship queries you can do per result line. Note that this will only show the relationships that actually point to other Registry records. Relationships just having free text (e.g., “this tutorial uses TOPCAT“) will not be shown here.
Matches words against the resources' titles.
Only return resources the metadata of which have been updated more recently than this (data updates are not usually announced to the Registry). This could be useful in what's new-type searches.
Free text search in the resources' subject fields (keywords). This is like UAT Term, except that no unification in terms of terminology has been made. On the other hand, you will match the curator-assigned subjects here, which may be a win in some situations.
Free text search in the lists of resource creators (“author”). The main reason to use this rather than the general text fields search is when authors have names that may turn up a lot in titles and descriptions of astronomical resources.
These are a few constraints that are mightily useful in some special circumstances, but we figured these circumstances are rather uncommon.
res_detail is a table that in RegTAP takes just about anything not fitting anywhere else. This constraint offers a few canned queries against this table. For instance, you can constrain source facilities and instruments here (but again, not too many resources give such information). Note then when the operator says ILIKE, you can write % to match zero or more characters.
If you don't understand what the various operators offered here mean, don't worry: You probably don't need them.
This will match the resource's identifier or parts of that; use this to see what records there are from a certain data center (“authority”), or to get to the full resource record.
Look for resources describing the service at the operand (a URL); use this if you look for support on a service you only have the URL (rather than the ivoid) for.
Constrain by the resource type. This isn't useful for service discovery, but when you look for authorities (when claiming one) or tutorials, this is what you want.