Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Extended Age Query not performing search as expected, strict mode is not being followed #6271

Open
grantfitzsimmons opened this issue Feb 24, 2025 · 2 comments · May be fixed by #6206
Open
Assignees
Labels
2 - Queries Issues that are related to the query builder or queries in general geospecify
Milestone

Comments

@grantfitzsimmons
Copy link
Member

Describe the bug
I am searching for all objects that fall within the Albian age (which has the start and end period by default set to 125-125):

Image

My query is set to "strict" for the search, so I would expect to only return all objects that have all age values between 125-125. See #5180 for more specific expectations.

Image

For example, the Collection Object with the catalog number G014 should have a range of 66 - 125 since it has an end period for Late, Cretaceous (100.5 - 66) linked to its relative age and an absolute age of 100.

Image

Expected behavior
These records should not be returned in this query. Strict mode is not functioning as expected,

Crash Report

If the bug resulted in an error message, please click on "Download Error Message" and attach it here. If there is no error, please follow these instructions to download your System Information.

Please fill out the following information manually:

@grantfitzsimmons grantfitzsimmons added 2 - Queries Issues that are related to the query builder or queries in general geospecify labels Feb 24, 2025
@grantfitzsimmons grantfitzsimmons added this to the 7.10 milestone Feb 24, 2025
@acwhite211
Copy link
Member

acwhite211 commented Feb 25, 2025

I identified the misunderstanding. The strict age query is designed to look through all the paths from CO to Chronostrat/AbsoluteAge. If any of those paths fall within the bounds of the age query range filter, then the CO will be returned in the query.

These are the paths it checks:

  • collectionobject__absoluteage__absoluteage
  • collectionobject__relativeage__agename__startperiod
  • collectionobject__relativeage__agename__endperiod
  • collectionobject__relativeage__agenameend__startperiod
  • collectionobject__relativeage__agenameend__endperiod
  • collectionobject__paleocontext__chronosstrat__startperiod
  • collectionobject__paleocontext__chronosstrat__endperiod
  • collectionobject__paleocontext__chronosstratend__startperiod
  • collectionobject__paleocontext__chronosstratend__endperiod
  • collectionobject__collectingevent__paleocontext__chronosstrat__startperiod
  • collectionobject__collectingevent__paleocontext__chronosstrat__endperiod
  • collectionobject__collectingevent__paleocontext__chronosstratend__startperiod
  • collectionobject__collectingevent__paleocontext__chronosstratend__endperiod
  • collectionobject__collectingevent__locality__paleocontext__chronosstrat__startperiod
  • collectionobject__collectingevent__locality__paleocontext__chronosstrat__endperiod
  • collectionobject__collectingevent__locality__paleocontext__chronosstratend__startperiod
  • collectionobject__collectingevent__locality__paleocontext__chronosstratend__endperiod

In the extended age query issue #5180, this is how the strict and non-strict modes are described:

Users can choose to either run the query as 'strict', meaning only results that fall entirely within that range will be returned, or they can be 'non-strict', meaning any overlap will be returned. This is simply a yes or no option in the query line.

It seems the misunderstanding is what strict mode means. Here are the conditions used when filter each chronostrat:

  • Here are the variable definitions (ignoring uncertainty values for simplicity):
    • aqsp the specified age query filter start period
    • aqep the specified age query filter end period
    • cssp the chronostrat's start period
    • csep the chronostrat's end period
  • Given the assumption that aqsp >= aqep and cssp >= csep, which is enforced in the code.
  • For non-strict mode: cssp >= aqep or csep <= aqsp
  • For strict mode: cssp >= aqep and csep <= aqsp
  • These conditions reflect if the age ranges are partially or fully overlapped.

This implementation is reflected in the testing instructions for #5272

Going through the example for the CO with CatalogNumber 'G014'.

  • From the age period query, the age filter query start period is 125, and the end period is 125
  • The strict filter will require the CO's start period equal to 125, and the end period equal 125
  • collectionobject__absoluteage__absoluteage is 100 with no uncertainty, so this fails the strict filter.
  • collectionobject__relativeage__agename__startperiod/endperiod is 100.5 - 66 with no uncertainties, so this fails the strict filter
  • collectionobject__paleocontext__chronosstrat__startperiod/endperiod is 125 - 125, the Albian period, so this passed the strict filter, therefore the CO record is returned in the query results.

From the description of this issue, it seems that strict mode means that for all non-null paths, take the smallest and largest numbers to create a "meta" start and end period for the CO, and then evaluate the filtering condition on that. In this implementation, which filtering condition would be used? So, for the CO with CatalogNumber 'G014', the meta start/end period for the CO would be 125 - 66, and the desire would be for it to fail the strict query filter.

To summarize, the strict mode currently is implemented to adjust the filtering condition of the age query to reflect partial or full overlap, while this issue wants a single meta start and end age for each CO to be used.

I could implement this behavior as another mode called "meta-strict" or "super-strict"? Or I can fully replace the current strict mode implementation?

The new version of the age name filter displays the "meta" age range of each CO record, so it will be easier to make these adjustments in the branch. #6206

EDIT: I'm working on implementing the strict behavior described in this issue.

@acwhite211 acwhite211 linked a pull request Feb 27, 2025 that will close this issue
3 tasks
@acwhite211
Copy link
Member

I implemented the new strict age query behavior in #6206

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2 - Queries Issues that are related to the query builder or queries in general geospecify
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants