Вызов параллельных корпусов

[maria-terekhina]

Предыстория: код для всех параллельных корпусов в НКРЯ абсолютно одинаковый. Когда мы инициализируем объект Query, нам нужно указать название корпуса по которому мы сейчас будем искать. В параллельном корпусе помимо этого нужно указать только язык-подкорпус (параметр subcorpus, не targetLanguage), по которому сейчас будет идти поиск. Если этот язык указан, в пару автоматичеки ставится русский. Если этот язык не указывать (или указать 'rus'), то query будет искаться во всех параллельных подкорпусах (будут пары русский + любой язык, где нашлось).

Вопрос: все ли нас в таком случае устраивает? Под каким кодом записать параллельный НКРЯ в query.py? Нужно ли для случая, когда идет поиск по всем параллельным подкорпусам в объекте Target указывать еще и язык найденного примера?

[agricolamz]

Я бы хотел от пользователя эксплицитного прописывания в разных аргументах rus и eng или rus и all (по умолчанию?), и в таком случае выдавать табличку со столбцами для конкретных языков.

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

[akv17]

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

• насчет alias для параллельного нкря -- не знаю. может просто rus_parallel?
• режим rus и all в текущую архитектуру совершенно не вписывается. указывать язык найденного примера можно, но все равно ведь возникает множество трудностей, основанных на том, как один тип Target сделать одновременно подходящим и для обычных корпусов, и для параллельных. как возможное решение проблемы, у меня есть две идеи:
  • i) если пришло rus и all, вернуть словарь с ключами - языковыми парами, значениями - объектом Result, в котором каждый Target содержит пример только для языковой пары из ключа
  • ii) на базе уже готовых типов завести аналогичный тип, но с расширенным функционалом для параллельных корпусов (скорее всего в будущем ведь еще параллельные появятся). например, завести тип ParallelTarget, в котором будет доступ ко всем возможным языковым парам для данного примера, корректное отображение __str__ и другие возможности, поддерживающие как бы векторизацию по разным языкам перевода

вторая идея мне кажется наиболее оптимальной и я готов реализовать / помочь в реализации новых Parallel типов

[kategerasimenko]

@maria-terekhina Так, я пока не очень понимаю. Так что сейчас серия тупых вопросов: 1) а нельзя сделать так, чтобы у нас был один код для НКРЯ? - это программа максимум 2) а нельзя сделать так, чтобы у нас был параметр targetLanguage, а уже внутри кода был перевод в suborpus? И в тч сделать значение all, а дальше его обработать внутри кода. 3) Но у нас же всегда будет rus в корпусе? Зачем указывать rus где-либо? 4) И в чем собственно вопрос? В том что класс Target не подходит под параллельные? В том, что если у нас много языков, то нам надо руками сопоставлять пары и объединять пары в ряды (так ли это?)?

@akv17 мне нравится идея 2. Только я не знаю, насколько норм иметь для каких-то корпусов объект Target, а для каких-то ParallelTarget. Надо будет мб подумать и сделать так, чтобы ничего не падало (например, в цикле вызывается метод, который есть только в ParallelTarget и обычный Target падает).

[akv17]

@kategerasimenko введем тип ParallelQuery, тем самым, по сути, имея две архитектуры: одна для обычных, другая для параллельных. тогда при работе с параллельными пользователь будет работать с ParallelQuery.

[kategerasimenko]

@maria-terekhina У нас с @akv17 возник спор. Кажется, удобнее сделать ParallelTarget и мб ParallelResult, но мы не можем решить, нужно ли делать ParallelQuery. Он хорош из структурных соображений - вызвал параллельный запрос, получил параллельный результат (это говорит Артем), но в самом Query ничего не меняется и тогда не очень понятно, зачем заводить новый объект, да и пользователю тогда придется делить обычный запрос и параллельный (это говорю я). Может у тебя как у эксперта по параллельным корпусам будут какие-то мысли на этот счет?

[maria-terekhina]

@akv17 @kategerasimenko Делать один код для всего НКРЯ, мне кажется, нет смысла. Не вижу, зачем объединять параллельный и основной корпуса.

Выдача учстроена таким образом: у нас всегда пара русский + какой-то язык. Мультиязыковых примеров не бывает, все языки отпараллелены только с русским (пример выдачи без спецификации языка: http://search1.ruscorpora.ru/search.xml?mycorp=&mysent=&mysize=24681277&mysentsize=1608376&dpp=&spp=&spd=&text=lexform&mode=para&sort=gr_tagging&env=alpha&req=%EA%EE%E4)

@agricolamz, мне показалось логичным считать язык именно подкорпусом, а не targetlanguage. Потому что при поиске в этих подкорпусах можно делать запрос как на русском, так и на втором языке, нигде специально не указывая язык оригинала. У нас нет необходимости просить пользователя прописывать, какой язык оригинала, а какой перевода.

Собственно, я не вижу особой проблемы в том, чтобы просто разветвить str в том же target.py. Просто добавить в конструктор параметр queryLanguage, который по умолчанию None, и если он передается в конструктор, то добавлять его в str. То же самое и спереводом. У нас и так уже довольно сложная архитектура. Если усложнять дальше, это будет уже совсем не user-friendly.

[kategerasimenko]

@maria-terekhina @akv17 я не очень понимаю, но у меня есть предложение. Что если Маша переделает Target как удобно для параллельных корпусов + напишет комменты к изменениям и куда-нибудь его зальет? (не уверена что в master стоит переделку заливать, мб скинуть на почту или в чат). И тогда посмотрим, насколько переделка удобна в целом?

[agricolamz]

Люди для этого придумали разные ветки на гитхабе.

[kategerasimenko]

@agricolamz я подозревала :) но я так и не научилась ими нормально пользоваться, к своему стыду.