OGCAPI-RECORDS Part 2 (Facets) - Retrieving Records in (a) Bucket(s)?

[davidblasby]

As I mentioned in my quick review (#484) that one of the outstanding functionality is how to get the records in a bucket.

Here is a typical UX (this is GeoNetwork 4). The "facets" are along the left side. These are directly expressible in the OGCAPI-Records Part 2 Facets manner (see my implementation - geonetwork/geonetwork#100).

Typically, the user will "tick" a few of these boxes - and the text search will be limited to the records in those "buckets".

I don't see how the you can do that in the current Facets definition.

1. My original thoughts were that you could do a 1:1 relationship between term facets and the equivalent queryable (note - this linkage is a bit ambiguous as I put in my previous issue).

   I've currently implemented queryables as a loose-text search - although the spec says:
   Equality predicates with any queryable not already listed in this table.
   I found this difficult to use - for example, its really useful to have a loose-text search on a title queryable. Having the user EXACTLY type in the title wouldn't be reasonable.

2. However, for things like a histogram facet, you'd have to do a between (property >= min AND property <=max). I think this would require something like CQL (i.e. Features filtering)

3. The filter facet implies some type of ability to do something like CQL. The format for the expression isn't defined. Perhaps this should be augmented with a human readable title as well?

So, I expect to use facets, a query mechanism needs to be defined: The user selects a set of buckets and they are used as a type of filter to the query (/items) endpoint.

[jahow]

@davidblasby here are hopefully a few clarifications:

1. Term facets have indeed a 1:1 relationship between a property and a facet; by calling GET /collections/<collectionId>/facets, the client gets a list of the facets that are included in the responses; the "term" facets have a property property to indicate which field is used for that facet.
   So to filter on a given facet a CQL filter like so should be applied: <facetProperty> = <selectedValue>
2. Same for histogram, the /facets endpoint will let the client know which property to use for the CQL filter
3. The filter facet indeed has to give a valid filter for each value; this filter can then be applied right away by the client. The format isn't defined clearly, we discussed this and agreed on this (I don't remember why exactly). Maybe the spec could use an improvement there.
   As for the human readable label, it is a good idea! I'll add it to the spec

So, I expect to use facets, a query mechanism needs to be defined: The user selects a set of buckets and they are used as a type of filter to the query (/items) endpoint.

Yes, this is the whole point of facets basically: letting the user narrow down their results. Maybe this could be clarified as well?

[davidblasby]

Hi, Olivia, thanks for your feedback.

I did add CQL support to GN5 so I could retrieve the documents in a bucket - this is going well. This should definitely be mentioned in the specification.

One of the issues I have found is with bounds inclusivity in histogram buckets with how Elastic computes the min/max for a bucket in an aggregation. For almost all of the buckets, you can do a CQL like this:

property >= min AND property < max

However, for the "highest" bucket you need to include the max in the request (max is now <=):

property >= min AND property <= max

This is especially needed in fixed-bucket-number aggregations.

I ended up adding a x- flag in the bucket to let the client know they needed to do this.