Listing and Filtering Resources (specifically Animals)

[thomasd-gea]

The endpoint to retrieve animals can currently not be filtered. Although we can deliver all animals that where ever present on a farm, this feels overkill most of the times. So, just delivering the "alive" animals would be more applicable. On the other hand, it is sometimes required to retrieve data about animals that are not on the farm anymore (e.g. "dead" or "off farm"). Is it planned to offer a common/generic/standardized filtering approach for resources? There are examples out there (e.g. for NoSQL-based databases: https://www.arangodb.com/docs/stable/aql/operations-filter.html) that allow you to filter based on the properties of an (JSON) object.

In the specific case something like ...&onlyAlive=false would be quite convenient, however, this would be very specific for animals and not generic.

[alamers]

As far as I know, we haven't discussed this in detail. The url-scheme, of which this would be part, has 'recommended' status right now.
In our solution, we have this notion of recommended naming for parameters. This allows a standardization of e.g. date range filters and dead/alive filters, without requiring a source to support them all. So, some form of naming standard would imho be very beneficial.

Not sure how far we can and should take it: it soon becomes quite specific for a source or a use-case. But a set of recommended naming for filter parameters seems easy enough.

[alamers]

I am working on the specs in the wiki: https://github.com/adewg/ICAR/wiki/Filtering-resources

[alamers]

I think the specs are fairly complete and require some discussion before we start filling out all the possible filters. I am not sure how much sense it makes to list all possible filters, the naming convention should cover it. Listing the most likely candidates and all recommended filters should be sufficient.

Some things to point out for the discussion:

• I've simply used concatenation for addressing subfields. It makes the filter names quite long but consistent;
• for composites: I added a recommendation to not allow a partial filter (using only a part of the composite) since that may be ambiguous
• for composite range filters: I added the From/To postfix to each composite field for symmetry and composability (in theory you can select the from and to using different units)
• the From/To postfixes are both for date ranges as well as numerical ranges. Since they do not have a special syntax, they could conflict with subfields in theory, but I expect that not to be a problem.

[alamers]

As discussed in todays meeting, some todo's:

• write down why we don't use odata (implementation impact, performance management) or at least its syntax (expectation management)
• instead of string concatenation, change to .-form
• a suggestion/naming recommendation for fuzzy matching?
• as a next step/extension: object pattern matching as an alternative POST to ../search?
• relation with paging / name clash with paging parameters

[alamers]

I've also reviewed the current spec wrt filter parameters: I notice that we now have:

• animal-id-scheme / animal-id ( in /animalSets)
• start-date-time / end-date-time in most end points

Those would be redefined by this proposal to:

• member.scheme / member.id (assuming that we leave out the top member field)
• eventDateTime.from and eventDateTime.to

[alamers]

I've updated Filtering resources with the feedback as provided above.
Things to consider:

• what to do with existing defined parameters in the recommended URL scheme?
• the current convention is to use '-' instead of '.' for concatenation

[alamers]

As discussed in today's meeting: we change the '.' to '-' for concatenation.

[alamers]

As discussed in the meeting of 25th Feb, this ticket can be closed.