Недавние мои подвижки в реализации задуманного функционала для проекта BIRMA , ставшие возможными благодаря использованию уже созданного Salesforce движка (и моим собственным его модификациям - [github.com]), побудили меня наконец поделиться со всеми историей самого проекта и некоторыми техническими аспектами всех его воплощений, включая нынешнее.

Этот материал вполне мог бы задать тему и для доклада на предстоящем ЛИБКОМе , но, увы, не на этот раз — хотя бы по причине того, что формально я уже не имею никакого отношения к какой-либо библиотечной деятельности. Конечно, мои разработки можно расценивать в том числе и как околобиблиотечные утилиты — но теперь уже я что-то добавляю или расширяю лишь исключительно на чистом энтузиазме.

Так что более уместной в данном случае площадкой для публикации мне показался Habrahabr — к счастью, местные модераторы мой креатив одобрили (так что теперь, возможно, там же появятся и некоторые другие мои посты). Вот ссылка на размещённый там вчера текст:

[habr.com]

Продолжение данной темы (с более подробным рассмотрением особенностей использования движка) см. здесь: [irbis.elnit.org], либо можно сразу перейти ко второй статье: [habr.com]



Редактировано 1 раз. Последний раз 01.12.2019 09:14 пользователем S-presso.

Если использовать регулярные выражения (которые поддерживаются во всех ЯП и на всех платформах), то и плодить квази-интерпретаторы - клоны подмножества квази-языка CDS/ISIS - ИРБИС не надо будет.

Регуляркой такая простая вещь, как текст оглавления, разбирается на раз.
Хотя, с удовольствием пощупал бы эту "БИРМУ"

upd: точнее, интересует чисто реализация интерпретатора



Редактировано 1 раз. Последний раз 07.11.2019 10:23 пользователем Игорь.

Кстати, как был решен вопрос с текстами, которые полностью в верхнем регистре? Интересует реализация алгоритма грамотного преобразования слов, которые должны начинаться с заглавной буквы или полностью состоять из них (Фамилии, имена собственные, аббревиатуры).

Э... стесняюсь спросить, а Вы внимательно статью читали?
Вообще-то к форматированию (в том числе и с применением «квази-языка CDS/ISIS - ИРБИС») описанная часть SDK под общим названием BIRMA.NET не имеет никакого отношения. Она выполняет прямо противоположную задачу — выделяет отдельные упорядоченные фрагменты из уже каким-либо образом отформатированного текста (неважно, автоматическими ли средствами это было сделано, или просто используется готовый входной образец, характеризующийся сколько-либо выраженной упорядоченностью, — например, текст отсканированного оглавления). Для хранения всех таких повторяющихся последовательностей используется специальное внутреннее представление, где каждый полученный фрагмент хранится вместе со своим соответствующим идентификатором — именно эти-то идентификаторы и задаются в специальных описаниях шаблонов (template), синтаксис которых был позаимствован (вместе со всей кодовой базой) из проекта Salesforce Gorp. При описании Gorp’овских шаблонов как раз-таки и используются привычные регулярки — но, как правило, не напрямую, а с помощью подстановок из паттернов (pattern), которые в свою очередь уже целиком описываются регулярками. Кроме того, в BIRMA несколько расширен синтаксис паттернов — были введены два служебных паттерна (%all_before) и (%all_after), которые, подобно другим паттернам, можно подставлять в произвольное место любого паттерна (и, соответственно, и шаблона тоже), но в то же время они не имеют собственного представления в виде регулярных выражений, а содержат указание о переходе к поиску следующей за ними части выражения, а всё, что содержится в промежутке, либо просто не включается в выходные данные (%all_before), либо конкатенируется с последующим фрагментом (%all_after). Отмечу, что теоретически это позволяет осуществлять требуемый разбор любого входного текста — например, исходного кода веб-сайта для извлечения всех нужных данных. Простой регуляркой такого не сделаешь.

Что касается последующего форматирования получаемых выходных данных, то такая возможность в BIRMA.NET тоже присутствует — в частности, это позволяет создать нужную разметку для всех добавляемых элементов библиографической записи, полученных в ходе описанного выше процесса разбора, и просто импортировать её в нужную запись, как это делает «Каталогизатор». При этом сама утилита, взаимодействующая с движком BIRMA, ничего никуда не импортирует — она только создаёт файл с нужной разметкой (или, в ирбисовских терминах, — нужным форматом). Таким образом она носит универсальный характер и формально не привязана ни к Ирбису, ни к какой-либо другой СУБД. Применяемый при этом язык генерации разметки тоже не имеет никакого отношения к ирбисовскому языку форматирования. Также имеется возможность быстро перевести все полученные выходные данные в формат JSON. Отмечу ещё, что поскольку BIRMA.NET — это обычная DLL-библиотека, ничто не препятствует также и созданию собственных пользовательских утилит на её основе. Теоретически можно и ирбисовский АРМ так соорудить, но я уже этим не балуюсь (простой плагин для «Каталогизатора» или даже чистый импорт из файла вполне решают задачу).

