Редактор параллельных разметок (проект) — различия между версиями
Материал из Wiki - Факультет компьютерных наук
Dmitry (обсуждение | вклад) |
Dmitry (обсуждение | вклад) |
||
| Строка 11: | Строка 11: | ||
=== Что это за проект? === | === Что это за проект? === | ||
====Мотивировка==== | ====Мотивировка==== | ||
| + | |||
Для разметки языковых данных в корпусах, базах данных и т.п. часто пользуются краудсорсингом, привлекая студентов, школьников, энтузиастов, низкооплачиваемых mechanical turks. Являясь непрофессионалами и не имея достаточного опыта, эти разметчики делают много ошибок, поэтому обычно одни и те же данные размечаются двумя-тремя-.. - пятью разметчиками. Нужен интерфейс для супервайзера-профессионала, который на основе этих параллельных разметок создаст правильную итоговую разметку. (Аналогично такую чистовую разметку делают на основе ответов нескольких автоматических разметчиков). | Для разметки языковых данных в корпусах, базах данных и т.п. часто пользуются краудсорсингом, привлекая студентов, школьников, энтузиастов, низкооплачиваемых mechanical turks. Являясь непрофессионалами и не имея достаточного опыта, эти разметчики делают много ошибок, поэтому обычно одни и те же данные размечаются двумя-тремя-.. - пятью разметчиками. Нужен интерфейс для супервайзера-профессионала, который на основе этих параллельных разметок создаст правильную итоговую разметку. (Аналогично такую чистовую разметку делают на основе ответов нескольких автоматических разметчиков). | ||
====Что такое разметка?==== | ====Что такое разметка?==== | ||
| + | |||
Токен (слово или другая единица языка) с приписанным ему набором тегов ("разбором"), ср. пример из древнерусского:<br /> | Токен (слово или другая единица языка) с приписанным ему набором тегов ("разбором"), ср. пример из древнерусского:<br /> | ||
<ana lex="проблискатисѧ" gr="V,praes,sg,3p" source_el="ἀπαστράπτεται"/>проблискаѥтсѧ<br /> | <ana lex="проблискатисѧ" gr="V,praes,sg,3p" source_el="ἀπαστράπτεται"/>проблискаѥтсѧ<br /> | ||
| Строка 19: | Строка 21: | ||
[[Файл:IMAG1097.jpg|мини]] | [[Файл:IMAG1097.jpg|мини]] | ||
| − | ==== | + | ====Требования к разрабатываемой системе==== |
| − | + | ||
| − | + | Система должна предоставлять следующие функции (I): | |
| − | + | # создавать "проект" и загружать исходные файлы (от двух до N файлов с xml-разметкой в юникоде) | |
| + | # выравнивать данные из разных файлов по токенам (NB возможны мелкие расхождения) | ||
| + | # показывать расхождения (подсветкой?) | ||
| + | # давать возможность пользователю выбрать один ("правильный"), кликнув на нем | ||
| + | # автоматически выбирать "правильный", если разметки для токена везде совпадают | ||
| + | # выделять или (как опция) автоматически выбирать наиболее вероятный разбор по принципу "большинство голосует" (если разметок 3 и больше) | ||
| + | # давать возможность вручную написать новый разбор, если другие не годятся (в поле для редактирования) | ||
| + | # сохранять итоговую разметку в xml-файл (токены, для которых ответ не выбран, остаются без разметки) | ||
| + | # сохранять информацию о текущем состоянии в файл "проекта" | ||
| + | # проверять валидность итогового xml-файла (с учетом п. 7) | ||
| + | # сообщать, сколько разборов осталось неразмеченными (в status bar?), и переходить к следующему неразмеченному | ||
| + | # давать возможность увидеть контекст (10 токенов слева и справа от текущего как сниппет) (NB всплывающее поле? в строке статуса по клику? отрисовывать его при каждом токене не хочется) | ||
| − | + | Дополнительные требования (II): | |
| − | + | # отрисовывать блекло повторяющиеся разборы, чтобы они не отвлекали пользователя (совсем скрывать их нежелательно, чтобы пользователь видел, откуда пришел тот или иной разбор) | |
| + | # показывать [http://en.wikipedia.org/wiki/Cohen%27s_kappa каппу] inter-annotator agreement | ||
| + | # ранжировать аннотаторов от "хороших" к "плохим" (по степени их согласования с большинством), сначала показывать "хороших", потом "плохих" | ||
| + | # вручную менять порядок показа их разборов | ||
| + | # особым образом помечать сложные случаи, чтобы потом можно было к ним вернуться (+ переходить между ними), иметь возможность писать к ним комментарии | ||
| + | # возможность оставить два и более разбора в итоговой разметке (такая потребность реально бывает) | ||
| + | # убирать и добавлять токены в разметку (связано с тем, что границы между токенами требуется поменять вручную). | ||
| − | + | === Чему вы научитесь? === | |
| − | + | # Основы проектирования и разработки клиент-серверных приложений | |
| + | # Базовые знания Unix Shell | ||
| + | # Работа с нереляционными базами данных | ||
| − | + | === Какие начальные требования? === | |
| − | + | # Основы HTML/CSS/JavaScript | |
| + | # Основы языка программирования Python | ||
| + | # Представления о системах управления версиями | ||
| + | # Базовые представления о базах данных | ||
| − | + | === Какие будут использоваться технологии? === | |
| − | + | * HTML/CSS, JavaScript, JQuery | |
| + | * Python 2.7 | ||
| + | * WebPy/Web2Py/Django | ||
| + | * Ubuntu Linux/OpenSUSE/FreeBSD, GNU Emacs или Vim - на выбор | ||
| + | * MongoDB | ||
| + | * http-сервера Nginx, Gunicorn | ||
| − | + | === Темы вводных занятий === | |
| − | + | # Архитектура клиент-серверных приложений и основные принципы разработки | |
| − | + | # Нереляционные базы данных, преимущества, недостатки, особенности использования | |
| − | + | === Направления развития === | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | # Усовершенствование архитектуры серверной части, развертывание кластера серверов с распределением нагрузки http-сервером, развертывание кластера БД с шардами и репликацией | |
| − | + | ||
| − | === | + | === Критерии оценки === |
| − | + | ||
| − | + | # 4-5 - Клиент-серверное приложение, реализующее все функции из списка требований (I) | |
| − | --- | + | |
| − | + | # 6-7 - Система, реализующая функции, перечисленные в Пункте (1), и, кроме того, имеющая защиту от использования незарегистрированными пользователями, предоставляющая возможность регистрации и входа в систему. Реализованы несколько функций из списка Дополнительных требований (II). | |
| − | + | ||
| − | + | # 8-10 Система, реализующая функции, перечисленные в Пункте (2), и, кроме того, реализованы все функции из списка Дополнительных требований (II). Разработанная система полностью соответствует требованиям к архитектуре. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Версия 20:03, 1 декабря 2014
| Ментор | Фролов Дмитрий |
| Учебный семестр | Весна 2015 |
| Учебный курс | 1-й курс |
Что это за проект?
Мотивировка
Для разметки языковых данных в корпусах, базах данных и т.п. часто пользуются краудсорсингом, привлекая студентов, школьников, энтузиастов, низкооплачиваемых mechanical turks. Являясь непрофессионалами и не имея достаточного опыта, эти разметчики делают много ошибок, поэтому обычно одни и те же данные размечаются двумя-тремя-.. - пятью разметчиками. Нужен интерфейс для супервайзера-профессионала, который на основе этих параллельных разметок создаст правильную итоговую разметку. (Аналогично такую чистовую разметку делают на основе ответов нескольких автоматических разметчиков).
Что такое разметка?
Токен (слово или другая единица языка) с приписанным ему набором тегов ("разбором"), ср. пример из древнерусского:
<ana lex="проблискатисѧ" gr="V,praes,sg,3p" source_el="ἀπαστράπτεται"/>проблискаѥтсѧ
Параллельную разметку можно представить примерно так:
Требования к разрабатываемой системе
Система должна предоставлять следующие функции (I):
- создавать "проект" и загружать исходные файлы (от двух до N файлов с xml-разметкой в юникоде)
- выравнивать данные из разных файлов по токенам (NB возможны мелкие расхождения)
- показывать расхождения (подсветкой?)
- давать возможность пользователю выбрать один ("правильный"), кликнув на нем
- автоматически выбирать "правильный", если разметки для токена везде совпадают
- выделять или (как опция) автоматически выбирать наиболее вероятный разбор по принципу "большинство голосует" (если разметок 3 и больше)
- давать возможность вручную написать новый разбор, если другие не годятся (в поле для редактирования)
- сохранять итоговую разметку в xml-файл (токены, для которых ответ не выбран, остаются без разметки)
- сохранять информацию о текущем состоянии в файл "проекта"
- проверять валидность итогового xml-файла (с учетом п. 7)
- сообщать, сколько разборов осталось неразмеченными (в status bar?), и переходить к следующему неразмеченному
- давать возможность увидеть контекст (10 токенов слева и справа от текущего как сниппет) (NB всплывающее поле? в строке статуса по клику? отрисовывать его при каждом токене не хочется)
Дополнительные требования (II):
- отрисовывать блекло повторяющиеся разборы, чтобы они не отвлекали пользователя (совсем скрывать их нежелательно, чтобы пользователь видел, откуда пришел тот или иной разбор)
- показывать каппу inter-annotator agreement
- ранжировать аннотаторов от "хороших" к "плохим" (по степени их согласования с большинством), сначала показывать "хороших", потом "плохих"
- вручную менять порядок показа их разборов
- особым образом помечать сложные случаи, чтобы потом можно было к ним вернуться (+ переходить между ними), иметь возможность писать к ним комментарии
- возможность оставить два и более разбора в итоговой разметке (такая потребность реально бывает)
- убирать и добавлять токены в разметку (связано с тем, что границы между токенами требуется поменять вручную).
Чему вы научитесь?
- Основы проектирования и разработки клиент-серверных приложений
- Базовые знания Unix Shell
- Работа с нереляционными базами данных
Какие начальные требования?
- Основы HTML/CSS/JavaScript
- Основы языка программирования Python
- Представления о системах управления версиями
- Базовые представления о базах данных
Какие будут использоваться технологии?
- HTML/CSS, JavaScript, JQuery
- Python 2.7
- WebPy/Web2Py/Django
- Ubuntu Linux/OpenSUSE/FreeBSD, GNU Emacs или Vim - на выбор
- MongoDB
- http-сервера Nginx, Gunicorn
Темы вводных занятий
- Архитектура клиент-серверных приложений и основные принципы разработки
- Нереляционные базы данных, преимущества, недостатки, особенности использования
Направления развития
- Усовершенствование архитектуры серверной части, развертывание кластера серверов с распределением нагрузки http-сервером, развертывание кластера БД с шардами и репликацией
Критерии оценки
- 4-5 - Клиент-серверное приложение, реализующее все функции из списка требований (I)
- 6-7 - Система, реализующая функции, перечисленные в Пункте (1), и, кроме того, имеющая защиту от использования незарегистрированными пользователями, предоставляющая возможность регистрации и входа в систему. Реализованы несколько функций из списка Дополнительных требований (II).
- 8-10 Система, реализующая функции, перечисленные в Пункте (2), и, кроме того, реализованы все функции из списка Дополнительных требований (II). Разработанная система полностью соответствует требованиям к архитектуре.
