Add support for optional automated nesting of repeated search criteria (from 985)

[gigamorph]

Problem Description: For triples that can take multiple hops using the same predicate (transitive), Rob is looking for a way to avoid specifying each hop and repeating the associated criteria.

Given the following, ideally the user would only have to enter the data in the blue box, and the system would automatically add criteria in the green box. Note that this example uses name but the feature should probably repeat everything in the group that the first partOf was added to and use the same group type. At the lowest level, the transitive search term should be omitted.

The classification term is another term configured to a transitive predicate.

TBD if the number of times the criteria is repeated would vary by term.

TBD if this should be a search option vs. a dedicated search term. But, pretty sure the system should not force the repeating behavior.

Expected Behavior/Solution: If a special transitive search field (A*), which has a non transitive field (A) and is configured with a partitioning relationship (P), is used with a subquery of any structure (SQ), then the query to be produced is nested to a configured degree (N) through the partitioning relationship.

A*: SQ -->

A: { OR: [ { SQ }, P: { OR: [ {SQ}, P: { SQ } ] } ] }

Where Ps can be nested to the configured degree, N (with 2 or 3 seeming like a reasonable default)

e.g.

Object produced_at*: { name: california } Would be

Object produced_at: OR: [ { name: california}, part_of: { OR: [ {name: california}, part_of: {name: california} ] } ] } Yes?

Syntax in the query language and UI affordance to be determined. Easiest might be to add _transitive: 1 to the options of the query, and a flag in the options dropdown? Otherwise we risk almost doubling the already large number of fields.

Requirements: TBD

Needed for promotion: If an item on the list is not needed, it should be crossed off but not removed.

- [ ] Wireframe/Mockup - Heather - [ ] Committee discussions - Sarah

• [ ] Feasibility/Team discussion - Sarah
• [ ] Backend requirements - TBD
• [ ] Frontend requirements- TBD
• [ ] Questions
• List of questions for discussions. Answers should be documented within the issue.

UAT/LUX Examples:

Dependencies/Blocks:

Related Github Issues:

• https://git.yale.edu/lux-its/lux-web/issues/1171

Related links:

Wireframe/Mockup: Place wireframe/mockup for the proposed solution at end of ticket.

[prowns]

Marking as blocked to note that this ticket may be superseded by research that @brent-hartwig and @azaroth42 are doing on transitive queries for YPM endpoint.