There are times that you need to amend or completely replace the lexical dictionaries derived from Wikidata. Nebojša created a document called Evaluation of Lexicon Format Alternatives that covers investigating this topic. This feature enhancement will cover the discussion and progress on such an effort.
The current top contender is DMLex.
The second option is OntoLex-Lemon, but that seems more geared towards ontologies and knowledge graphs. That's probably more like entirety of Wikidata, instead of the lexeme part of Wikidata.
The other options listed in the document struggle with containing sufficient structure to disambiguate words that differ in the meaning. The current file format read by buildDictionary is best at compressing a post validated lexical structure. It's not a good format for humans to edit.
The new file format to support should have the following characteristics:
- Have an acceptable license that is compatible with the Unicode license.
- Reference a main label. This is typically a lemma.
- Represent a part of speech.
- Label multiple surface forms under the lemma with grammemes that allow each state to be uniquely identified (when possible).
- Allow phonetic information to be available so that articles or particles can be properly added.
- Be computer parseable and validated. The group is leaning towards JSON because Wikidata already uses a JSON parser. XML is acceptable if necessary. DMLex supports both.
- Ideally have other repositories of lexical data to choose from that are compatible with the Unicode license.
- Ideally is an open standard, but a custom format is possible.
In order to use such data, it's likely that the existing dictionary-parser will be modified to support the additional format. This additional file format can be used to amend, preempt, or replace the data from Wikidata as necessary. The proposal is not to remove support for the existing lst/xml file formats. The proposal is to convert this new custom lexical dictionary support into the existing file formats that buildDictionary can parse. This is already mildly done with the supplemental data for specific languages. The data structures will likely have to be shared between the 2 parsers in the dictionary-parser tool.
There are times that you need to amend or completely replace the lexical dictionaries derived from Wikidata. Nebojša created a document called Evaluation of Lexicon Format Alternatives that covers investigating this topic. This feature enhancement will cover the discussion and progress on such an effort.
The current top contender is DMLex.
The second option is OntoLex-Lemon, but that seems more geared towards ontologies and knowledge graphs. That's probably more like entirety of Wikidata, instead of the lexeme part of Wikidata.
The other options listed in the document struggle with containing sufficient structure to disambiguate words that differ in the meaning. The current file format read by buildDictionary is best at compressing a post validated lexical structure. It's not a good format for humans to edit.
The new file format to support should have the following characteristics:
In order to use such data, it's likely that the existing dictionary-parser will be modified to support the additional format. This additional file format can be used to amend, preempt, or replace the data from Wikidata as necessary. The proposal is not to remove support for the existing lst/xml file formats. The proposal is to convert this new custom lexical dictionary support into the existing file formats that buildDictionary can parse. This is already mildly done with the supplemental data for specific languages. The data structures will likely have to be shared between the 2 parsers in the dictionary-parser tool.