Редактор параллельных разметок (проект) — различия между версиями
Материал из Wiki - Факультет компьютерных наук
Dmitry (обсуждение | вклад) (→Какие начальные требования?) |
|||
| (не показано 7 промежуточных версии 2 участников) | |||
| Строка 2: | Строка 2: | ||
|name=Редактор параллельных разметок | |name=Редактор параллельных разметок | ||
|mentor=Фролов Дмитрий | |mentor=Фролов Дмитрий | ||
| − | |mentor_login=Dmitry | + | |mentor_login={{URLENCODE:Dmitry|WIKI}} |
|semester=Весна 2015 | |semester=Весна 2015 | ||
|course=1 | |course=1 | ||
|summer= | |summer= | ||
|categorize=yes | |categorize=yes | ||
| + | |is_archived=yes | ||
}} | }} | ||
| Строка 18: | Строка 19: | ||
Токен (слово или другая единица языка) с приписанным ему набором тегов ("разбором"), ср. пример из древнерусского:<br /> | Токен (слово или другая единица языка) с приписанным ему набором тегов ("разбором"), ср. пример из древнерусского:<br /> | ||
<ana lex="проблискатисѧ" gr="V,praes,sg,3p" source_el="ἀπαστράπτεται"/>проблискаѥтсѧ<br /> | <ana lex="проблискатисѧ" gr="V,praes,sg,3p" source_el="ἀπαστράπτεται"/>проблискаѥтсѧ<br /> | ||
| − | + | Пример параллельной разметки можно увидеть на картинке справа. | |
| + | |||
[[Файл:IMAG1097.jpg|мини]] | [[Файл:IMAG1097.jpg|мини]] | ||
| Строка 25: | Строка 27: | ||
Система должна предоставлять следующие функции (I): | Система должна предоставлять следующие функции (I): | ||
| − | # создавать "проект" и загружать исходные файлы (от двух до N | + | # создавать "новый проект" и загружать исходные файлы (от двух до N xml-файлов разметки) |
| − | # выравнивать данные из разных файлов по токенам ( | + | # выравнивать данные из разных файлов по токенам (возможны мелкие расхождения) |
| − | # показывать расхождения | + | # показывать расхождения |
| − | # давать возможность пользователю выбрать один ("правильный") | + | # давать возможность пользователю выбрать один вариант ("правильный вариант") |
| − | # автоматически выбирать "правильный", если разметки для токена везде совпадают | + | # автоматически выбирать "правильный вариант", если разметки для токена везде совпадают |
# выделять или (как опция) автоматически выбирать наиболее вероятный разбор по принципу "большинство голосует" (если разметок 3 и больше) | # выделять или (как опция) автоматически выбирать наиболее вероятный разбор по принципу "большинство голосует" (если разметок 3 и больше) | ||
# давать возможность вручную написать новый разбор, если другие не годятся (в поле для редактирования) | # давать возможность вручную написать новый разбор, если другие не годятся (в поле для редактирования) | ||
| Строка 35: | Строка 37: | ||
# сохранять информацию о текущем состоянии в файл "проекта" | # сохранять информацию о текущем состоянии в файл "проекта" | ||
# проверять валидность итогового xml-файла (с учетом п. 7) | # проверять валидность итогового xml-файла (с учетом п. 7) | ||
| − | # сообщать, сколько разборов осталось неразмеченными | + | # сообщать, сколько разборов осталось неразмеченными, и переходить к следующему неразмеченному |
| − | # давать возможность увидеть контекст ( | + | # давать возможность увидеть контекст (несколько токенов слева и справа от текущего), возможно - в виде всплывающего поля по клику (дизайн - на усмотрение разработчиков) |
Дополнительные требования (II): | Дополнительные требования (II): | ||
| Строка 66: | Строка 68: | ||
# Ubuntu Linux/OpenSUSE/FreeBSD, GNU Emacs или Vim - на выбор | # Ubuntu Linux/OpenSUSE/FreeBSD, GNU Emacs или Vim - на выбор | ||
# MongoDB | # MongoDB | ||
| − | # http- | + | # git, github/bitbucket |
| + | # http-сервер Nginx/Apache (возможно - в связке с WSGI-сервером (Gunicorn)) | ||
=== Темы вводных занятий === | === Темы вводных занятий === | ||
| Строка 75: | Строка 78: | ||
=== Направления развития === | === Направления развития === | ||
| − | # | + | # Различные варианты усовершенствование архитектуры серверной части, механизмов и алгоритмов клиент-серверного взаимодействия |
| − | # Развертывание кластера серверов с распределением нагрузки (например, http-сервером) | + | <!--# Развертывание кластера серверов с распределением нагрузки (например, http-сервером) |
| − | # Развертывание кластера БД с шардами и репликацией | + | # Развертывание кластера БД с шардами и репликацией --> |
=== Критерии оценки === | === Критерии оценки === | ||
Текущая версия на 10:50, 20 октября 2015
| Ментор | Фролов Дмитрий |
| Учебный семестр | Весна 2015 |
| Учебный курс | 1-й курс |
| Внимание! Данный проект находится в архиве и реализован не будет. |
Что это за проект?
Мотивировка
Для разметки языковых данных в корпусах, базах данных и т.п. часто пользуются краудсорсингом, привлекая студентов, школьников, энтузиастов, низкооплачиваемых mechanical turks. Являясь непрофессионалами и не имея достаточного опыта, эти разметчики делают много ошибок, поэтому обычно одни и те же данные размечаются двумя-тремя-.. - пятью разметчиками. Нужен интерфейс для супервайзера-профессионала, который на основе этих параллельных разметок создаст правильную итоговую разметку. (Аналогично такую чистовую разметку делают на основе ответов нескольких автоматических разметчиков).
Что такое разметка?
Токен (слово или другая единица языка) с приписанным ему набором тегов ("разбором"), ср. пример из древнерусского:
<ana lex="проблискатисѧ" gr="V,praes,sg,3p" source_el="ἀπαστράπτεται"/>проблискаѥтсѧ
Пример параллельной разметки можно увидеть на картинке справа.
Требования к разрабатываемой системе
Система должна предоставлять следующие функции (I):
- создавать "новый проект" и загружать исходные файлы (от двух до N xml-файлов разметки)
- выравнивать данные из разных файлов по токенам (возможны мелкие расхождения)
- показывать расхождения
- давать возможность пользователю выбрать один вариант ("правильный вариант")
- автоматически выбирать "правильный вариант", если разметки для токена везде совпадают
- выделять или (как опция) автоматически выбирать наиболее вероятный разбор по принципу "большинство голосует" (если разметок 3 и больше)
- давать возможность вручную написать новый разбор, если другие не годятся (в поле для редактирования)
- сохранять итоговую разметку в xml-файл (токены, для которых ответ не выбран, остаются без разметки)
- сохранять информацию о текущем состоянии в файл "проекта"
- проверять валидность итогового xml-файла (с учетом п. 7)
- сообщать, сколько разборов осталось неразмеченными, и переходить к следующему неразмеченному
- давать возможность увидеть контекст (несколько токенов слева и справа от текущего), возможно - в виде всплывающего поля по клику (дизайн - на усмотрение разработчиков)
Дополнительные требования (II):
- отрисовывать блекло повторяющиеся разборы, чтобы они не отвлекали пользователя (совсем скрывать их нежелательно, чтобы пользователь видел, откуда пришел тот или иной разбор)
- показывать каппу inter-annotator agreement
- ранжировать аннотаторов от "хороших" к "плохим" (по степени их согласования с большинством), сначала показывать "хороших", потом "плохих"
- вручную менять порядок показа их разборов
- особым образом помечать сложные случаи, чтобы потом можно было к ним вернуться (+ переходить между ними), иметь возможность писать к ним комментарии
- возможность оставить два и более разбора в итоговой разметке (такая потребность реально бывает)
- убирать и добавлять токены в разметку (связано с тем, что границы между токенами требуется поменять вручную).
Чему вы научитесь?
- Основы проектирования и разработки клиент-серверных приложений
- Базовые знания Unix Shell
- Работа с нереляционными базами данных
Какие начальные требования?
- Представление о технологиях создания веб-страниц
- Основы языка программирования Python
Какие будут использоваться технологии?
- HTML/CSS, JavaScript, JQuery
- Python 2.7
- WebPy/Web2Py/Django
- Ubuntu Linux/OpenSUSE/FreeBSD, GNU Emacs или Vim - на выбор
- MongoDB
- git, github/bitbucket
- http-сервер Nginx/Apache (возможно - в связке с WSGI-сервером (Gunicorn))
Темы вводных занятий
- Архитектура клиент-серверных приложений и основные принципы разработки
- Нереляционные базы данных, преимущества, недостатки, особенности использования
Направления развития
- Различные варианты усовершенствование архитектуры серверной части, механизмов и алгоритмов клиент-серверного взаимодействия
Критерии оценки
- 4-5 - Система представляет собой клиент-серверное приложение, реализующее как минимум половину функции из списка требований (I)
- 6-7 - Система, реализующая все функции из списка требований (I).
- 8-10 - Система, реализующая функции все функции из списка требований (I), и, кроме того, реализованы 1-2 или более функций из списка Дополнительных требований (II). Для получения самого высокого балла (10) разработанная система должна иметь защиту от использования незарегистрированными пользователями, предоставлять возможность регистрации и входа в систему.
