Тема занятия: Глобальные вербальные ипс: изучение и поиск

Методика выполнения

1. Провести поиск по теме «Компьютерная лингвистика» в заданных глобальных ИПС (набор систем и их количество может меняться по усмотрению преподавателя). Поисковое предписание логически должно выглядеть следующим образом:

(computational V computing V computer) & linguistics.

Запрос задать по-английски дважды, как конъюнкцию и как устойчивое словосочетание (фраза), используя характерные для каждой системы способы выражения операторов (для незнакомых систем найти соответствующую справочную информацию). Первую веб-страницу с результатами каждого поиска сохранить в своей папке в виде «только html». Количественные результаты отразить в таблице:

 

№ п/п	Название ИПС	Найдено документов/сайтов	Комментарий (если требуется)
Запрос как конъюнкция	Запрос как устойчивое словосочетание
	AlltheWeb (Fast)
	AltaVista
	Google
	MSN Search
	Teoma
	WiseNut
	Yahoo

2. Проанализировать и попытаться объяснить полученные объемы выдачи в каждой системе.

3. В трех системах (Яндекс, Рамблер, Google) провести поиск по теме «Компьютерная лингвистика». Поисковое предписание, соответствующее логической формуле «(компьютерная V вычислительная) & лингвистика» (дизъюнкция устойчивых словосочетаний «компьютерная лингвистика» и «вычислительная лингвистика»), задать по-русски, используя характерные для каждой системы способы выражения операторов. Обратить внимание на различия в морфологической нормализации в разных системах. Первую веб-страницу с результатами каждого поиска сохранить в своей папке в виде «только html». Количественные результаты отразить в файле отчета в виде таблицы.

4. Провести поиск по той же теме, сузив область поиска заданием дополнительных терминов, позволяющих отобрать документы, где наиболее вероятны определения данного термина (учебник, курс лекций, определение, называется и т.п.). Количество найденных документов указать в файле отчета. Туда же через буфер обмена скопировать поисковые предписания по каждой системе.

5. Просмотреть в каждой системе найденные документы, найти в них по одному определению термина «компьютерная лингвистика» и записать их в файл отчета с указанием адреса (URL) соответствующего документа.

6. Предъявить работу преподавателю.

 

Основная литература:

1. Ивашко, А. Г. Информационные системы и технологии: учебное пособие/ А. Г. Ивашко, Ю. Е. Карякин; Тюм. гос. ун-т. - Тюмень: Изд-во ТюмГУ, 2013.

2. Плещев, В. В. Разработка и стандартизация программных средств, информационных технологий и систем: организация, методология, метрология, качество, CASE-средства: учеб. пособие/ В. В. Плещев. - Тюмень: Изд-во ТюмГУ, 2011.

 

Дополнительная литература:

3. Романенко, А. Г. Информационно-поисковые системы: учеб. пособие/ А. Г. Романенко, О. Ф. Самойлюк. - Москва: Изд-во РГГУ, 1997. - 85 с

4. Барская, Г. Б. Интернет в маркетинге: учеб. пособие/ Г. Б. Барская, Ю. В. Бидуля; Тюм. гос. ун-т. - 2-е изд., доп. и перераб.. - Тюмень: Изд-во ТюмГУ, 2010. - 236 с.

5. Кряжева, М. Ф. Информационный поиск: общетеоретические аспекты/ М. Ф. Кряжева. - Тюмень: Вектор Бук, 2004. - 84 с.

 

План практического занятия 17

Тема занятия: Корпоративные сети библиотек. Протокол Z39.50

Время: 6 час

Вопросы:

1. Корпоративные и национальные библиотечные сети, их роль в создании информационного пространства.

2. Определение прав доступа в сети. Формат передачи данных: назначение, виды.

3. Протокол Z39.50 как средство организации доступа к ресурсам корпоративных сетей.

Методика выполнения

Теоретические сведения

