Ret: Z39. 50 Извлечение записей (Не- норматив)



Скачать 436.69 Kb.
страница1/3
Дата19.01.2013
Размер436.69 Kb.
ТипДокументы
  1   2   3




Приложение 14
RET: Z39.50 Извлечение записей
(Не- норматив)
Поиск и извлечение записей - это две основных функции стандарта Z39.50. Под поиском понимается отбор записей в базе данных на основе критериев указанных источником, и создание адресатом множества результатов, представляющего собой [множество] отобранных записей. Образно говоря, под извлечением записей понимается передача множества результатов адресатом источнику.
Настоящее приложение описывает извлечение и таким образом предполагает наличие множества результатов. Для простоты предположим, что множеств результатов содержит всего одну запись (хотя Z39.50. позволяет источнику запрашивать различные варианты множеств результатов). Настоящее приложение сосредоточивает внимание на возможностях, предоставляемых стандартом Z39.50. для извлечения [и представления] данной записи.
RET.1 Обзор [функции] извлечения Z39.50

Хотя извлечение неформально считается передачей записей множества результатов, логически множество результатов не содержит записей. Скорее, оно содержит логические единицы (items) (иногда называемые “ответами”), и каждая из этих единиц включает ссылку (указатель - pointer) на запись базы данных (термин “записи множества результатов” является идиоматическим выражением, означающим “записи базы данных, представленные единицей множества результатов”)
Более того, запись базы данных, так как она рассматривается стандартом Z39.50. представляет собой исключительно локальную структуру данных. Вообще стандарт Z39.50. не передает записей базы данных (то есть адресат не передает информацию в ее физическом представлении в базе данных), и стандарт Z39.50. не [предполагает] передачи всей информации, содержащейся в определенной базе данных, передаваться может лишь подмножеств этой информации.
Таким образом более точный смысл [выражения] “передача записей множества результатов” таков: [это есть -] передача некоторого подмножества [элементов] информации из записи базы данных (представленного единицами данного множества результатов) в соответствии с некоторым указанным форматом. Эта перемещаемая структура, приспособленная для переноса, и называется извлеченной записью. (Несколько запросов на извлечение данной записи могут иметь в качестве результата несколько извлеченных записей, существенно отличающихся как по структуре , так и по содержанию).
[Функции] извлечения стандарта Z39.50.
поддерживают следующие возможности:
Источник может запросить определенные логические элементы информации из записи (через спецификацию элементов, описанную ниже)
Источник и адресат могут иметь общую область номинации (name space) для помет элементов (посредством схемы и множества помет, описанных ниже), так что элементы точно идентифицируются источником, в списке элементов и адресатом в извлеченной записи.
Источник может указать, как элементы в комплексе должны сочетаться в извлеченной записи (посредством синтаксиса, описанного ниже).

Соответственно извлечение в стандарте Z39.50. имеет четыре первичные функции:
Отбор элементов (см. примечание)

Маркирование элементов

Представление элементов