Игорь написал(а):
-------------------------------------------------------
> Кстати, как был решен вопрос с текстами, которые
> полностью в верхнем регистре? Интересует
> реализация алгоритма грамотного преобразования
> слов, которые должны начинаться с заглавной буквы
> или полностью состоять из них (Фамилии, имена
> собственные, аббревиатуры).


Такая задача не решается в BIRMA.NET в ходе парсинга данных, но можно обрабатывать уже полученные после разбора данные (представленные в формате JSON или любом другом на усмотрение пользователя). Кроме того, сам используемый там язык разметки уже содержит функции для преобразования данных в нижний/верхний регистр (как, собственно, можно подключить и любые другие функции, доступные для платформы .NET).
Но, поскольку я сам уже неоднократно имел дело с оглавлениями в верхнем регистре, то мне вполне очевидна и необходимость последующей ручной правки данных, которой можно было бы избежать при соответствующей интеллектуальной реализации перевода в нижний регистр — с подключением специальных словарей всех имён и названий, пишущихся только с заглавной буквы. Однако сам я подобной задачи перед собой не ставил.

Статью я прочитал. Поэтому и высказал краткое резюме о регулярках.
Разве не Ваши слова там о попытках изобразить подобие функционала языка форматирования ИРБИС? И про последующий переход к библиотеке, использующей регулярку в качестве ядра.
И, я когда-то только регулярками и парсил сайты (пока не познакомился с bs4) для выгребания нужной информации, в том числе описания разных и новых книг.

Мне вот интересно - можно ли с этой библиотекой менять правила разбора "на лету", не перезагружая программу ?

И, я правильнно понял, BIRMA не сохраняет полученные данные в базу к соответствующей записи журнала или книги?

S-presso написал(а):

> Такая задача не решается в BIRMA.NET в ходе
> парсинга данных, но можно обрабатывать уже
> полученные после разбора данные (представленные в
> формате JSON или любом другом на усмотрение
> пользователя). Кроме того, сам используемый там
> язык разметки уже содержит функции для
> преобразования данных в нижний/верхний регистр
> (как, собственно, можно подключить и любые другие
> функции, доступные для платформы .NET).
> Но, поскольку я сам уже неоднократно имел дело с
> оглавлениями в верхнем регистре, то мне вполне
> очевидна и необходимость последующей ручной правки
> данных, которой можно было бы избежать при
> соответствующей интеллектуальной реализации
> перевода в нижний регистр — с подключением
> специальных словарей всех имён и названий,
> пишущихся только с заглавной буквы. Однако сам я
> подобной задачи перед собой не ставил.

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

Игорь написал(а):
-------------------------------------------------------
> Разве не Ваши слова там о попытках изобразить
> подобие функционала языка форматирования ИРБИС? И
> про последующий переход к библиотеке, использующей
> регулярку в качестве ядра.


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

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



Редактировано 1 раз. Последний раз 09.11.2019 01:02 пользователем S-presso.

Игорь написал(а):
-------------------------------------------------------
> И, я когда-то только регулярками и парсил сайты
> (пока не познакомился с bs4) для выгребания нужной
> информации, в том числе описания разных и новых
> книг.
>

Ну, в общем, Gorp’овский парсер тоже фактически генерирует одну такую большую регулярку. Но даже в оригинальной версии Gorp использовался несколько более сложный алгоритм, чем простое применение получившегося выражения к исходному тексту. А в моей модификации он выглядит ещё более замороченным. Потому я и писал, что одной большой регуляркой его уже не обработать — её в любом случае приходится делить на составные части. Но, конечно, это касается только принятой в самой BIRMA реализации, а не в целом.
По мне, так подобные длиннющие регулярные выражения выглядят слишком страшно, чтобы их применять в повседневной практике. Нет, понятно, что и все компилируемые в память программы тоже можно писать на языке ассемблера (или в двоичном коде). Но есть ли смысл в подобных ухищрениях, если получаемые структуры всё равно мало кто способен осмыслить и удержать в голове? Потому и возникли в своё время трансляторы с языков высокого уровня в соответствующий двоичный код (или ассемблерные инструкции). Вот и бирмовский парсер по сути делает что-то подобное — позволяет удобно структурировать поисковое выражение «для простых смертных».