Существует ли какая нибудь связь между каталогом и полнотекстовыми документами?

Какая связь Вас интересует? Полнотекстовый модуль может работать без Ирбис64, если Вас это интересует...

Это я уже понял. А можно чтобы из каталога по ссылочке переходить к полнотекстовым документам в полнотекстовом модуле?

Теоретически это возможно. Нужно только доработать АРМ Полнотекстовый читатель. Хотя смысла в использовании именно этого арма для просмотра ПТ я не вижу. Вернее вижу :), но можно и без него.

Можно организовать поиск по словам из текстов прописанных как внешние объекты в Каталоге
Это имеет смысл делать для небольших по объему текстов - статей или аннотаций

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

Да, ИРБИС54 ПОЛН.ТЕКСТ может работать внутри (вместе с) ИРБИС64 - м.б. для того чтобы вести биб.описания полных текстов (т.е для совмещения двух концепций: библиографические БД и полнотекстовые БД) - весь вопрос в том, ЗАЧЕМ ЭТО НУЖНО. Ведь в ИРБИС64 (без ПОЛНЫХ ТЕКСТОВ) есть возможность прикреплять к биб. описаниям внешние объекты... Т.е. надо выбирать: или библиографическая БД с прикрепленными внешними объектами (при этом поиск идет по биб. описанию, а внешний объект, он же полный текст, используется как "иллюстрация"), или полнотекстовая БД без всяких биб.описаний с поиском по полным текстам. Совмещать эти концепции, т.е. вести поиск и по биб.описанию и по полному тексту - мне кажется НЕРАЗУМНО...

[irbis.gpntb.ru]
Все это уже обсуждалось

> мне кажется НЕРАЗУМНО...

Достаточно посмотреть на интерфейс любой поисковой системы, используемой в коммерческих полнотекстовых базах данных. Например, интерфейс Emerald - [thesius.emeraldinsight.com]

Пророчество:
ИРБИС64FT как отдельный продукт не будет пользоваться большим спросом, а приобретать и его, и "просто" ИРБИС явно нелогично.
Поэтому: полнотекстовый поиск и автоклассификация скоро войдут в "основной состав" АРМов ИРБИСа просто как новые дополнительные функции, повышающие комфортность работы пользователя.
Позже попробую дать более подробное обоснование.



Отправка отредактированного (21-07-05 15:03)

ИРБИС64 ПОЛНОТЕКСТОВЫЕ БД можно рассматривать и как дополнительный модуль в ИРБИС64, и как автономный продукт - так он и продается...

В любом случае, независимо от концепции или парадигмы, и чем станет в конечном итоге ИРБИС64FT, в нем обязательно нужно следующее:
1. Поиск без усечения. Пример: ввожу «Панев», получаю 75 документов. Ну, думаю, во писателище!!! А оказалось, что нашлись доклады со словами «панацея», «панорама» и т. д.
2. Поиск «Фраза целиком». Пример: ввожу «Российская государственная библиотека», получаю все документы, где упоминаются или Российская, или государственная, или библиотека.
3. Поиск внутри каждого из найденных полных текстов, вроде того, который есть в «просто» ИРБИСе («Полное описание» - «Найти»)
4. Операторы И, ИЛИ, НЕ. Пример: ввожу «Web-ИРБИС», получаю все документы, где упоминаются или Web, или ИРБИС.
5. Упорядочение найденного как минимум по релевантности и по дате.
6. Выделение и копирование фрагментов текста.