Представление записей
Примечание: отбор элементов относится к извлечению, его не следует смешивать с отбором записей, который относится к поиску. Отбор элементов представляет собой отбор элементов информации в уже отобранной записи базы данных.
RET.2 Извлечение классов объектов
Настоящий раздел RET.2 описывает классы объектов используемые функциями извлечения. RET.3 приводит детальные определения тех объектов, которые определяются настоящим стандартом.
Спецификации элементов (elementSpecs) см. RET.2.1
tagSets (множества помет), см. RET.2.1
определения схем, см. RET.2.2
Спецификацию вариантов (variantSpecs), см. RET.2.3;
а также
синтаксис записей см. RET.2.4.
RET.3 приводит детальные определения тех объектов, которые определяются настоящим стандартом.
Ниже приводится краткий перечень классов объектов
[Спецификация элементов] (elementSpec) присутствует в запросе на Представление стандарта Z39.50. и используется в первую очередь для отбора. В самом общем виде elementSpec запрос на определенные элементы (множество запросов на элементы (elementRequests )
[Множество помет] tagSet определяет множество элементов и указывает имена и рекомендуемые типы данных (datatypes) для отдельных элементов в пределах данного множества. Имя элемента называется его пометой и может использоваться изолированно (в запросе на элементы -elementRequest) или в сопровождении именуемого элемента (в извлеченной записи)
Схема определяет абстрактную структуру записи (см. RET.2.2 ). Определение схемы относится к одному или более множеству помет.
Хотя спецификация элементов (elementSpec) используется в первую очередь для множества, она может иметь и аспект представления: каждый запрос на элемент может включать запрос на вариант ( variantRequest ), который в первую очередь используется для представления элементов, чтобы указать определенную форму элемента , например, как элемент должен форматироваться. (Однако, запрос на вариант может содержать ограничение отбора: он может запрашивать определенную часть или фрагмент элемента)
Запрос на вариант - один из трех возможных видов использования спецификации вариантов (variantSpec):
Запрос на вариант это спецификация вариантов существующая в пределах одной записи
Применяемый вариант (appliedVariant) это спецификация примененная к элементу адресатом, когда этот элемент включен в найденную запись.
Адресат может предоставить список спецификаций вариантов поддерживаемый для определенного элемента, каждая спецификация обозначается поддерживаемый вариант (supportedVariant.)
Синтаксис записи, примененный адресатом к множеству элементов, отбирается спецификацией элементов (и возможно трансформируется примененными вариантами) в результате образуется извлеченная запись.
Вывод:
Спецификация элементов используется (в первую очередь) для отбора элементов
Запрос на вариант используется для представления элемента
Синтаксис записи используется для представления записи
Множество помет используется для маркирования элементов как в пределах спецификации элементов (для отбора элементов), так и [при применении} синтаксиса записи (для представления записи) .
Схема определяет абстрактную структуру записи
RET.2.1 Особенности спецификации элементов и множества помет
Спецификация элементов (An elementSpec) может быть включена в запрос на представление [для того, чтобы] указать какие элементы должны быть включены в извлеченную запись. Например, источник может выразить желание, чтобы извлеченная запись состояла из двух элементов:-“автор” и “заглавие”. Спецификация элементов может выразить это двумя способами.

Может быть определено имя множества документов (примитивное имя), например 'authorTitle', что означает “представить автора и заглавие”
Может быть использована динамическая спецификация, позволяющая источнику динамически отбирать желаемые элементы.
Использование имени множества элементов имеет существенное ограничение: должно быть определено такое имя , которое учитывало бы любую возможную комбинацию элементов в запросе.
Для версии 2 стандарта Z39.50., допускается только примитивная форма, спецификация элементов (elementSpec ) должна представлять собой имя множества элементов (тип ASN.1 которого - VisibleString). Версия 3 позволяет альтернативно использовать в спецификации элементов тип EXTERNAL, внешний (обращающийся, следовательно, к внешнему определению, которое может быть описано в ASN.1, хотя это и не обязательно). Далее в примерах ASN.1 с нарастающей сложностью показаны отдельные возможности, которые могут быть поддержаны с помощью спецификации элементов (elementSpec)
RET.2.1.1. Простые числовые пометы
Простая спецификация документов может быть представлена как список элементов. Определение спецификации может быть таким:
ESpec ::= SEQUENCE OF ElementRequest (последовательность запроса на элементы)

ElementRequest ::= INTEGER (целое число)
В данном примере каждый запрашиваемый элемент представлен целым числом. Предполагается, что источник и адресат используют одно и то же определение - tagSet (множество помет) - которое присваивает элементам [определенные] целые числа [в качестве помет]. Целое число является именем или пометой элемента. В данном примере tagSet (множество помет) может присвоить число 1 элементу “заглавие” и число 2 - элементу “автор”

RET.2.1.2 Строковые пометы
Ограничивать пометы элементов целыми числами не всегда желательно. В некоторых случаях полезно использование строковых помет. В таких случаях запрос на элемент принимает чуть более сложную форму:
ElementRequest ::= StringOrNumeric (Строковый или числовой)

Заметим, что StringOrNumeric - это тип [пометы], определяемый и экспортируемый в рамках стандарта Z39.50 APDU следующим образом:
StringOrNumeric ::= CHOICE (выбор){

numeric (числовой) [1] IMPLICIT INTEGER (по умолчанию - целое число),

string (строка ) [2] IMPLICIT InternationalString (по умолчанию - международная строка)}

в этом случае, в множестве помет (tagSet) может быть объявлено что “автор также может обозначаться строкой “author”, а заглавие строкой “title”.
RET.2.1.3 Типы помет
Иногда необходимо (или удобно) запрашивать такие элементы, пометы которых не принадлежат к одному множеству помет. Такая возможность дает важное преимущество, предоставляя пространство для множественных номинаций помет, так что определения их множеств могут осуществляться независимо [друг от друга]. Требуется все же, чтобы пометы имели ссылки на [определенные] множества.

Определение схемы (см.Ret 2.2) может присвоить целое число для идентификации множества помет (tagSet) ([данное] множество определяется только в пределах контекста определения схемы). Идентификатор множества (tagSet) называется типом пометы (tagType). Отметим, что определение множества помет (tagSet) есть зарегистрированный объект и потому имеющий устойчивый идентификатор объекта. Тип пометы (tagType) целым числом используется как краткий идентификатор.
Продолжая приведенный выше пример представления типов помет (tagTypes), запрос на элемент может быть определен следующим образом:
ElementRequest (запрос на элемент) ::= SEQUENCE (последовательность){

tagType (вид пометы) [1] IMPLICIT INTEGER (по умолчанию - целое число),

tagValue (значение пометы) [2] StringOrNumeric (строковое или числовое)}
RET.2.1.4 Присутствие пометы
Запись в базе данных часто содержит повторяющиеся элементы. Источник может пожелать чтобы данный элемент присутствовал Т раз (например, “четвертый образ”). Для того чтобы ввести условие повторяемости в приведенный выше пример, запрос на элемент может быть определен следующим образом:
ElementRequest (запрос на элемент) ::= SEQUENCE (последовательность){

tagType(тип пометы) [1] IMPLICIT(по умолчанию)

INTEGER OPTIONAL (целое число, факультативно),

tagValue (значение пометы) [2] StringOrNumeric (строковое или числовое),

tagOccurrence(присутствие пометы) [3] IMPLICIT INTEGER(по умолчанию целое число)}
RET.2.1.5 Пути помет
Запись в базе данных не обязательно является простым набором элементов, она может иметь иерархическую или древовидную структуру ([в последнем случае] информация содержится в “листьях” и “узелках”). Источник может запросить, например, “четвертый абзац третьего раздела второй главы первой книги” (“книга”, “глава”, “раздел”, “абзац” могут иметь пометы). Данный пример вводит понятие пути помет (TagPath), который представляет собой гнездовую последовательность помет (в пределах этой последовательности каждая помета характеризуется типом и присутствием). Путь пометы (TagPath) может быть реализован заменой первой линии ASN.1 в первом примере:
ElementRequest (запрос на элемент) ::= TagPath (путь пометы)

TagPath (путь пометы)::= SEQUENCE OF SEQUENCE (последовательность последовательности){
RET.2.1.6 Запрос на вариант
Наконец, источник может пожелать ввести в запрос на элемент запрос на вариант (variantRequest) чтобы указать вид документа (напр. PostScript), язык, графику, форматирование (напр. длину строки), или фрагмент.
Espec(спецификация элементов) ::= SEQUENCE OF ElementRequest (последовательность запроса на элементы)

ElementRequest (запрос на элементы)::= SEQUENCE(последовательность){

TagPath(путь пометы),

VariantRequest OPTIONAL(запрос на вариант, факультативно)}
В данном случае путь пометы (TagPath) определяется как в предыдущем примере. Варианты описаны в разделе RET.2.3
RET.2.2 Схема и абстрактная структура записи
Схема базы данных представляет собой одинаковую у источника и адресата интерпретацию информации записи в той базе данных, которую описывает схема. Основным компонентом схемы является абстрактная структура записи - ARS. Она перечисляет элементы в терминах путей их помет (tagPaths) и предоставляет информацию, связанную с каждым элементом, учитывая его обязательность, повторяемость, а также приводит определение элемента. (описывается при этом и иерархия элементов в пределах записи, см. RET.2.2.5.)
Абстрактная структура записи ( ARS) определяется в терминах одного или более множества помет. В схеме может быть определено множество помет, она может обращаться к ранее определенному множеству. В простом примере абстрактной структуры записи (ARS), который приведен ниже, примем, что было определено следующее множество помет.
Tag (помета) Element(элемент) Recommended dataType (рекомендованный тип данных)

1 title (заглавие) InternationalString (международная строка)

7 name (имя) InternationalString (международная строка)

16 date (дата) GeneralizedTime (обобщенное время)

18 score (отсчет) INTEGER (целое число)

14 recordId (идентификатор записи) InternationalString (международная строка)

<locally

defined string

tag(локально определенная строковая помета)> objectElement (элемент объекта) InternationalString (международная строка)or

OCTET STRING (октетная строка)
В следующем примере абстрактной структуры записи (ARS) каждый “элемент схемы” относится к элементу из приведенного выше множества помет.
В данном примере, схема указывает, что данному элементу объекта (objectElement) адресат должен присвоить некоторую описательную строковую помету. Например, если элемент является “отпечатками пальцев”, помета может быть 'fingerPrintFile' (в этом случае содержание элемента “имя”, помета 7, может идентифицировать лицо, являющееся субъектом отпечатков пальцев). Поскольку это единственный элемент в абстрактной структуре записи, имеющий строковую помету, источник распознает его в качестве объектного элемента.
Abstract Record Structure (абстрактная структура записи)
Schema Manda- Repeat-

Element tory? able? Definition
(Схема Обяза- Повторяю-

Элемент тельное? щееся?)
title yes no A set of words that conveys the main idea of the record.

Заглавие да нет Набор слов, передающих основную идею записи
name no yes One or more individuals associated with the ob­ject element; it could, for example, be an auth­or or an organization.

Имя нет да Один или более знаков, ассоциированных с объектным элементом, это может быть, например, автор или организация.
date no no A date associated with the record.

Дата нет нет Дата ассоциированная с записью
score no no Represents the numerical score of the record based on its relevance to the query.

Степень нет нет Представляет числовой уровень записи, рассчитывающийся по ее релевантности запросу
recordId no no An identifier of the record unique within the target system.

Идентификатор
записи нет нет Идентификатор записи уникальный в системе адресата
object

объект

Element yes no Contains object informa­tion for the record. It may be text, image, etc.

Элемент да нет Содержит информацию об объекте для записи. Это может быть текст, изображение.
  1   2   3

Похожие:

Ret: Z39. 50 Извлечение записей (Не- норматив) iconПриложение 15 pro: Z39. 50 Профили
В настоящем приложении перечисляются профили Z39. 50, одобренные Семинаром по созданию среды открытых систем, специальной группой...
Ret: Z39. 50 Извлечение записей (Не- норматив) iconAnsi/niso z39. 50-1995 Information Retrieval: Application Service Definition and Protocol Specification
Это предисловие не является формальной частью американского государственного стандарта ansi/niso z39. 50-1995 и включено исключительно...
Ret: Z39. 50 Извлечение записей (Не- норматив) iconИзвлечение рения из шлиф-отходов
Исследовано извлечение рения из шлиф-отходов, содержащих более 40 никеля, кобальт и 1,2 рения. Предложена технология, включающая...
Ret: Z39. 50 Извлечение записей (Не- норматив) iconНорматив стоимости кв м. для расчета субсидий бюджетникам
Государственный комитет «Единый тарифный орган Челябинской области» установил норматив стоимости квадратного метра общей площади...
Ret: Z39. 50 Извлечение записей (Не- норматив) iconКак отключить Контроль учетных записей в Windows Vista и что такое Контроль учетных записей?
Я привык работать в Windows xp, после перехода на Windows Vista столкнулся с проблемой: при любой попытке открыть приложение, Vista...
Ret: Z39. 50 Извлечение записей (Не- норматив) iconПеречень изменений в ас умс версии 13. 01 от 02. 07. 2012 г
При выделении нескольких записей разрешено автоматическое последовательное удаление каждой из них посредством нажатия кнопки «Удалить»....
Ret: Z39. 50 Извлечение записей (Не- норматив) iconМетод расчета государственного регистрационного номера гцб в форме записей на счетах
Государственный регистрационный номер гцб в форме записей на счетах, выпущенной Правительством Республики Молдова в лице Министерства...
Ret: Z39. 50 Извлечение записей (Не- норматив) iconУрок математики, проведённый в 1 классе. Тема урока: «Слагаемые. Сумма. Использование этих терминов при чтении записей»
Цель урока: познакомить с терминами «слагаемое», «сумма», учить использовать их при чтении записей
Ret: Z39. 50 Извлечение записей (Не- норматив) iconАдминистративно-территориального деления узловского района тульской области в границах муниципального образования
Архив актовых записей, находящихся на хранении в отделе загс администрации муниципального образования Узловский район, представляет...
Ret: Z39. 50 Извлечение записей (Не- норматив) iconЗагсы в Риге и Латвии Отделения записей актов гражданского состояния загс
Отделения записей актов гражданского состояния загс dzimtsarakstu nodalas производят регистрацию рождения, заключение и расторжение...
Разместите кнопку на своём сайте:
ru.convdocs.org


База данных защищена авторским правом ©ru.convdocs.org 2016
обратиться к администрации
ru.convdocs.org