Автоматизация библиотечных процессов, создание электронных каталогов и использование коммуникативного формата обмена библиографическими данными привело к расширению информационного пространства библиотек. Перспективным направлением стала тесная кооперация в различных сферах библиотечной деятельности: обмен опытом, создание и предоставление электронных ресурсов, кооперация в области информационного взаимодействия. Нельзя сказать, что обмен информацией и документами – новое начинание библиотек, но развитие компьютерных сетевых технологий позволило перевести это на новые рельсы.

Библиотеки объединяются между собой в различные сети по различным видам деятельности:

Автоматизация библиотечных процессов, создание электронных каталогов и использование коммуникативного формата обмена библиографическими данными привело к расширению информационного пространства библиотек. Перспективным направлением стала тесная кооперация в различных сферах библиотечной деятельности: обмен опытом, создание и предоставление электронных ресурсов, кооперация в области информационного взаимодействия. Нельзя сказать, что обмен информацией и документами – новое начинание библиотек, но развитие компьютерных сетевых технологий позволило перевести это на новые рельсы.

Библиотеки объединяются между собой в различные сети по различным видам деятельности:

В области каталогизации:

· локальная каталогизация и локальный ЭК;

· локальная каталогизация и распределённый ЭК;

· централизованная каталогизация и сводный (централизованный) ЭК;

· распределённая каталогизация и сводный (централизованный) ЭК.

В области справочно-библиографического обслуживания:

· удалённый доступ к ЭК для пользователей;

· электронная доставка документов (ЭДД);

· виртуальная справка;

· полнотекстовые электронные библиотеки.

В области методической деятельности:

· методические консультации через форумы и сайты;

· обмен методическими разработками через сеть (сценарии, иллюстративный материал, рекомендации).

При этом работа по каталогизации может также объединяться по разным признакам. По территориальному признаку:

· региональные – сводные и/или распределённые ЭК библиотек городов, областей, регионов;

· межрегиональные – сводные и/или распределённые ЭК библиотек различных городов, областей, регионов;

· национальные – сводный каталог библиотек России (проект ЛИБНЕТ);

· международные – сводный мировой каталог произведений печати и рукописных документов (например, на базе OCLC).

По содержанию:

· универсальные – сводные и/или распределённые каталоги, отражающие все виды документов любой тематики;

· межотраслевые – сводные и/или распределённые каталоги, отражающие все виды документов определённого тематического направления;

· отраслевые (ведомственные) – сводный и/или распределённый ЭК библиотек вузов, музеев, медицинских учреждений и т.д.;

· видовые – сводные и/или распределённые каталоги, посвящённые конкретному виду изданий (например, карты, картины и пр.).

В России на сегодняшний день в национальном масштабе реализуются несколько проектов корпоративной каталогизации:

СИГЛА (www.sigla.ru) – международный проект научной библиотеки МГУ и компании БКС

Российский информационно-библиотечный консорциум (РИБК, www.ribk.net)

Ассоциация региональных библиотечных консорциумов (АРБИКОН, www.arbicon.ru)

2. Основные положения Z39.50

Технология сетевого доступа к базам данных по протоколу Z39.50 существенно отличается от других технологий. Отличие обусловлено самой сутью протокола: ориентация на работу с базами данных, абстрагирование от конкретных систем, жесткая регламентация структуры пересылаемых данных [7].

В основе Z39.50 (здесь и ниже см. описание стандарта [6]) лежит идея построения абстрактной модели работы с абстрактной базой данных. Каждый элемент этой абстрактной модели подробно описывается до однозначного толкования и стандартизуется с присвоением уникального идентификатора – OID. Работа с каждой конкретной СУБД согласно Z39.50 должна быть организована только через эту абстрактную модель путем обмена пакетами данных (APDU), содержащими последовательности идентифицируемых по меткам объектов. В стандарте описаны следующие классы объектов (OID Z39.50 = 1.2.840.10003):

Контекст приложения (context)		{OID 1.2.840.10003.1 = Z39.50 1}
APDU		{OID Z39.50 2}
Аттрибуты (attributeSet)		{OID Z39.50 3}
Диагностика (diagnostic)		{OID Z39.50 4}
Структура записей (recordSyntax)		{OID Z39.50 5}
Синтаксис преобразований (transferSyntax)		{OID Z39.50 6}
Отчета по ресурсам (resourceReport)		{OID Z39.50 7}
Контроль доступа (accessControl)		{OID Z39.50 8}
Расширенный сервис (extendedService)		{OID Z39.50 9}
Пользовательская информация (userInfoFormat)	{OID Z39.50 10}
Элементы (elementSpec)		{OID Z39.50 11}
Варианты (variantSet)		{OID Z39.50 12}
Схема данных (schema)		{OID Z39.50 13}
Схема меток (tagSet)		{OID Z39.50 14}

Внутри класса объекты идентифицируются номерами, дабавляемыми к классовому номеру. Например, в классе recordSyntax {Z39.50 5} объекты имеют OID: Unimarc {Z39.50 5 1}, USmarc {Z39.50 5 10}, SUTRS {Z39.50 5 101} и т.п.

Согласно стандарту Z39.50 взаимодействие клиента (origin) и сервера (target) начинается посылкой клиентом серверу APDU InitializeRequest и приемом от него APDU InitializeResponse. При этом стороны согласовывают между собой версию протокола, максимальные размеры записей, допустимые команды и другие параметры. В момент инициализации может быть проведена аутентификация пользователя. За успешной инициализацией следует открытие сеанса, который может быть закрыт получением одной из сторон APDU close. В течение сеанса происходит обмен APDU, инициатором которых выступает клиент. Основные APDU следующие:

APDU	Request	Response	Функция
Search	X	X	Поиск, создание рабочего набора данных
Present	X	X	Извлечение записей из рабочего набора данных
DeleteResultSet	X	X	Удаление рабочего набора данных
Scan	X	X	Просмотр словаря базы данных
Sort	X	X	Сортировка рабочего набора данных
Segment	X		Сегментация записей
ExtendedServices	X	X	Расширенный сервис - вставка, удаление и модификация записей в базе данных

Поиск: синтаксис запросов и наборы атрибутов

Команда Search формируется с указанием списка баз данных и собственно запроса. Среди множества типов запросов, указанных в стандарте, обязательным для поддержки сервером Z39.50 является запрос типа 1 (RPNquery – запрос в обратной польской нотации). RPNquery – последовательность опрераторов и операндов. В качестве операндов могут использоваться: RPNquery, набор данных (resultSet) или комбинация атрибутов и поискового терма. Существенно, что в качестве атрибутов можно использовать только их номера по выбранному стандартному набору атрибутов, имеющему свой OID. Наиболее распространен набор атрибутов Bib-1 {OID Z39.50 3 1}, включающий 99 поисковых (Use) атрибутов (author, title, DatePublication и т.п.) и пять типов уточняющих атрибутов (Relation, Position, Structure, Truncation, Completeness). Примером развернутового в строку RPN-запроса может быть запрос на поиск записей, в которых автор начинается на «Кузн» и встречается в любой позиции поля:

@attr 1=1003 @attr 2=3 @attr 3=3 @attr 5=1 {Кузн}

где по Bib-1 @attr 1=1003 - соответсвует author, @attr 2=3 – равно, @attr 3=3 – любая позиция в поле, @attr 5=1 – усечение справа, Кузн – поисковый термин. Естественно, серверу передается не строка запроса, а древовидная RPN-структура, упакованная согласно спецификациям ASN.1-BER в APDU SearchRequest для передачи по сети.

