Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ошибки разметки 1 #10

Open
konstantin-smith opened this issue Jan 17, 2016 · 7 comments
Open

Ошибки разметки 1 #10

konstantin-smith opened this issue Jan 17, 2016 · 7 comments

Comments

@konstantin-smith
Copy link

Насчёт Loc и LocOrg: некоторые размечающие, похоже, напутали. Обычные упоминания стран отмечают как LocOrg. Например, #98: Эстония ввела евро тогда, когда эта денежная единица переживает не лучшие времена: как известно, двум государствам еврозоны — Греции и Ирландии - все страны отмечены как LocOrg. Аналогично в #99, #115, #117 и т.д.

Похоже, при прогоне придётся не учитывать различия между Loc и LocOrg из-за большого количества брака в разметке.

@konstantin-smith
Copy link
Author

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

Теперь рассмотрим разметку. Везде, где организация имеет спаны org_descr и org_name, который в кавычках, диапазон спана org_name кавычки не включает. Но поскольку в objects идёт ссылка на спаны (а именно по ним определяется диапазон), то в этих случаях всегда закрывающая кавычка не включается.
Например, координатор движения «Левый фронт» - в objects + span кавычка исключена. Что при проверке приведёт к неправильному определению, так как участники будут эту кавычку включать в диапазон согласно требованию документации.

@StanDzh
Copy link
Collaborator

StanDzh commented Jan 18, 2016

Добрый день. Не могу прокомментировать проблемы в эталоне, но компаратор предусматривает обработку ситуаций с кавычками. В частности, токены, соответствующие кавычкам, просто не участвуют в сравнении - они не штрафуются.

По крайней мере, таково ожидаемое поведение. Правильно ли я понимаю, что Вы обнаружили "систематическую ошибку" в поведении компаратора? Или "систематическая ошибка" - это расхождение инструкции с эталоном?

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

@konstantin-smith
Copy link
Author

Попробую пояснить. Компаратор работает на основе информации из objects и span. Если объект состоит из 2-х атрибутов org_desc и org_name, то границы компаратор будет вычислять по 2-му (позиция) и 3-му (длина) столбцам файла span для этих атрибутов. Так вот, для org_name эти столбцы ссылаются на текст без кавычек. То есть компаратор не учтёт закрывающую кавычку в эталоне. А поскольку такая кавычка должна быть включена согласно документации, то все такие объекты будут неправильно интерпретироваться. Ещё раз процититую:

Если выделенная цепочка включает ещё что-то, кроме текста в кавычках, то кавычки нужно включить. Неправильным считается вариант ответа, включающий только открывающую или только закрывающую кавычку.

@vbocharov
Copy link
Contributor

Инструкция для участников верна. Она говорит о том, что поведение систем должно быть последовательным.

Инструкция для размечающих тоже верна. Они не включают кавычки в спан в описанных случаях.

Компаратор должен эту ситуацию отслеживать и не штрафовать участников, если они соблюдают требования той инструкции, которая адресована им.

@AndreyAv
Copy link

Вопрос про муки выбора типа сущности между LOC и LOCORG на примере файла book_389.txt. Вот четыре строки из файла, идущие подряд:

Азию [LOCORG] представляют два арбитра:
• Тору Камикава (Япония [LOCORG]) • Шамсул Майдин (Сингапур [LOCORG])
Африку [LOCORG] представляют два арбитра:
• Коффи Коджа (Бенин [LOC]) • Эссам Абд Эль Фатах (Египет [LOC])

В квадратных скобках я указал тип сущности в соответствии с разметкой. Как, все-таки, правильно в таком контексте размечать географию - как LOC или как LOCORG?

@konstantin-smith
Copy link
Author

Диверсия: в тексте book_74 во 2-й разметке имя у Медведева задано "ДимИтрий"

@mariarusia
Copy link

127 текст
1 23080 org_name 13 62 165715 5 # 165715 165716 165717 165718 165719 Всемирной продовольственной и сельскохозяйственной организации
2 23081 org_name 76 3 165720 1 # 165720 ООН

"По сведениям Всемирной продовольственной и сельскохозяйственной организации ООН (ФАО), в декабре 2010 г. цены на продукты питания достигли рекордных уровней. Эксперты связывают это с подорожанием сахара, зерновых и сырья для производства растительного масла."

Я так понимаю, ООН в этом случае должно попадать в название Всемирной продовольственной и сельскохозяйственной организации ООН

"В случаях, когда одна организация является частью другой (например, «Департамент картона министерства локализации упаковок»), допустимыми считаются два типа ответов:
o выделение одной организации, включающей в себя оба названия (часть и целое):
ORG: департамент картона министерства локализации упаковок
o выделение каждой сущности отдельно. В этом случае вложенные объекты должны включать в себя название всех вышестоящих сущностей:
ORG: министерства локализации упаковок
ORG: департамент картона министерства локализации упаковок"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants