apache / apache/lucene

Decouple Kuromoji's morphological analyser and its dictionary [LUCENE-8816]

Open
#9,860 33 comments 0 reactions 0 assignees View on GitHub
legacy-jira-priority:Major module:analysis type:enhancement
Dominant language
Java
Stars
3.6k
Forks
1.4k
Avg merge
2d 11h
Merged PRs (30d)
88

Description

I've inspired by this mail-list thread.

As many Japanese already know, default built-in dictionary bundled with Kuromoji (MeCab IPADIC) is a bit old and no longer maintained for many years. While it has been slowly obsoleted, well-maintained and/or extended dictionaries risen up in recent years (e.g. [mecab-ipadic-neologd](https://github.com/neologd/mecab-ipadic-neologd), [UniDic](https://unidic.ninjal.ac.jp/)). To use them with Kuromoji, some attempts/projects/efforts are made in Japan.

However current architecture - dictionary bundled jar - is essentially incompatible with the idea "switch the system dictionary", and developers have difficulties to do so.

Traditionally, the morphological analysis engine (viterbi logic) and the encoded dictionary (language model) had been decoupled (like MeCab, the origin of Kuromoji, or lucene-gosen). So actually decoupling them is a natural idea, and I feel that it's good time to re-think the current architecture.

Also this would be good for advanced users who have customized/re-trained their own system dictionary.

Goals of this issue:
- Decouple JapaneseTokenizer itself and encoded system dictionary.
- Implement dynamic dictionary load mechanism.
- Provide developer-oriented dictionary build tool.

Non-goals:

- Provide learner or language model (it's up to users and should be outside the scope).

I have not dove into the code yet, so have no idea about it's easy or difficult at this moment.

---
Migrated from [LUCENE-8816](https://issues.apache.org/jira/browse/LUCENE-8816) by Tomoko Uchida (@mocobeta), 1 vote, updated Jan 27 2022
Linked issues:
- #9861
- #5128
- #9912

Contributor guide

Open the contributing guide

Research direction

Start by reading the JapaneseTokenizer architecture and the linked issues #9861, #5128, and #9912, then review the referenced mailing-list discussion. The work is done when JapaneseTokenizer is decoupled from its encoded system dictionary, dictionaries can be loaded dynamically, and a developer-oriented dictionary build tool exists without adding a learner or language model.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
search, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.