Такая организация системы запросов позволяет с одной стороны однозначно отобразить логику запроса, абстрагируясь от синтаксиса запроса конкретной СУБД, а с другой - абстрагироваться от поисковых полей конкретной базы данных, так как запрос формулируется всегда в терминах абстрактного набора атрибутов, например, Bib-1. Кроме Bib-1, ориентированного на работу с библиографическими базами данных, сегодня стандартизованы и другие наборы атрибутов, например, STAS – 2000 атрибутов для научно-технической информации, GEO – 2000 атрибутов для геоинформационных систем и т.д.

Запросы RPN (Type-1) – не единственно допустимый тип запросов в Z39.50. Стандарт 1995 года (версия 3) допускает запросы Type-0 – запросы в синтаксисе конкретной СУБД, запросы Type-2 – запросы в синтаксисе Common Command Language (CCL – ISO 8777) и др. В настоящее время ведется обсуждение включения в Z39.50 запросов в синтаксисе SQL [8].

Извлечение данных: схемы, форматы, элементы, варианты

В результате описанной выше процедуры найденные записи сохраняются в рабочих наборах данных на стороне сервера и могут быть использованы в течение сеанса для уточнения поиска и извлечения по команде Present. Эта команда возвращает затребованное количество записей клиенту в необходимом формате внешнего представления. Форматы представления стандартизованы в классе RecordSyntax {Z39.50 5} и включают MARC-форматы ISO-2709 (Unimarc, Usmarc, CCF, SBN и т.д.), неструктурированный текстовый формат SUTRS, структурированные теговые форматы (GRS-1, Summary), специальные форматы (HTML, XML, PDF, TIFF, GIF) и другие. Структурированные форматы позволяют после передачи по сети полностью сохранить первоначальную структуру записи, в отличие от других протоколов (http,ftp и др.), что является немаловажным в распределенных системах.

Поскольку извлекаемые записи могут иметь значительную длину и их поля (элементы) могут иметь существенно различный тип данных, стандартом предусмотрена возможность извлечения ограниченного списка полей из записи. Список полей, допускающих одновременное присутствие во внешнем представлении записи, называется «набором элементов» (elementSet). Минимально допустимы два набора элементов – Full (F) и Brief (B).

Идеология максимального абстрагирования от структур реальных баз данных приводит к весьма изощренной схеме извлечения данных, описанной в стандарте Z39.50: записи из результирующих наборов отображаются в записи абстрактной базы данных через схему, определяющую абстрактную структуру записи в виде дерева элементов, специфицируемых метками (tag) из стандартных наборов (tagSet); затребованные элементы выбираются в нужной альтернативной форме (variant) из абстрактной записи и отображаются в экспортируемую структуру, определяемую форматом внешнего представления (recordSyntax). Все объекты описанной процедуры (schema, tagSet, elementSpec, variantSet, recordSyntax) определены в соответствующих классах с присваением OID.

Служебная и конфигурационная информация

Стандартом Z39.50 v.3 предусмотрена специальная база данных IR-Explain-1, в которой сервер может хранить информацию о своей конфигурации, базах данных, атрибутах, форматах и других поддерживаемых им объектах (всего 17 категорий):

TargetInfo	RecordSyntaxInfo	AttributeDetails	Processing
DatabaseInfo	AttributeSetInfo	TermListDetails	CategoryList
Schemainfo	TermListInfo	ElementSetDetails	VariantSetInfo
TagSetInfo	ExtendedServicesInfo	RetrievalRecordDetails	UnitInfo
		SortDetails

К этой базе метаданных клиент должен обращаться с запросами RPN по атрибутам Exp-1 {Z39.50 3 2} и получать записи в структурированном формате Explain {Z39.50 5 100}, не запрещается дополнительно поддерживать другие форматы записей Explain (SUTRS, GRS-1). Поддержка (необязательная) сервером Z39.50 базы данных Explain позволяет клиентам дополнительно настраиваться на его конфигурацию. Это важная возможность при построении графических рабочих мест клиента Z39.50 с развитой системой самонастраивающихся меню.