Опять-таки, по демо судить трудно, но кажется, что в ИРБИС64FT нет ничего ИРБИСовского, библиотечно-библиографического — этот модуль (если рассматривать его отдельно) не Интегрированный, не Развиваемый и не Библиотечный. Получается ПТИПС?
Он больше похож на модные «десктопные поисковики», за исключением того, что они обычно встраиваются в браузеры (в моей коллекции таких 24, и ни один не работает:)))
Предположим даже, что он очень хорош для обработки социологических, экологических и т. д. данных, и может использоваться, например, для анализа результатов соц. исследований, в том числе проводимых в библиотеках… (но это относится скорее к Visual HCA). И по-прежнему хочется узнать, можно ли использовать ИРБИС64FT в библиотечной научно-исследовательской и научно-методической работе.
А еще больше он похож просто на оболочку полнотекстовых БД, которые по содержанию могут быть любыми, например, «справочно-правовыми».
Видимо, главная особенность (достинство, преимущество, изюминка, фишка) ИРБИС64FT — это «Поиск похожих». Но так как все крымские доклады в какой-то степени похожи друг на друга, пока никаких выводов об этом сделать нельзя.
…почитал доклады разработчиков 2003-2004 гг. и понял: то, что есть сейчас — пока что скорее «черновик».

...и все-таки, поскольку ИРБИС64 позиционируется как инструмент для создания электронных библиотек, в нем должно быть описание по Dublin Core...

А.Лавринович писал(а):

>4. Операторы И, ИЛИ, НЕ. Пример: ввожу «Web-ИРБИС», получаю все
>документы, где упоминаются или Web, или ИРБИС.
Вроде были, хотя может я чего-то и путаю.

> 5. Упорядочение найденного как минимум по релевантности и по
> дате.
Одной из фишек "...является так же собственный оригинальный механизм ранжирования..." (с) Бродовский

> 6. Выделение и копирование фрагментов текста.
Так а это вроде бы есть. Кстати, если полный текс - html - это нет проблем, а если PDF, то его можно защитить от копирования. Формат у него такой :). Таким образом возможность 6 не зависит от АРМа.

Ранжирование результата естественно существует - в этом суть разработанного алгоритма поиска. Если первыми выходят док-ты, в которых присутствуют отдельные слова (из запроса из нескольких слов) - это значит, что ДРУГИХ НЕТ.
Если в результате поиска по запросу "Web-ИРБИС не первом месте не оказалось до-ков, в которых упоминается "Web-ИРБИС", значит таковых просто нет.
Что касается правого усечения - то в обновленной версии будет работать морфология слов русского языка (вместо усечения) - т.е. при поиске по слову КОМПЬЮТЕР будут выдаваться документы, где присутствуют только флексии этого слова (на ПАНЕВ будет отзываться только ПАНЕВ)

Немножко обнадежили и утешили.
Хотя с принципами ранжирования я пока не разобрался (на примерах "крымской" базы и сделанной мной тестовой).
Однако продолжим.
…как известно, в «поисковиках» релевантность определяется, мягко говоря, очень своеобразно — как часто в документе встречается данное слово или фраза, что, как известно, вызывает множество нелепиц, анекдотических результатов, а также допускает множество махинаций.
Очевидно, что она должна определяться по совокупности признаков: заглавиям, по всему лингвистическому обеспечению (если оно имеется), далее — по предисловиям, аннотациям, рефератам, заключениям, выводам, оглавлениям… И ТОЛЬКО В ПОСЛЕДНЮЮ ОЧЕРЕДЬ И ПРИ ОТСУТСТВИИ ВСЕГО ВЫШЕПЕРЕЧИСЛЕННОГО – ПО ЧАСТО ПОВТОРЯЮЩИМСЯ СЛОВАМ.

Поэтому в данной дискуссии разделяю точку зрения Е.Негуляева и не могу удержаться от того, чтобы не процитировать его:
«Недостатки чисто полнотекстового поиска известны давно и прослеживаются на истории развития поисковых машин для интернет. Поиск на основе анализа частотности, местоположения слов и т. п. оказался неудовлетворительным […] чисто полнотекстовый поиск имеет массу недостатков […].
полнотекстовый поиск обязан (!) комбинироваться с поиском по метаданным, в нашем случае по библиографическим данным, классификационными индексам, ключевым словам и т. п. Нельзя упрощать проблему, представляя электронную библиотеку как свалку текстов, к которой мы обеспечиваем легкий доступ путем организации полнотекстового поиска […]».
«должен быть единый АРМ, позволяющий комбинировать полнотекстовые запросы с запросами по библиографическим данным, индексам и т. п.»

Комментарий. То есть полнотекстовый поиск должен (может) быть дополнительной функцией, вроде «уточнения запроса».
Ведь и сам К. О. пишет: «Задача автоматизированного смыслового анализа текстов разбивается на две части — подготовка базы данных к использованию алгоритмов смыслового анализа и разработка интерфейса для использования этих алгоритмов читателем библиотеки. Вторая часть задачи может быть решена внутри системы ИРБИС в виде дополнительного поискового сервиса […]. Для пользователей системы ИРБИС применение алгоритмов смыслового анализа текстов станет существенным дополнением к существующей системе» (Сбойчаков К. О. Перспективы развития ИРБИС: применение системы смыслового анализа текстов для создания полнотекстовых хранилищ знаний в современной библиотеке. 2003). Значит, все-таки дополнение, а не замена?

И еще две цитаты — из прошлогодней темы «ИРБИС на предприятиях». Сначала из А.С.К.: «сохранение всего файла в некоей БД (полнотекстовое хранилище) с получением дополнительных сведений о файле и АВТОМАТИЧЕСКОМ ЗАПОЛНЕНИИ НЕКОТОРЫХ ПОЛЕЙ ОПИСАНИЯ ФАЙЛА» (выделено мной. — А.Л).
А теперь — из себя:
«ИРБИС + WebIRBIS нужно дополнить функциями:
1. интеграции с системами OCR
2. потокового ввода бумажных документов
3. предварительной автоклассификации полнотекстовых документов ПО ЗАДАННЫМ ПРИЗНАКАМ (ЗАГОЛОВОК, КЛЮЧЕВЫЕ СЛОВА и т. д.)» (выделено мной же. — А.Л).

Вот тогда и будет настоящее "полнотекстовое хранилище". И снова приходим к необходимости Dublin Core и, видимо, XML («автоматическое заполнение некоторых полей»)?



Отправка отредактированного (05-08-05 14:58)

Видимо, нужно было бы сначала определить значение термина «полный текст». Возьмем для примера доклад. Он обычно содержит следующие элементы, по-моему, НЕ ВХОДЯЩИЕ В ПОНЯТИЕ "ТЕКСТ": автор, его место работы, заглавие, аннотацию, список литературы. Так вот, пожалуй, главный недостаток полнотекстового поиска в ИРБИС64 в его нынешнем «автономном» виде» — он воспринимает весь документ как «монолит». Хотя очевидно, что если я ввожу запрос «Бродовский», то хочу получить те доклады, где он является автором, а не упоминается в списке литературы или в самом тексте!
То есть поиск должен начинаться с метаданных (~ библиографических описаний), и только в самую последнюю очередь обращаться к собственно ТЕКСТУ.
Для солидности сошлюсь на мнение "классика" Б.А.Семеновкера. В статье "Библиография в Древнем Египте" он писал, что если в начале папирусного свитка указаны его автор и название, то это и есть библиография - а стало быть, не текст произведения. Журнал "Библиография", год примерно 1993-й, точнее сообщу потом.



Отправка отредактированного (05-08-05 14:56)

Юмор и сатира
1. Об автоклассификации полнотекстовых документов «по признаку превышения общеупотребительной частоты». На похожем принципе основаны поисковые системы интернета, результат работы которых часто бывает анекдотическим или нулевым.
И неужели эта технология распространяется на гуманитарную и художественную литературу? Примеров можно придумать сколько угодно. Например, в теологическом трактате может ни разу не встретиться слово «Бог», в лирическом стихотворении — «любовь» (любимое ключевое слово А. И. Вислого) и т. д. И наоборот — например, часто повторяется слово «библиотека», а речь идет не о библиотеке, а о программировании.
Видимо, это все-таки касается только научно-технической литературы, причем пользователь должен сначала сообщить системе предметную область (как при машинном переводе — «голый кондуктор бежит по автобусу», «гуртовщик мышей» и т. д.). Также, видимо, не обойтись без индексации «ручками», тем более что предусматривается «предварительная работа [«ручками»? — А. Л.] по созданию полнотекстовой базы данных и естественно-тематическая классификация текстов».

