Я не буду выигрывать очки здесь, но кое-что.
Многоязычный словарь - это большое и трудоемкое мероприятие.Вы не говорили подробно о точном использовании, для которого предназначен ваш словарь: возможно, статистическом, не переводящем, не грамматическом .... Различное использование требует сбора разных данных, например, классификация «пошло» как прошедшее время.
Сначала сформулируйте свои первые требования в документе и запрограммируйте прототип интерфейса.Задавая структуры данных до алгоритмической концепции, я часто вижу сложную бизнес-логику.Тогда можно было бы начать неправильно, рискуя Feature Creep .Или преждевременная оптимизация, как та латинизация, которая может не иметь никакого преимущества, и двунаправленность бара.
Возможно, вы можете начать с некоторых активных проектов, таких как Reta Vortaro ;его XML может быть неэффективным, но даст вам некоторые идеи для организации.Есть несколько академических лингвистических проектов .Наиболее релевантным аспектом может быть stemming : распознавание greet / grees / greeted / greeter /reeting / greetings (@smci) как принадлежащее к той же (основной) записи.Вы хотите взять уже запрограммированные стеммеры;они часто хорошо проверены и уже применяются в электронных словарях.Я бы посоветовал исследовать эти проекты, не теряя много энергии, импульса для них;просто достаточно, чтобы собрать идеи и посмотреть, где они могут быть использованы.
Структуры данных, которые можно придумать, ИМХО имеют второстепенное значение.Я сначала собрал бы все в четко определенной базе данных , а затем сгенерировал программно используемые структуры данных .Затем вы можете сравнить и измерить альтернативы.И это может быть для разработчика самой интересной частью - создание красивой структуры данных и алгоритма.
Ответ
Требование:
Карта слова в список [язык, определение определения].Список определений.
Несколько слов могут иметь одно и то же определение, поэтому необходима ссылка на определение.Определение может состоять из определения с привязкой к языку (грамматические свойства, склонения) и / или независимого от языка определения (описание понятия).
Одно слово может иметь несколько определений (книга = (существительное) материал для чтения, = (глагол) резервное использование местоположения).
Примечания
Поскольку обрабатываются отдельные слова, это не означает, что встречающийся текст в целом является одноязычным,Поскольку текст может состоять из смешанных языков, и я не вижу особых издержек в О-сложности, что кажется неуместным.
Таким образом, общая абстрактная структура данных будет выглядеть так:
Map<String /*Word*/, List<DefinitionEntry>> wordDefinitions;
Map<String /*Language/Locale/""*/, List<Definition>> definitions;
class Definition {
String content;
}
class DefinitionEntry {
String language;
Ref<Definition> definition;
}
Конкретная структура данных:
WordDefinitions лучше всего использовать с оптимизированной хэш-картой.
Пожалуйста, позвольте мне добавить:
Я наконец-то придумал конкретную структуру данных.Я начал со следующего:
MultiMap от Guava - это то, что мы имеем здесь, но коллекции Trove с примитивными типами - это то, что нужно, если использовать компактное двоичное представление в ядре.
Можно было бы сделать что-то вроде:
import gnu.trove.map.*;
/**
* Map of word to DefinitionEntry.
* Key: word.
* Value: offset in byte array wordDefinitionEntries,
* 0 serves as null, which implies a dummy byte (data version?)
* in the byte arrary at [0].
*/
TObjectIntMap<String> wordDefinitions = TObjectIntHashMap<String>();
byte[] wordDefinitionEntries = new byte[...]; // Actually read from file.
void walkEntries(String word) {
int value = wordDefinitions.get(word);
if (value == 0)
return;
DataInputStream in = new DataInputStream(
new ByteArrayInputStream(wordDefinitionEntries));
in.skipBytes(value);
int entriesCount = in.readShort();
for (int entryno = 0; entryno < entriesCount; ++entryno) {
int language = in.readByte();
walkDefinition(in, language); // Index to readUTF8 or gzipped bytes.
}
}