Remove Dependence on Data Constants

[clarkepeterf]

Problem Description: Stop ML from being dependent on data constants

Expected Behavior/Solution: ML no longer needs to generate data constants to function properly

Requirements: Change the following:

• [x] Change Via Search Facets to use AATs
• [x] Change Similar queries to use AATs
• [ ] Change model / profileDocLib to use AATs
  • partially complete, issue with language identifiers
• [x] Remove facet request thresholds (mentioned in xhttps://github.com/project-lux/lux-marklogic/issues/179)

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

- [ ] Wireframe/Mockup - Mike - [ ] Committee discussions - Sarah - [ ] Feasibility/Team discussion - Sarah - [ ] Backend requirements - TBD - [ ] Frontend requirements- TBD - [ ] Are new regression tests required for QA - Amy - [ ] Questions - List of questions for discussions. Answers should be documented within the issue.

UAT/LUX Examples:

• TBD

Dependencies/Blocks: N/A

Related Github Issues: N/A

Related links:

• N/A

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

[roamye]

@clarkepeterf - before moving this to backlog please move it to prioritization review first so it can follow the UAT process. Moving this to prioritization review so it can be reviewed tomorrow.

[clarkepeterf]

@brent-hartwig @azaroth42 Do we need to generate a dynamic list of language identifiers based on the data, or can we have a pre-selected list of supported languages?

Note:

• Currently there are 768 language data constants in DEV.
• Currently the frontend never passes a lang argument when requesting a document, so it always defaults to en

[brent-hartwig]

@clarkepeterf, thinking ahead to when consumers start specifying a language, we could make an adjustment now: fallback on the likes of English when the data pipeline did not provide a constant for the requested language. We have such fallback logic in getIdentifiedByPrimaryName but not getLanguageIRI. The latter will presently throw an exception if we do not have the associated constant. We also have hasLangaugeIRI which will not throw an exception; yet, not all calls to getLanguageIRI check first --and might as well implement in the getter. Adding the fallback logic would align with gracefully continuing when we can: the show must go on!