ТОМ2 - платформа для парсерных игр

Объявление

Платформа ТОМ предназначена для создания текстовых игр на русском языке и имеет развитый парсер, позволяющий взаимодействовать с играми с помощью команд на близком к естественному языке. В данный момент активно разрабатывается версия ТОМ 2.
Последнюю версию платформы можно скачать здесь.

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » ТОМ2 - платформа для парсерных игр » Словарь и стандартная библиотека » Редактирование словаря TomDic


Редактирование словаря TomDic

Сообщений 1 страница 21 из 21

1

Думал, что в словаре должны содержаться только слова, но судя по тому, что есть в TomDic, оказалось я глубоко ошибался.

Оказывается туда записывается и информация о значениях слов. А так-же строится дерево... классов что-ли. В нём различные значения слов наследуются друг от друга и составляются в дерево.

http://savepic.ru/3749137.png
Ты сам составлял это дерево или откуда-то брал?

Кстати, есть два типа "семантической" зависимости:
Первая - это которая у тебя в словаре (стул - это мебель, мебель - это материальный предмет).
Вторая - обозначает часть чего-либо (косточка - часть вишенки, колесо - часть машины, рука - часть человека).

(может я путаю какие-то понятия, давно это было...)

Пару лет назад я где-то на просторах интернета находил любопытную базу слов, где все они были сформированы как-раз в виде такого дерева. При чём все слова (значения) были связаны в дерево с этими двумя типами зависимостей.
Так я её ни куда и не применил, то ли у меня мастерства не хватило разобраться в ней до конца, то ли желания не было. Но помню что слов там было очень много: от обычной классификации всяких деревьев и их плодов до всяких разновидностей моллюсков и живностей. Дело усложняло ещё и эта двойная классификация, из-за которой дерево всячески переплеталось и "кольцевалось" как непонятный граф.

Могу даже поискать на жёстком диске эту базу, вот только думаю, что чистить её от "мусора" окажется дольше чем сделать свою узкоспециализированную.

2

Да это именно дерево классов, которые являются значениями слов. Еще там должны быть синонимы, но пока их нет.
Дерево составлял сам с учетом применимости к текстовым играм. Работа по составлению дерева в самом начале, то что там есть мне было нужно для отладки парсера.
Значения слов описываются языком ТОМа и в совокупности должны формировать стандартную библиотеку.
Сторонние базы вряд ли подойдут... работа по их подгонке будет сопоставима с составлением с нуля.

3

Как в словарной базе открыть файл словаря?

4

russian bear написал(а):

Как в словарной базе открыть файл словаря?

Для работы со словарной базой нужен mySQL.
Файл словаря - это компиляция SQL-базы, просмотреть в нём можно только отдельные слова с помощью специального просмотрщика.

5

ASBer написал(а):

Для работы со словарной базой нужен mySQL.
Файл словаря - это компиляция SQL-базы, просмотреть в нём можно только отдельные слова с помощью специального просмотрщика.

Не. Я имел в виду Словарную базу ТОМ на MySQL, как показано выше на скриншоте. Базу я скачал, но как ее наполнить?

6

Здесь описан процесс установки mySQL и там же ниже описано копирования базы tomdic. Если всё сделано правильно, при запуске tombase.exe база открывается автоматически.

Наиболее свежая база лежит тут: http://files.mail.ru/1274681914AF475EA794A664D38A5B38
Выложена исключительно для ознакомления.

7

Ссылка убилась. Можно свежую базу?

8

http://files.mail.ru/6C84789058D5466494C036CB9F7C2839
обновил

9

Так как никакого внятного описания структуры базы данных нет и вряд ли будет (всё-таки она меняется чуть ли не в каждой версии), попробуем немного сами поковырять её внутренности.
(Готовьтесь, будет критика)
При открытии БД видим несколько таблиц:

basis
beginning
end
entries
form
meaning
wlist
word

В таблице basis хранятся основы, в beginning - начала (не приставки), а в end - окончания слов. Зачем всё это хранится в БД не понятно, ведь по логике вещей эти вспомогательные для поиска элементы должны генерироваться при создании словаря TOM.dic, хранить их постоянно в БД нет смысла.
Далее идет таблица entries. И что же внутри? Ни за что не догадаетесь: там практически в готовом виде находится содержимое файла TOM.dic. Зачем, если всё это опять же должно генерироваться (и наверняка делает это) непосредственно перед созданием файла TOM.dic?
Далее (но не по порядку) мы заглянем в таблицу wlist. Вы действительно хотите знать, что там находится? Именно: там опять содержимое TOM.dic, при чём в не самом самом не оптимальном виде. Я даже скрин сейчас покажу:
http://s4.uploads.ru/CR3FK.png

Это таблица списков. Списки повторяются два раза: один раз текстом через точку с запятой, второй раз в полях. При этом полей 30. Тридцать полей. Во-первых, огромные расходы памяти. Во-вторых, что если значений будет 31? В-третьих, эта таблица должна генерироваться непосредственно перед созданием файла TOM.dic.

Ладно, самое страшное прошли. Давайте взглянем на нужные, но не менее избыточные, оставшиеся три таблицы.

Начнём с таблицы word. Тут хранятся слова. Эх, как я был бы рад, если бы это было действительно так. Но увы, кроме слов тут ещё и предлоги. Но предлоги это тоже слова, скажете вы. В концепции ТОМа - нет. Они имеют разную структуру. Так зачем же они в одной таблице - известно только автору. Могу лишь предположить, что словарь задумывался как набор словарных статей, и каждая статья может содержать не только описание слова, но и других объектов. Тогда почему в этой таблице только слова и предлоги, а классы и атрибуты - в другой?
Прокомментируем поля этой таблицы:
name - имя слова/предлога
main_form - основная форма? Зачем? Разве она у слова не вычисляется на основе ключа по умолчанию? А у предлога её в принципе не должно быть
fkey - ключ слова. Определён в БД как строка максимальной длиной 12 символов. А что, если ключ будет больше 6 кодов?
defkey - ключ по умолчанию (привет, основная форма). Тоже 12 символов. Ну тут-то точно встретится больше 6 кодов.
status - число, показывающее готовность описания слова. Если 100, то это слово попадает в файл TOM.dic
type - тип слова (verb, misc, pron, prep ...). Просто рудимент от базы данных, из которой брались слова. Не должен использоваться программой (я очень надеюсь на это).
frequency - частота "встречаемости" слова. Тоже рудимент.
code - код слова/предлога. Для слов содержит чистый код слова: имя, ключ, ключ по умолчанию, все формы слова... Всё то, что уже описано в других полях таблиц. То-есть опять-же избыточная информация. Для предлогов тут тоже описан чистый код, но без окончания. Уже не избыточен, т.к. элементы предлога не хранятся в других таблицах.
Cluster - без понятия что это, но похоже на что-то очень важное. Только не пойму на что.
obj_code - объектный код. Это код, который нельзя поместить в списки слова/предлога, но нужно засунуть в тело слова/предлога. Не избыточное поле.
glb_code - код, который, по видимому, как-бы добавляется в основной модуль программы при доступе к этому слову/предлогу. Встречается редко, но метко (убивает логический анализатор мозга практически сразу).

Дальше мы обязаны посмотреть таблицу form, т.к. она содержит формы слова. Да! Именно так и делается в БД, когда хотят сделать динамический список (а не описывают 30 статических полей).
Тут почти нет нареканий и непоняток. Почти. Но не будем останавливаться.

Последняя таблица - meaning. Это что-то мыслимое, значимое. Тут хранятся классы и атрибуты. Всё красиво, понятно и со смыслом. Исключение пожалуй - поля class_id, class2_id и class3_id. Опять-же, а что если кросс-класс состоит из 4-х классов?

Вот и подошло к концу моё критическое повествование. Прошу прощения, наболело.
Наверняка всё не так страшно, как я описал, и у всего есть какой-то смысл или логическое объяснение. Я бы и слова не сказал, если бы мне не пришлось разрабатывать что-то под этот формат. И ещё, я не настаиваю на полном изменении структуры БД, я лишь хочу разобраться как это работает, чтобы иметь возможность загружать и работать со стандартной библиотекой в своей среде разработки.

10

basis, beginning, end, entries, wlist - действительно надо убивать сразу после использования. Не убивал только потому что нужно было там копаться для отладки генерации. Ну просто представь что этих таблиц нет ))))

word.type - очень полезное поле =) ТОМ его не использует, зато использую я при обработке слов, отборе и т.д.

В остальном действительно, многое эволюционно так сложилось - можно переписать логичнее и правильнее, но ведь и так работает?  =)

11

Интересно, однако. Но еще вопрос, редактор еще не пропало желание сделать?

12

russian bear написал(а):

редактор еще не пропало желание сделать?

Вы ведь понимаете, что при создании редактора нужно в первую очередь как-то загрузить стандартную библиотеку и представить её в удобном виде пользователю. Дней пять подряд пытался как-то извлечь информацию из неё. Сначала из TOM.dic, потом из БД. Безуспешно. Найти какую-то логическую связь между элементами станд. библ. не удаётся. Желание стремительно тает.

Даже сейчас я хотел вытащить автора на некоторые объяснения, но услышал только то, что мои догадки частично верны. Давайте поиграем в горячо-холодно? Не серьёзно ведь.

ASBer написал(а):

В остальном действительно, многое эволюционно так сложилось - можно переписать логичнее и правильнее, но ведь и так работает?  =)

Абсолютно согласен: если работает и устраивает производительность, то пусть работает. Но это лишь до тех пор, пока ты работаешь над этим один. Когда людей больше одного, то появляются вопросы. Приходится либо хорошо объяснять, либо сразу писать понятно на столько, чтобы не пришлось объяснять.

Ладно, сделаю ещё одну попытку узнать немного информации.
* word.main_form как-то участвует при работе?
* Как в таблице word отличить слова от предлогов? По type этого делать нельзя. Значит только по первому слову в поле code?
* Что такое word.Cluster?
* Поле word.code используется только для создания TOM.dic? Тогда слово от предлога отличать по нему нельзя?
* word.obj_code хранит код в теле предлога/слова. У слов я такого не заметил, значит код может быть только в предлогах?
* word.glb_code - куда девать это содержимое? Вот я по прежнему хочу представить стандартную библиотеку в виде дерева. Кросс-классы добавлять под всеми его родителями, просто помечать немного другим значком. В конце концов их не должно быть слишком много, сейчас я нашёл только один кросс-класс: бензин (жидкость и топливо). Так вот если я представлю библиотеку в виде дерева, то куда мне девать содержимое glb_code? К чему привязывать?

* В таблице meaning оказывается хранятся не только классы и атрибуты, но и переменные. Будут ещё сюрпризы?
* Каждый класс привязан к слову. Значит в дереве можно показывать не слова, а только классы. К каждому классу будет привязано слово, верно? Атрибуты представить как-нить в другом виде. Хотя нет, вот вижу некоторые атрибуты могут наследоваться от классов, значит придётся их в это-же дерево запихивать. С переменными, висящими "в воздухе", вообще не понятно что делать.
* meaning.description не используется, как я понял? Не нашёл ни одной записи со значением в этом поле.

В общем, я лишь хочу придумать как в удобном виде представить стандартную библиотеку пользователю в среде разработки. Кто-нить может мне помочь?

13

Да, уж. Будем посмотреть на дальнейшее развитие ситуации. Высказываться пока не буду. Воздержусь.

14

russian bear написал(а):

Высказываться пока не буду. Воздержусь.

А что воздерживаться? Предлагай варианты. Ты ведь недавно писал:

russian bear написал(а):

Давай работать вместе над редактором ТОМ2. Как программист я отстал от жизни, но нюх сохранил.

15

Alexandr написал(а):

Ладно, сделаю ещё одну попытку узнать немного информации.

* word.main_form как-то участвует при работе?
- Нужно только для загрузки словоформ из внешних словарей. Игнорируй.

* Как в таблице word отличить слова от предлогов? По type этого делать нельзя. Значит только по первому слову в поле code?
- если word.type = 'prep' - это предлог, иначе слово (да, word.type всё-же используется...).

* Что такое word.Cluster?
- есть допустим слово "шлем", пример: "шлем вам письмо" =)
Тут совпадают формы слов "шлем" и "слать", поэтому мы их объединяем в один кластер. Словарная статья соответствует кластеру и может содержать описание нескольких слов. Все они будут загружены одновременно. Кстати, к словам "шлем" и "слать" нужно еще добавить слово "идти", думаю понятно почему =)

* Поле word.code используется только для создания TOM.dic? Тогда слово от предлога отличать по нему нельзя?
- лучше смотри на word.type.
word.code - это полуфабрикаты для словарных статей.

* word.obj_code хранит код в теле предлога/слова. У слов я такого не заметил, значит код может быть только в предлогах?
- может быть и в словах, просто пока не возникло такой необходимости.