2. О тенденции любой информации объединяться в тематические группы «по интересам». То есть книги на одну тему сами бегут на одну полку, а из политематического ЭК «похожие» записи сами себя отправляют в специализированные БД?

3. О «возможности находить тексты, близкие к заданному образцу. В качестве текста образца может выступать поисковый запрос читателя на естественном языке, произвольный полный текст (внешний по отношению к базе данных) или текст из базы данных»:
· запрос на естественном языке — напоминает микрософтовскую «скрепку с глазами», ответы которой часто не имеют никакого отношения к вопросу.
· полный текст — напоминает мое предложение ввести режимы «Поиск похожих» и «Поиск похожих в интернете»

4. А как насчет смыслового анализа аудио-, видео-, графических объектов и их автоклассификации и поиска? Google уже ищет (или пытается искать) фрагменты телепередач...

Попробовал тестовые полнотекстовый модуль. Я так понимаю, по умолчанию АРМ Администратора создает только базовый словарь.
Что не понравилось:
1. при запуске естественно-тематического классификатора БД в списке индексов забит только один индекс. Объясните, пожалуйста, эта область должна заполняться, например, ГРНТИ? Если так, то почему в деме индекс только один? Яркой демы не получается. Поиск не яркий, только по ключевым словам, что не дает нормальных результатов. Хотелось бы видеть именно качество выделения тематики текста.

2. сразу после установки и индексации базы пытаюсь манипулировать с ПОС, но при нажатии на любую кнопку для его создания выдается Access Violation. При следующем запуске (когда я уже поискал в Читателе) ошибок не было.

3. Я, конечно, понимаю, что Visual HCA - инструмент для профессионала, но было бы не плохо иметь все-таки какой-то мастер создания ПОС с рекомендациями и подсказками по ходу создания словаря.

Панев Максим писал(а):

> Попробовал тестовые полнотекстовый модуль. Я так понимаю, по
> умолчанию АРМ Администратора создает только базовый словарь.
> Что не понравилось:
> 1. при запуске естественно-тематического классификатора БД в
> списке индексов забит только один индекс. Объясните,
> пожалуйста, эта область должна заполняться, например, ГРНТИ?
> Если так, то почему в деме индекс только один? Яркой демы не
> получается. Поиск не яркий, только по ключевым словам, что не
> дает нормальных результатов. Хотелось бы видеть именно качество
> выделения тематики текста.
Какой иной поиск, кроме поиска по КЛЮЧЕВЫМ СЛОВАМ, возможен по произвольным неструктурированным текстам, не прошедшим НИКАКОЙ предварительной обработки (в т.ч. систематизации)??? Как можно искать по ГРНТИ, УДК, ББК и пр. тексты, которые не отрубрицированы по этим классификаторам??? Надеюсь, что никаких иллюзий относительно АВТОМАТИЧЕСКОЙ РУБРИКАЦИИ по этим классификаторам ни у кого нет...
Что касается естественно-тематической классификации и ПОС - то она пока служит ТОЛЬКО для поиска похожих текстов. Автоматически создать эту систему (т.е. тематические индексы) пока не представляется возможным (думаю, что, строго говоря, и не представится) Для этого и нужна работа эксперта (который проводит своего рода обучение системы), которая ОПИСАНА в соответствующей инструкции - увы, чудес на свете не бывает...

>
> 2. сразу после установки и индексации базы пытаюсь
> манипулировать с ПОС, но при нажатии на любую кнопку для его
> создания выдается Access Violation. При следующем запуске
> (когда я уже поискал в Читателе) ошибок не было.
>
> 3. Я, конечно, понимаю, что Visual HCA - инструмент для
> профессионала, но было бы не плохо иметь все-таки какой-то
> мастер создания ПОС с рекомендациями и подсказками по ходу
> создания словаря.

