Версия Ирбис64 2010.1 d6.

База данных собственная. Словарь ключевых слов создается по сценарию

2001 8 MDL,'/K=/',v200#
2021 8 MDL,'/K=/',v202#
1001 8 MDL,'/K=/',v100#

В сценарии поиска указан префикс K=. Вроде бы все как обычно. Но в каталогизаторе вижу ЭТО!



Таблицу ISISACW.TAB так же прикрепил. Я из нее что-то когда-то удалял. В результате у меня не все строчки были одинаковой длины. выровнял строчки с кодами. Все равно такое.

Эффект: в найденном слове в качестве термина попадает только та часть слова, которая идет после буквы Л. Часть до Л в словарь не попадает. Не могу понять, в чем проблема.



Редактировано 3 раз. Последний раз 06.03.2012 14:46 пользователем Панев Максим.

Выход простой:
Взять ISISACW.TAB из дистрибутива и создать словарь заново.

Сработало.

Давайте теперь разбираться в причинах. Были удалены 2 символа: 171 (xAB=«) и 187 (xBB=»). Т.е. русские кавычки были убраны из набора значащих символов. Казалось бы, что в этом такого? Я так понимаю, это ошибка ИРБИСа?

Сейчас вот такая ситуация:





Редактировано 6 раз. Последний раз 06.03.2012 15:52 пользователем Панев Максим.

Все работает верно - если аккуратно корректировать isisacw.tab и помнить, что при изменении таких ресурсов как isisacw.tab надо ПЕРЕЗАПУСКАТЬ сервер (который кэширует) и СОЗДАВАТЬ СЛОВАРЬ ЗАНОВО ПОЛНОСТЬЮ

Александр Иосифович. Подменил таблицу на лету не перезагружая сервер. Запустил АРМ Администратор, пересоздал словарь. Термины изменились.
Видимо перезагрузка сервера нужна только для актуализации словаря с клиентов.
Если вы утверждаете, что все работает правильно, то я вас очень прощу прикрепить к сообщению таблицу, где указанные 2 символа не являются частью слова, чтобы я проделал индексацию на вашем варианте. Потому что с моим вариантом результат индексирования приведен в первом сообщении.

Спасибо. Есть ошибка...

Alio написал(а):
-------------------------------------------------------
> Спасибо. Есть ошибка...
Это не ошибка, а...
В связи с тем, что кодировка данных в БД UTF8, разделителями слов (т.е. НЕАЛФАВИТНЫМИ символами) в шкале ISISACW.TAB можно объявлять ТОЛЬКО символы из ПЕРВОЙ половины набора от 001 до 127

Так это же не правильно!

Что значит "неправильно"? - Так есть.

А как мне, в этом случае, решить мою проблему с русскими кавычками в начале термина?

Провести глобальную корректировку - заменить "русские" кавычки на "латинские"

Я вас понял.

Alio написал(а):
-------------------------------------------------------
> разделителями слов (т.е. НЕАЛФАВИТНЫМИ символами)
> в шкале ISISACW.TAB можно объявлять ТОЛЬКО символы
> из ПЕРВОЙ половины набора от 001 до 127

Зачем тогда в файле указаны коды 128 — 255?

--
Сергей Кузнецов

Отвечу сам. У ирбиса вообще похоже нет поддержки юникода. При создании словарей входящий текст рассматривается как поток байтов. Например букву «л» в кодировке UTF8 он увидит как два байта с кодами 208 187, а раз 187 нет в таблице, то он обрезает всё от начала слова до буквы «л» и считает что следующая буква будет началом ключевого слова. А реальное начало слова уходит в небытие.

--
Сергей Кузнецов

Цитата:

У ирбиса вообще похоже нет поддержки юникода.

Некорректное утверждение. Ирбис поддерживает юникод, хоть не полностью.
Как же тогда по вашему ИРБИс держит данные, в которых встречаются символы не из ANSI?

woodyfon написал(а):
-------------------------------------------------------

> Как же тогда по вашему ИРБИс держит данные, в
> которых встречаются символы не из ANSI?