* word.glb_code - куда девать это содержимое? Вот я по прежнему хочу представить стандартную библиотеку в виде дерева. Кросс-классы добавлять под всеми его родителями, просто помечать немного другим значком. В конце концов их не должно быть слишком много, сейчас я нашёл только один кросс-класс: бензин (жидкость и топливо). Так вот если я представлю библиотеку в виде дерева, то куда мне девать содержимое glb_code? К чему привязывать?
- word.glb_code добавляется в самый конец словарной статьи.
На дереве его показывать не надо. Т.к. этот код относится к слову лучше сделать для него поле на форме слова.

* В таблице meaning оказывается хранятся не только классы и атрибуты, но и переменные. Будут ещё сюрпризы?
- meaning - это таблица значений слов. Переменная вполне подходит на роль значения слова. А еще там есть синонимы команд. И в дальнейшем типы значений будут еще расширяться.

* Каждый класс привязан к слову. Значит в дереве можно показывать не слова, а только классы. К каждому классу будет привязано слово, верно? Атрибуты представить как-нить в другом виде. Хотя нет, вот вижу некоторые атрибуты могут наследоваться от классов, значит придётся их в это-же дерево запихивать. С переменными, висящими "в воздухе", вообще не понятно что делать.
- Структура библиотеки - это сеть. Представить сеть в виде дерева - та еще задача...
Как это лучше сделать в редакторе не возьмусь советовать.
У меня это алфавитный список слов с поиском по слову (закладка словарь) + дерево значений слов (закладка значения). Практика показала что навигация по этим двум спискам вполне удобна.
И чтобы тебя уж совсем добить - скажу что сами слова как объекты тоже могут принадлежать классам "существительное", "глагол", "прилагательное" и т.п.
Сейчас класс указан только для одного местоимения - "ты", но скорее всего это нужно будет распространить на все слова.

* meaning.description не используется, как я понял? Не нашёл ни одной записи со значением в этом поле.
- используется в описании действий, см. значения с типами action и act_sin.

16

Alexandr написал(а):

А что воздерживаться? Предлагай варианты. Ты ведь недавно писал:

А пока для меня это темный лес. Я улавливаю только лишь общий смысл вопросов и ответов, поэтому и воздерживаюсь от комментариев. Не хочу говорить глупости. А вот когда вопросы выйдут за пределы кодирования, тогда пожалуйста. Я немножко знаю редактор Адрифта, и всё. Знаю, что редактор такого типа позволяет создавать парсерные приключения пользователям, не имеющим представления о языках программирования. Кроме того, я немножко не согласен с уклоном ТОМа в стороны семантики. Считаю, что для квестов это пока лишним. Возможно когда-то на новом витке развития, когда уже не чем заняться, и нужно уже добавить в парсер элементы искусственного интеллекта, то может быть. Это очень серьезный и трудоемкий вопрос, требующий отдельных разработок в будущем. А в настоящем нужна парсерная платформа с оконным редактором, переводящим человеческий язык в код ТОМа.
А сейчас я готов всегда помочь с рутинными работами.

17

В версии 2.a.4.1 поменялась структура словарной статьи. Проверка принадлежности к статье осуществляется по полной словоформе, а не по середине слова, как это было ранее.

В плюсе:
- более правильное определение статьи, исключение ложных загрузок;
- сокращение объёма словаря на 140кб;
- открывается возможность для дальнейшей разработки (планируется заменить матрицу хеш-таблицей).

18

Глядя на Александра, тоже решил сделать редизайн словаря.
Теперь это выглядит так:
http://sd.uploads.ru/rMHDh.png
Слева список слов со значениями и синонимами, справа дерево значений.

19

Плотненько так засел за описание действий. Пока что нахожусь на этапе добавления синонимов к глаголам. Новых глаголов в базу добавлено много, но самих действий увеличилось совсем чуть-чуть. Ввод проходит гладко, структура словаря адекватна выполняемой задаче, что очень радует =)

20

Бета-тест покажет, на сколько гладко там всё с синонимами. Обычно так и получается, что когда сам делаешь, кажется что всё однозначно и правильно сходится, а потом удивляешься, как же пользователи додумываются до такого. :)

21

Alexandr написал(а):

а потом удивляешься, как же пользователи додумываются до такого.

Это да, мысль ходит по проторенной дорожке и у разных людей эти дорожки сильно различны  %-)
Без стороннего тестирования не обойтись никак  :flag:


Вы здесь » ТОМ2 - платформа для парсерных игр » Словарь и стандартная библиотека » Редактирование словаря TomDic