Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in
haskell-gargantext
haskell-gargantext
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 187
    • Issues 187
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 10
    • Merge Requests 10
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • gargantext
  • haskell-gargantexthaskell-gargantext
  • Merge Requests
  • !439

Merged
Opened Sep 08, 2025 by Alfredo Di Napoli@AlfredoDiNapoli
  • Report abuse
Report abuse

Keep only the roots in searchTableNgrams

Work in progress for #504.

@davidchavalarias I have some questions -- the code for managing ngrams is a bit subtle, but in essence what we do is to build a forest of ngrams trees, where each tree is composed by a root (e.g. soils) and one or more children, that they shows up in the UI bundled together.

I have done some tweaks as part of this MR which, on the surface, makes it look like it's fixing things:

Screenshot_2025-09-08_at_12.28.19

However, I think there are some dark corners that I would like to clarify:

  1. In the issue #504, you were surprised that the number of candidate terms were too small. I have looked at the number this patch generate, and we generate 350 terms if we include all terms, but less than 350 if we consider candidate or map terms, which seems reasonable to me. Does that match your intuition? In other terms, 350 will be a fixed number of all terms, the candidate will be less;

  2. I am not sure if this is a bug in Gargantext or something which wasn't accounted for, but at the moment the UI will (correctly so) not show trees which mixes list types. What do I mean? Consider the following two terms in that "water" example: risks and risk. It turns out that one is a candidate term (i.e. risk) but due to the fact its parent is a map term, then at the moment it won't be included in the final list of terms. What should be the correct behaviour between:

    • a. The parent gets "promoted" to a candidate term, so that we can show both risk and risks bundled together;
    • b. Only risk gets shown as a candidate term alone, i.e. detached from the parent. This means that now also risks will be shown as a standalone item in the Map terms view, which seems incorrect.
Edited Sep 08, 2025 by Alfredo Di Napoli

Check out, review, and merge locally

Step 1. Fetch and check out the branch for this merge request

git fetch origin
git checkout -b adinapoli/issue-504 origin/adinapoli/issue-504

Step 2. Review the changes locally

Step 3. Merge the branch and fix any conflicts that come up

git fetch origin
git checkout origin/dev
git merge --no-ff adinapoli/issue-504

Step 4. Push the result of the merge to GitLab

git push origin dev

Note that pushing to GitLab requires write access to this repository.

Tip: You can also checkout merge requests locally by following these guidelines.

  • Discussion 2
  • Commits 4
  • Pipelines 4
  • Changes 5
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
1
Labels
Ready to merge
Assign labels
  • View project labels
Reference: gargantext/haskell-gargantext!439

Revert this merge request

This will create a new commit in order to revert the existing changes.

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.

Cherry-pick this merge request

Switch branch
Cancel
A new branch will be created in your fork and a new merge request will be started.