"не прошедшим НИКАКОЙ предварительной обработки" - так про это и речь. А почему только для поиска похожих? Ведь если в тексте выделены ТЕМАТИЧЕСКИЕ ключевые слова, то это уже более менее тематический поиск. Так почему бы не сделать так: если ПОС уже созданы для каждого текста, то сначала проводить поиск по этим словарям.
Или я не так понимаю смысл ПОС? Он вообще создается для каждого документа, или для всех документов в базе подразумевая, что они имеют общую тематику?
Хотя стоп. Кажется понял :). Словарь один, а термины ссылаются на документы, как в обычном словаре.
Ну если так, тогда для этого и существует VHCA, не так ли. То есть он служит для объединения всех документов в базе в некие логические группы по похожим тематикам. Хотя это и есть автоклассификация :).
Так почему бы тогда не формировать на основе базового словаря словарь ненормированных ключевых слов. С помощью все той же VHCA выделить в каждом тексте тематические ключевые слова, заполнить ими поле в записи "ненормированные ключевые слова" и на основе уже этого поля создать тематический словарь. Мне так кажется, что поиск по нему будет немного эффективнее. Или я не прав?

"...Надеюсь, что никаких иллюзий относительно АВТОМАТИЧЕСКОЙ РУБРИКАЦИИ по этим классификаторам ни у кого нет..." если вы имеете ввиду полностью авторубрикацию, то конечно, таких иллюзий нет. Но ведь новинка в том и заключается, что есть полуавтоклассификация.

Извиняюсь за спам :)... почитал документацию по созданию ПОС и еще раз укрепился во мнении, что пользоватся VHCA может ТОЛЬКО Константин Олегович :).
Я не понимаю, ведь в домументации все расписано четко по шагам, нет никаких отклонений от схемы. Почему не написать мастера, чтобы не запутаться во всем разнообразии функций. Единственное, что нужно переделать - это интерфейс. Мне кажется, что перенос алгоритнов - не такая уж и сложная задача.
Ну если ответ на мою просьбу "нет", то хотелось бы хотябы схематично видеть, что за чем надо нажимать, а то сложно по тексту ориентироваться :)

А полнотектовый читатель файл-серверный чтоли?

То есть Александр Иосифович согласился с тем, что ИРБИС не обладает искусственным разумом, потому что «чудес на свете не бывает» и что такого вообще не будет никогда.
Итак, «полуавтоклассификация» должна состоять из трех этапов, из которых 1-й и 3-й —«ручные», «человеческие»:
1. человек-эксперт «проводит своего рода обучение системы»
2. система создает «черновик» (то есть собственно «полуавтоклассификация»)
3. человек-систематизатор доводит результат п. 2 до ума.
Тогда, может быть, более перспективное направление — это продолжение работы над сопоставлением разных классификаций, наподобие уже сделаного в отношении УДК и ГРНТИ с целью формирования индексов одной класссификации из индексов другой классификации (или предметных рубрик на основе классификации). Получается опять «полуавтосистематизация», а в результате ее — опять «черновик».

Напрашивается идея ввести «поиск похожих», но не полных текстов, а библиографических описаний в АРМах «Каталогизатор» и «Читатель» (в дополнение к «поиску по связи»). Это может пригодиться, например, при создании новой записи путем копирования и редактирования «похожей», при составлении библиографических списков.

«Система рекомендуется к примененению […] при формировании программ больших конференций, при создании пользовательских, в том числе образовательных БД, как аналитическое ядро при создании поисковых серверов Интернет».
(из рекламы Visual HCA)
Очень хотелось бы узнать о примерах такого ее использования.

И еще хотелось бы узнать: есть ли у кого-нибудь опыт «нетривиального» (или «небиблиотечного») применения полнотекстового модуля? Например: учебный процесс (в т. ч. дистанционное образование), документооборот, …

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