Advanced Search Techniques

The free text field in the search interface does not just look for exact matches — it ranks results by relevance across several indexed fields at once. This is convenient for casual searches, but it also means the top result is not necessarily the only correct match, and a search for an exact acronym or ID can be diluted by loosely related hits.

If you need precise results, you can bypass the relevance ranking and query individual indexed fields directly. The examples below show how to do this. Just type the given strings into the search field to reproduce the described behaviour.

To search for a specific entry_id, enter id: followed by the value, e.g.

To search for a specific acronym, enter the field name entry_acronym_s: followed by the acronym:

Fields whose name ends in _s (string) or _ss (string list) are stored without any tokenization, so they support the * wildcard for prefix/substring-style matching. This lets you find all entries with a similarly named value for that field, for example all versions of an acronym:

Wildcards are of limited use on the numeric (_l), date (_dt) and date-range (_rdt) fields — use the range syntax below for those instead.

Whitespace needs to be escaped with a backslash, otherwise it is interpreted as an implicit AND between two separate terms. The following searches for all versions of the CMIP5 DRS path cmip5 output1 CSIRO-QCCCE CSIRO-Mk3-6-0 1pctCO2 mon ocean Omon r1i1p1 ... tos:

Whitespace is not the only character that needs care. The query syntax also treats + - && || ! ( ) { } [ ] ^ " ~ * ? : \ / as syntax, so if a value you are searching for happens to contain one of these characters (for example a colon in an identifier), escape it with a backslash as well or the query may fail to parse or match unexpectedly.

The free text search allows the set operators AND, OR and NOT, which can be nested in parentheses:

AND is the default operator: whitespace between two clauses behaves like AND. It is also allowed to replace NOT with a dash (-).

Fields whose name ends in _l (the datatype long) or _dt (date) can be searched as a range. To search for datasets between 1000 and 10000 bytes:

An open-ended bound is also allowed, for example to search for datasets larger than 1 TB:

You can also use an open range on both sides to check whether a field is set at all. Since projects are not "real" entries in the CERA sense, they do not have a progress acronym; the following finds all entries without one:

The same works for numeric fields — note that the canonical form uses * on both ends, field:[* TO *], rather than a specific value such as 0:

Dates need to be provided in ISO format, e.g.

Ranges work the same way as for numbers:

publication_date_dt (when the entry was published, as opposed to creation_date_dt, when the metadata record was created) can be queried the same way.

geo and date_range_rdt look like a normal field and a normal date field respectively, but they are not: querying them correctly requires specifying a relationship (does the entry's coverage contain, intersect, or lie within the given box/interval?) rather than a plain value or [A TO B] range. In the web interface, the recommended way to filter by these is the dedicated Map (bounding box) and Temporal Coverage selectors in the search sidebar, each of which lets you pick "Contains", "Intersects" or "Within" from a dropdown and takes care of the underlying syntax for you.

If you want to type the equivalent query into the free text field by hand, it looks like this:

(op can be Contains, Intersects or Within; the coordinate order in ENVELOPE() is west, east, north, south.) This is genuinely advanced usage — get the exact syntax right, or use the sidebar widgets instead.

Not every field is available for every entry, and not all of them are exposed as filters in the sidebar — some are only queryable through the free text field. The suffix of a field name indicates its type:

The complete, authoritative list of request parameters accepted by the search API — including parameters not exposed in the GUI, such as facet, facet.field and fl — is documented at /wdcc-api-docs.