Редактор параллельных разметок (проект) — различия между версиями

Материал из Wiki - Факультет компьютерных наук
Перейти к: навигация, поиск
 
(не показано 16 промежуточных версии 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
 
}}
 
}}
  
 
=== Что это за проект? ===
 
=== Что это за проект? ===
 
====Мотивировка====
 
====Мотивировка====
 +
 
Для разметки языковых данных в корпусах, базах данных и т.п. часто пользуются краудсорсингом, привлекая студентов, школьников, энтузиастов, низкооплачиваемых 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 />
Параллельную разметку можно представить примерно так:<br />
+
Пример параллельной разметки можно увидеть на картинке справа.
[[Файл:IMAG1092.jpg|мини]]
+
  
====Интерфейс должен уметь:====
+
[[Файл:IMAG1097.jpg|мини]]
1) создавать "проект" и загружать исходные файлы (от двух до N файлов с xml-разметкой в юникоде)<br />
+
  
2) выравнивать данные из разных файлов по токенам (NB возможны мелкие расхождения)<br />
+
====Требования к разрабатываемой системе====
  
3) показывать расхождения (подсветкой?)<br />
+
Система должна предоставлять следующие функции (I):
  
4) давать возможность пользователю выбрать один ("правильный"), кликнув на нем<br />
+
# создавать "новый проект" и загружать исходные файлы (от двух до N xml-файлов разметки)
 +
# выравнивать данные из разных файлов по токенам (возможны мелкие расхождения)
 +
# показывать расхождения
 +
# давать возможность пользователю выбрать один вариант ("правильный вариант")
 +
# автоматически выбирать "правильный вариант", если разметки для токена везде совпадают
 +
# выделять или (как опция) автоматически выбирать наиболее вероятный разбор по принципу "большинство голосует" (если разметок 3 и больше)
 +
# давать возможность вручную написать новый разбор, если другие не годятся (в поле для редактирования)
 +
# сохранять итоговую разметку в xml-файл (токены, для которых ответ не выбран, остаются без разметки)
 +
# сохранять информацию о текущем состоянии в файл "проекта"
 +
# проверять валидность итогового xml-файла (с учетом п. 7)
 +
# сообщать, сколько разборов осталось неразмеченными, и переходить к следующему неразмеченному
 +
# давать возможность увидеть контекст (несколько токенов слева и справа от текущего), возможно - в виде всплывающего поля по клику (дизайн - на усмотрение разработчиков)
  
5) автоматически выбирать "правильный", если разметки для токена везде совпадают<br />
+
Дополнительные требования (II):
  
6) выделять или (как опция) автоматически выбирать наиболее вероятный разбор по принципу "большинство голосует" (если разметок 3 и больше)<br />
+
# отрисовывать блекло повторяющиеся разборы, чтобы они не отвлекали пользователя (совсем скрывать их нежелательно, чтобы пользователь видел, откуда пришел тот или иной разбор)
 
+
# показывать [http://en.wikipedia.org/wiki/Cohen%27s_kappa каппу] inter-annotator agreement  
7) давать возможность вручную написать новый разбор, если другие не годятся (в поле для редактирования)<br />
+
# ранжировать аннотаторов от "хороших" к "плохим" (по степени их согласования с большинством), сначала показывать "хороших", потом "плохих"
 
+
# вручную менять порядок показа их разборов
8) сохранять итоговую разметку в xml-файл (токены, для которых ответ не выбран, остаются без разметки)<br />
+
# особым образом помечать сложные случаи, чтобы потом можно было к ним вернуться (+ переходить между ними), иметь возможность писать к ним комментарии
 
+
# возможность оставить два и более разбора в итоговой разметке (такая потребность реально бывает)
9) сохранять информацию о текущем состоянии в файл "проекта"<br />
+
# убирать и добавлять токены в разметку (связано с тем, что границы между токенами требуется поменять вручную).
 
+
10) проверять валидность итогового xml-файла (с учетом п. 7)<br />
+
 
+
11) сообщать, сколько разборов осталось неразмеченными (в status bar?), и переходить к следующему неразмеченному<br />
+
 
+
12) давать возможность увидеть контекст (10 токенов слева и справа от текущего как сниппет) (NB всплывающее поле? в строке статуса по клику? отрисовывать его при каждом токене не хочется)<br />
+
 
+
Желательные фичи:
+
а) отрисовывать блекло повторяющиеся разборы, чтобы они не отвлекали пользователя (совсем скрывать их нежелательно, чтобы пользователь видел, откуда пришел тот или иной разбор)<br />
+
 
+
б) показывать [http://en.wikipedia.org/wiki/Cohen%27s_kappa каппу] inter-annotator agreement<br />
+
в) ранжировать аннотаторов от "хороших" к "плохим" (по степени их согласования с большинством), сначала показывать "хороших", потом "плохих"<br />
+
г) вручную менять порядок показа их разборов<br />
+
д) особым образом помечать сложные случаи, чтобы потом можно было к ним вернуться (+ переходить между ними), иметь возможность писать к ним комментарии<br />
+
е) возможность оставить два и более разбора в итоговой разметке (такая потребность реально бывает)<br />
+
ж) убирать и добавлять токены в разметку (связано с тем, что границы между токенами требуется поменять вручную).<br />
+
---
+
  
 
=== Чему вы научитесь? ===
 
=== Чему вы научитесь? ===
---
+
 
 +
# Основы проектирования и разработки клиент-серверных приложений
 +
# Базовые знания 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))
  
 
=== Темы вводных занятий ===
 
=== Темы вводных занятий ===
---
+
 
 +
# Архитектура клиент-серверных приложений и основные принципы разработки
 +
# Нереляционные базы данных, преимущества, недостатки, особенности использования
  
 
=== Направления развития ===
 
=== Направления развития ===
---
+
 
 +
# Различные варианты усовершенствование архитектуры серверной части, механизмов и алгоритмов клиент-серверного взаимодействия
 +
<!--# Развертывание кластера серверов с распределением нагрузки (например, http-сервером)
 +
# Развертывание кластера БД с шардами и репликацией -->
  
 
=== Критерии оценки ===
 
=== Критерии оценки ===
---
+
 
 +
# 4-5 - Система представляет собой клиент-серверное приложение, реализующее как минимум половину функции из списка требований (I)
 +
# 6-7 - Система, реализующая все функции из списка требований (I).
 +
# 8-10 - Система, реализующая функции все функции из списка требований (I), и, кроме того, реализованы 1-2 или более функций из списка Дополнительных требований (II). Для получения самого высокого балла (10) разработанная система должна иметь защиту от использования незарегистрированными пользователями, предоставлять возможность регистрации и входа в систему.

Текущая версия на 10:50, 20 октября 2015

Ментор Фролов Дмитрий
Учебный семестр Весна 2015
Учебный курс 1-й курс


Внимание! Данный проект находится в архиве и реализован не будет.

Что это за проект?

Мотивировка

Для разметки языковых данных в корпусах, базах данных и т.п. часто пользуются краудсорсингом, привлекая студентов, школьников, энтузиастов, низкооплачиваемых mechanical turks. Являясь непрофессионалами и не имея достаточного опыта, эти разметчики делают много ошибок, поэтому обычно одни и те же данные размечаются двумя-тремя-.. - пятью разметчиками. Нужен интерфейс для супервайзера-профессионала, который на основе этих параллельных разметок создаст правильную итоговую разметку. (Аналогично такую чистовую разметку делают на основе ответов нескольких автоматических разметчиков).

Что такое разметка?

Токен (слово или другая единица языка) с приписанным ему набором тегов ("разбором"), ср. пример из древнерусского:
<ana lex="проблискатисѧ" gr="V,praes,sg,3p" source_el="ἀπαστράπτεται"/>проблискаѥтсѧ
Пример параллельной разметки можно увидеть на картинке справа.

IMAG1097.jpg

Требования к разрабатываемой системе

Система должна предоставлять следующие функции (I):

  1. создавать "новый проект" и загружать исходные файлы (от двух до N xml-файлов разметки)
  2. выравнивать данные из разных файлов по токенам (возможны мелкие расхождения)
  3. показывать расхождения
  4. давать возможность пользователю выбрать один вариант ("правильный вариант")
  5. автоматически выбирать "правильный вариант", если разметки для токена везде совпадают
  6. выделять или (как опция) автоматически выбирать наиболее вероятный разбор по принципу "большинство голосует" (если разметок 3 и больше)
  7. давать возможность вручную написать новый разбор, если другие не годятся (в поле для редактирования)
  8. сохранять итоговую разметку в xml-файл (токены, для которых ответ не выбран, остаются без разметки)
  9. сохранять информацию о текущем состоянии в файл "проекта"
  10. проверять валидность итогового xml-файла (с учетом п. 7)
  11. сообщать, сколько разборов осталось неразмеченными, и переходить к следующему неразмеченному
  12. давать возможность увидеть контекст (несколько токенов слева и справа от текущего), возможно - в виде всплывающего поля по клику (дизайн - на усмотрение разработчиков)

Дополнительные требования (II):

  1. отрисовывать блекло повторяющиеся разборы, чтобы они не отвлекали пользователя (совсем скрывать их нежелательно, чтобы пользователь видел, откуда пришел тот или иной разбор)
  2. показывать каппу inter-annotator agreement
  3. ранжировать аннотаторов от "хороших" к "плохим" (по степени их согласования с большинством), сначала показывать "хороших", потом "плохих"
  4. вручную менять порядок показа их разборов
  5. особым образом помечать сложные случаи, чтобы потом можно было к ним вернуться (+ переходить между ними), иметь возможность писать к ним комментарии
  6. возможность оставить два и более разбора в итоговой разметке (такая потребность реально бывает)
  7. убирать и добавлять токены в разметку (связано с тем, что границы между токенами требуется поменять вручную).

Чему вы научитесь?

  1. Основы проектирования и разработки клиент-серверных приложений
  2. Базовые знания Unix Shell
  3. Работа с нереляционными базами данных

Какие начальные требования?

  1. Представление о технологиях создания веб-страниц
  2. Основы языка программирования Python

Какие будут использоваться технологии?

  1. HTML/CSS, JavaScript, JQuery
  2. Python 2.7
  3. WebPy/Web2Py/Django
  4. Ubuntu Linux/OpenSUSE/FreeBSD, GNU Emacs или Vim - на выбор
  5. MongoDB
  6. git, github/bitbucket
  7. http-сервер Nginx/Apache (возможно - в связке с WSGI-сервером (Gunicorn))

Темы вводных занятий

  1. Архитектура клиент-серверных приложений и основные принципы разработки
  2. Нереляционные базы данных, преимущества, недостатки, особенности использования

Направления развития

  1. Различные варианты усовершенствование архитектуры серверной части, механизмов и алгоритмов клиент-серверного взаимодействия

Критерии оценки

  1. 4-5 - Система представляет собой клиент-серверное приложение, реализующее как минимум половину функции из списка требований (I)
  2. 6-7 - Система, реализующая все функции из списка требований (I).
  3. 8-10 - Система, реализующая функции все функции из списка требований (I), и, кроме того, реализованы 1-2 или более функций из списка Дополнительных требований (II). Для получения самого высокого балла (10) разработанная система должна иметь защиту от использования незарегистрированными пользователями, предоставлять возможность регистрации и входа в систему.