It currently seems to base the priority of category application based on the depth and then position of a category.
|
fn _pick_highest_ranking_category(acc: Vec<String>, item: &[String]) -> Vec<String> { |
|
if item.len() >= acc.len() { |
|
// If tag is category with greater or equal depth than current, then choose the new one instead. |
|
item.to_vec() |
|
} else { |
|
acc |
|
} |
|
} |
This means that in the scenario below, category 2b is picked over rule 1.
- Category 1 (matches)
- Category 2
- Category 2b (matches) ← picked
To avoid this, one needs to change it to:
- Category 1
- Category 1b (matches) ← picked
- Category 2
This is inconvient and requires both exporting, manually editing the category JSON, and reimporting it, in addition to nesting category unnessarily.
I think it would be better to first prioritize the order and only override based on depth when it is a child of the previously picked category (e.g. overriding 2 with 2b).
This could be changed in the code above to only override it if the starting names match.
It currently seems to base the priority of category application based on the depth and then position of a category.
aw-server-rust/aw-transform/src/classify.rs
Lines 116 to 123 in 826efce
This means that in the scenario below, category 2b is picked over rule 1.
To avoid this, one needs to change it to:
This is inconvient and requires both exporting, manually editing the category JSON, and reimporting it, in addition to nesting category unnessarily.
I think it would be better to first prioritize the order and only override based on depth when it is a child of the previously picked category (e.g. overriding 2 with 2b).
This could be changed in the code above to only override it if the starting names match.