Может частично что-то и держит. Но со словарями пока всё плохо.
Непонятно как игнорировать в словарях юникодные знаки препинания.
Например есть много вариантов кавычек и тире, но в Ирбисе можно указать только коды апостофа (') обратного апостофа (`) двойной кавычки (") и дефиса-минуса (-).

Предлагается глобальными корректировками уродовать оригинальные названия.

А почему нельзя перед созданием словарей делать «нормализацию» — заменять или удалять нестандартные символы? Подобно тому, как сейчас все символы приводятся к верхнему регистру.

--
Сергей Кузнецов

Alio написал(а):
-------------------------------------------------------
> Провести глобальную корректировку - заменить
> "русские" кавычки на "латинские"

А с индексацией полнотекста что делать? Не в исходные же pdf изменения вносить. Как корректно "подавить" 171 и 187?

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Куделя написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > Провести глобальную корректировку - заменить
> > "русские" кавычки на "латинские"
>
> А с индексацией полнотекста что делать? Не в
> исходные же pdf изменения вносить. Как корректно
> "подавить" 171 и 187?
Никак. Для разбиения PDF-текста на слова разработчик использует стороннюю утилиту, в которой НИЧЕГО изменить не может.

Не совсем понял.
Разве индексируются непосредственно pdf-файлы страниц извлекаемых при добавлении, а не данные из 27 поля Ibis--text\text.mst?

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Куделя написал(а):
-------------------------------------------------------
> Не совсем понял.
> Разве индексируются непосредственно pdf-файлы
> страниц извлекаемых при добавлении, а не данные из
> 27 поля Ibis--text\text.mst?
Это замечательно, что Вы изучаете структуру скрытой полнотекстовой БД, но...
При извлечении слов из текста (в UTF-кодировке) используются символы-терминаторы слов (т.е. символы, не являющиеся частью слов) - таковыми могут быть ТОЛЬКО символы основного набора (0-127)

Таким образом мы вернулись к исходному. Если нет возможности изменить принцип выделения слов в процессе инвертирования, нам надо поменять сами данные для инверсии.

Это можно сделать:
а) на этапе загрузки данных в mst, подменяя во входном массиве символов "лапки" на обычные "прямые кавычки", т.е. до индексации
б) менять данные уже после после загрузки, с последующей актуализацией.

В ТВП инверсного файла полнотекстовой части не вижу индексации 27 поля из чего делаю вывод, что индексация производится однократно и только на этапе загрузки, без оглядки на text.fst.

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

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Куделя написал(а):
-------------------------------------------------------
> Таким образом мы вернулись к исходному. Если нет
> возможности изменить принцип выделения слов в
> процессе инвертирования, нам надо поменять сами
> данные для инверсии.
>
> Это можно сделать:
> а) на этапе загрузки данных в mst, подменяя во
> входном массиве символов "лапки" на обычные
> "прямые кавычки", т.е. до индексации
> б) менять данные уже после после загрузки, с
> последующей актуализаци
Однако...

Alio написал(а):
-------------------------------------------------------
> Однако...

Но делать-то что-то надо

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Куделя написал(а):
-------------------------------------------------------
> Alio написал(а):
> --------------------------------------------------
> -----
> > Однако...
>
> Но делать-то что-то надо

Ну что ж, противиться требованиям ТАКОГО пользователя никак нельзя.
В версии 2022.1 будет чистка кавычек « »

Alio написал(а):
>
> Ну что ж, противиться требованиям ТАКОГО
> пользователя никак нельзя.
> В версии 2022.1 будет чистка кавычек « »

Александр Иосифович, огромное Вам спасибо! Хотя все-таки надеюсь, что это не только потому что я "такой пользователь", но и потому что доработка действительно важная и существенно улучшающая систему :)
Думаю, что и Максиму, который отметил проблему десять лет назад, это бы тоже пришлось по душе.

Разрешите сразу уточнение по поводу реализации. Это будет "вшито" в процесс загрузки полных текстов или как-то постфактум? Мне не совсем понятно как формируется индекс KT= в ПТБД. Из того что я вижу, как уже написал, складывается впечатление, что термины грузятся в индексный файл "напрямую" из pdf. Зачем тогда в мастер-файле 27 поле? Только для определения "близости слов" и ранжирования результатов поиска? Это я к тому что в результате доработки придется по новой реиндексировать весь массив документов или все-таки можно будет как-то минимизировать затраты.

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

Куделя написал(а):
-------------------------------------------------------
> Alio написал(а):
> >
> > Ну что ж, противиться требованиям ТАКОГО
> > пользователя никак нельзя.
> > В версии 2022.1 будет чистка кавычек « »
>
> Александр Иосифович, огромное Вам спасибо! Хотя
> все-таки надеюсь, что это не только потому что я
> "такой пользователь", но и потому что доработка
> действительно важная и существенно улучшающая
> систему :)
> Думаю, что и Максиму, который отметил проблему
> десять лет назад, это бы тоже пришлось по душе.
>
> Разрешите сразу уточнение по поводу реализации.
> Это будет "вшито" в процесс загрузки полных
> текстов или как-то постфактум? Мне не совсем
> понятно как формируется индекс KT= в ПТБД. Из того
> что я вижу, как уже написал, складывается
> впечатление, что термины грузятся в индексный файл
> "напрямую" из pdf. Зачем тогда в мастер-файле 27
> поле? Только для определения "близости слов" и
> ранжирования результатов поиска? Это я к тому что
> в результате доработки придется по новой
> реиндексировать весь массив документов или
> все-таки можно будет как-то минимизировать
> затраты.
Придется загружать словарь полностью, но без процесса разбиения на страницы.

Alio написал(а):
-------------------------------------------------------
> Придется загружать словарь полностью, но без
> процесса разбиения на страницы.

Это хорошо.
Я что-то попустил, а есть такой режим?

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP