Turtle >> Turtle Search System Query Language

Turtle Search System Query Language -- TSSQL/1.0

Статус этого документа.
Этот документ описывает внутренний для компании Stack Technologies Ltd. стандарт реализации разбора поисковых запросов. Документ предназначен для служебного использования. Этот документ может и должен являться предметом обсуждения, с внесением изменений. Соблюдение согласованного стандарта всеми сотрудниками, занятыми в разработке поисковой системы обязательно.
Copyright Notice

Copyright © Stack Technologies Ltd. (2001). All Rights Reserved.

Содержание.

1. Введение.

1.1 Назначение.
1.2 Термины и понятия.

2. Синтаксис запросов.

2.1 Служебные слова запросов.

2.1.1 Группировка '(' ')'.
2.1.2 Пересечение лексем '&'.
2.1.3 Объединение лексем '|'.
2.1.4 Исключение лексем '!'.
2.1.5 Точное соответствие запросу '""'.
2.1.6 Поиск в пределах фразы '\'.
2.1.7 Изменение относительного веса термина '^'.
2.1.8 Расширение поисковых терминов.
2.1.9 Поиск в частях документа.
2.1.10 Поиск перекрестных ссылок.
2.1.11 Отсутствие операторов между поисковыми терминами.
2.1.12 Хранение лексем в базе данных.
2.1.13 Поиск похожих документов.

3. Примеры поисковых запросов.
4. Заключение.

1. Введение.
В процессе работы с поисковой системой конечный пользователь имеет несколько интерфейсов взаимодействия с ней. Одним из способов задания различных параметров поиска является форма расширенного поиска с различными полями, которая в данном документе не рассматривается. В данном документе рассматривается способ взаимодействия пользователя с поисковой системой с помощью языка запросов, который должен интерпретироваться и пользователем и программами поисковой системы одинаково. Т.к. "Turtle" является полнотекстовой системой поиска неструктурированных (или слабо структурированных) текстов, стандартные языки запросов типа SQL не могут удовлетворить весь спектр потребностей описания возможного поискового запроса подобной системы.
1.1 Назначение.
Назначение языка запросов состоит в том, чтобы в удобной форме дать возможность конечным пользователям поисковой системы точно указать сферу интересов поискового запроса пользователя. В общем случае поисковый запрос может иметь весьма сложную структуру и сочетать в себе множество логических операций над промежуточными результатами по отдельным поисковым критериям. Язык запросов в поисковой системе по умолчанию считается выключенным и включается только продвинутым пользователем поисковой системы с помощью радиокнопки в форме простого поиска. При этом сама поисковая система подразумевает, что запрос составлен именно продвинутым пользователем и сужает область оптимизации данного типа запросов.
1.2 Термины и понятия.

Поисковый термин (лексема)
Понятие лексемы с точки зрения поисковой системы отличается от лингвистического определения лексемы. Лексемой будем называть последовательность символов, которая интерпретируется поисковой системой как единица информации документа. Эта последовательность символов является и единицей поиска в поисковой системе. В текущей реализации лексемой считается набор символов общей длиной, не превышающий некий предел, устанавливаемый в программном обеспечении конфигурационно (по умолчанию 32 символа). Этот набор символов может содержать символы isalnum() и любые символы с кодами, превышающими 0x7f. Кроме того, в список разрешенных символов, входящих в состав лексемы вносятся следующие символы и соответствующие им шестнадцатеричные коды:

Код символа Графическое представление

0x23 #

0x24 $

0x25 %

0x26 &

0x27 '

0x7e ~

0x2b +

0x2d -

0x2e .

0x2f /

0x3a :

0x3d =

0x3f ?

0x40 @

0x5f _

При этом считается, что в лексеме не могут дважды встречаться следующие символы:

Код символа Графическое представление

0x7e ~

0x23 #

0x40 @

0x24 $

0x27 '

Считается, что из этого расширенного набора символов на первой или на последней позиции могут находиться только isalnum() символы или символы, коды которых превышают 0x7f, а также символы:

Код символа Графическое представление

0x7e ~

0x23 #

0x2b +

0x2d -

0x5f _

0x2f /

0x24 $

0x27 '

Считается также, что последовательность не isalnum() символов с кодами меньше чем 0x80 в лексеме не может превышать 2-х символов за исключением случая :// используемого в обозначении URL ресурсов.
Считается, что в лексеме должен быть хотя бы один isalnum() символ или хотя бы один символ с кодом больше чем 0x7f/

Сублексема
Если лексема содержит специально оговоренные выше символы, то она может быть разбита на сублексемы. В состав сублексемы могут входить только isalnum() символы и сымволы, коды которых превышают 0x7f.

Фраза текста
Последовательность лексем в plain тексте документа, не разделенных знаками препинания. Разделителями фраз считаются следующие символы и соответствующие им шестнадцатеричные коды:

Код символа Графическое представление

0x3c <

0x3e >

0x3f ?

0x2c ,

0x2e .

0x2f /

0x3a :

0x22 "

0x3b ;

0x7b {

0x7d }

0x5b [

0x5d ]

0x3d =

0x2d -

0x28 (

0x29 )

0x21 !

Некоторые из этих символов могут входить в состав лексем (как это указано выше). Разделителями фраз они считаются тогда и только тогда, когда они не входят в состав лексемы.

Мажор лексемы
Порядковый номер фразы (начиная с 0) в тексте документа, в состав которой входит данная лексема. Считается, что на практике этот номер не может превышать значения 0xffff.

Минор лексемы
Порядковый номер лексемы внутри фразы (начиная с 0). Совокупность мажора лексемы и минора лексемы составляют полную координатную информацию о лексеме. Считается, что на практике этот номер не может превышать 0xff.

Служебное слово.
Зарезервированная последовательность символов, не входящая в определение лексемы и имеющая специальное назначение, обычно подразумевающее некий набор действий над лексемами. В поисковом индексе не может содержаться служебных слов и любое служебное слово не может являться лексемой текста.

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

Текстовый парсер
Подпрограмма разбора текста документа на лексемы с присвоением мажора и минора каждой лексеме текста для их дальнейшей индексации. Текстовый парсер не анализирует исходный текст документа на предмет наличия в нем служебных слов т.к. служебные слова не входят в правила описания лексем.

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

2. Синтаксис запросов.
Синтаксис запросов составляет совокупность лексем и служебных слов, однозначно определяющая последовательность действий над поисковыми терминами запроса. Подразумевается, что программа, использующая парсер запросов, не пытается оптимизировать запрос по последовательности выполнения действий, а только пытается оценить скорость выполнения этих действий и сообщает QP о возможном увеличении максимального времени ожидания выполнения данного поискового запроса. При этом QP должен попытаться уменьшить количество используемых данных путем уменьшения количества корзин (если это возможно) и увеличить ожидаемый барьер выполнения запроса до полученной величины. Критический барьер выполнения запроса по времени должен быть установлен QP на удвоенном уровне. По истечению этого критического интервала QP будет считать, что запрос не выполнен и должен передать на верхний уровень сообщение об ошибке в выполнении данного запроса.
2.1 Служебные слова запросов.
Ниже приводится перечень зарезервированных служебных слов для обозначения действий и их последовательности над лексемами.
2.1.1 Группировка '(' ')'.
Порядок выполнения действий, в общем случае, определяется согласно таблице приоритетов, которая выглядит так (см. описание SSAL):

Операция Усл. обозначение Приоритет Порядок выполнения

FILT {..┘} 0 слева на право

EXP * 1 справа на лево

CND "..." 2 слева на право

MUL ^ 3 справа на лево

AND & 4 слева на право

PND \N 5 слева на право

OR | 6 слева на право

POR - 7 слева на право

XOR % 8 слева на право

NOT ! 9 слева на право

Группировка с помощью скобок может изменить его, т.е. круглые скобки "(" и ")" имеют наивысший приоритет.
Пример: (test | word) & job
В данном примере при отсутствии скобок последовательность должна была бы быть следующей: 1) word & job; 2) результат выполнения (1) | test. Наличие скобок поменяло порядок действий на: 1) test | word; 2) результат выполнения (1) & job
Так как символы "(" и ")" не входят в набор допустимых символов в лексеме, то их отделение от лексем с помощью символов space (пробел) не обязательно, однако не является ошибкой. Количество открывающих скобок всегда должно быть равным количеству закрывающих скобок. Не выполнение этого требования считается синтаксической ошибкой.
2.1.2 Пересечение лексем '&'.
Служебное слово '&' обозначает, что над данными операнда, предшествующего этому оператору, и данными операнда, следующего за этим оператором, следует произвести операцию логического пересечения данных. Суть операции заключается в выборке данных каждого из операндов только таких данных по ID документов, которые встречаются в обеих выборках. Т.к. символ '&' может входить в состав лексемы, то оператором он считается тогда и только тогда, когда обособлен от других выражений символами space (пробел). При выполнении выборки данных результатов операции соответствующие весовые коэффициенты результатов являются суммой весовых коэффициентов соответствующих операндов.
Пример: a & b & c & d
Функция пересечения является коммутативной, т.е. a & b равно b & a Логический оператор '&' не может быть первым в поисковом запросе, ему всегда должна предшествовать поисковая лексема.
2.1.3 Объединение лексем '|'.
Служебное слово '|' обозначает, что над данными операнда, предшествующего этому оператору и данными операнда, следующего за этим оператором, следует произвести операцию логического объединения данных. Суть операции заключается в выборке данных каждого из операндов всех уникальных данных по ID документов, которые встречаются как в первой выборке, так и во второй. Символ '|' не может входить в состав лексемы, тем не менее, для целостности синтаксиса оператором он считается тогда и только тогда, когда обособлен от других выражений символами space. В противном случае символ игнорируется. При выполнении выборки данных результатов операции соответствующие весовые коэффициенты результатов являются суммой весовых коэффициентов соответствующих операндов.
Пример: a | b | c | d
Функция объединения является коммутативной, т.е. a | b равно b | a Логический оператор '|' не может быть первым в поисковом запросе, ему всегда должна предшествовать поисковая лексема.
2.1.4 Исключение лексем '!'.
Служебное слово '!' обозначает, что над данными операнда, предшествующего этому оператору, и данными операнда, следующего за этим оператором, следует произвести операцию логического исключения данных. Суть операции заключается в выборке данных каждого из операндов всех уникальных данных по ID документов, которые встречаются в первой выборке, но отсутствуют во второй. Символ '!' не может входить в состав лексемы, тем не менее, для целостности синтаксиса оператором он считается тогда и только тогда, когда обособлен от других выражений символами space. В противном случае символ игнорируется. При выполнении выборки данных результатов операции соответствующие весовые коэффициенты результатов являются копией весовых коэффициентов, отобранных из первой выборки.
Пример: a ! b ! c ! d
Функция объединения не является коммутативной т.е. a ! b не равно b ! a Логический оператор '!' не может быть первым в поисковом запросе, ему всегда должна предшествовать поисковая лексема.
2.1.5 Точное соответствие запросу '""'.
Поисковый запрос может подразумевать нахождение ID документов, содержащих точный фрагмент текста, лексемы именно в указанном порядке, следующие друг за другом. Для реализации подобной элементарной операции на процессоре поиска реализована команда CND (см. описание SSAL/1.0). В поисковом запросе последовательность действий с операндами CND определяется открытием и закрытием двойных кавычек '"'. Все операнды, заключенные между двойными кавычками последовательно подвергаются операции координатного пересечения CND с лева на право. Внутри текста запроса, ограниченного двойными кавычками не может находиться ни каких логических операторов над словами. Если таковые имеются, то они обязаны игнорироваться парсером запросов.
Пример: "deep purple group"
Операция точного соответствия не является коммутативной и не поддается искусственной оптимизации. Следом за символом двойных кавычек могут сразу идти операнды, использование пробелов следом за двойными кавычками не является ошибкой и игнорируется разборщиком запроса. Количество открывающих двойных кавычек в запросе всегда равно количеству закрывающих двойных кавычек. Запрос, не соблюдающий данные требования, считается синтаксически не верным и не подлежит исполнению. Для любой последовательности лексем запроса на точное соответствие справедливо утверждение, что в пределах найденного документа все лексемы будут иметь один и тот же мажор, и их миноры будут отличаться на единицу друг от друга слева на право.
2.1.6 Поиск в пределах фразы '\'.
Логическим продолжением операции пересечения лексем является пересечение с координатными условиями. В качестве координатных условий может быть использован критерий максимального расстояния между искомыми лексемами. Такая операция обозначается служебным словом '\', отделенным слева и справа от операндов символами space. Следом за символом '\' может следовать число, характеризующее максимальное расстояние между терминами в интервале от 1 до 255. Справедливо утверждение, что результатом элементарной операции будут являться ID документов, у которых искомые лексемы имеют один и тот же мажор, и их миноры будут отличаться не более чем на указанную в запросе величину. Если после символа '\' отсутствует число, то оно полагается равным максимально возможному (255).
Пример: deep \4 purple
Оператор '\' не может являться первым в поисковом запросе и должен находится между операндами. Оператор не является коммутативным, т.е. a \ b не равно b \ a. Выражение a \ b подразумевает, что слово 'a' должно предшествовать в искомом тексте слову 'b'.
2.1.7 Изменение относительного веса термина '^'.
Пользователь поисковой системы может определить наиболее важные в процессе поиска для него термины путем их изменения веса. Это производится с помощью оператора '^'. Следом за оператором может следовать число в float представлении со знаком или без знака. Числа меньшие 1, характеризуют уменьшение веса термина в запросе. Данный оператор может являться первым в запросе и выполняется справа налево. Он имеет второй по значимости приоритет. Выражение: ^1.5 a & b не является эквивалентным выражению: ^1.5 (a & b).
2.1.8 Расширение поисковых терминов.
Существует два типа расширений поисковых терминов:

Расширение лексем, содержащих сублексемы
Расширение лексем согласно синтаксису.

Расширение поисковых терминов может применяться только для отдельного термина (лексемы) и только один раз. Запись типа: *a* считается синтаксической ошибкой.
Если поисковая лексема содержит сублексемы (например, www.turtle.ru), то парсер запроса обязан привести такую лексему к следующей поисковой конструкции:
www.turtle.ru | www & turtle & ru
Т.к. приоритет '&' является более высоким, чем '|' - употребление скобок не обязательно, но мы должны осознавать, что это является не чем иным как:
(www & turtle & ru) | www.turtle.ru.
Поисковая лексема может также быть расширена согласно синтаксису запроса на морфологические формы или на формы с произвольным окончанием слова. Для этого существуют следующие операторы языка запросов:
'*' - следующая непосредственно за поисковым термином обозначает произвольное окончание термина.
'*' - предшествующая поисковому термину обозначает его морфологическое расширение на формы. Номер, следующий за '*' в фигурных скобках, или текстовое обозначение языка в фигурных скобках (см. ниже) определяет код языка расширения согласно конфигурационной таблице. Если номер языка расширения или имя языка отсутствует, то подразумевается любой язык морфологии (все формы слова во всех языках). Синтаксис подразумевает отсутствие space (символов пробел) в данном типе конструкции.
Коды языков и их обозначение:
english    none 0x01    английский      ru_RU.WINDOWS-1251
german     none 0x02    немецкий        de_DE.ISO_8859-1
french     none 0x03    французский     fr_FR.ISO_8859-1
italian    none 0x04    итальянский     it_IT.ISO_8859-1
spanish    none 0x05    испанский       es_ES.ISO_8859-1
russian    none 0x06    русский         ru_RU.WINDOWS-1251
bulgarian  none 0x07    болгарский      ru_RU.WINDOWS-1251
brazilian  none 0x08    бразильский     pt_PT.ISO_8859-1
swedish    none 0x09    шведский        sv_SE.ISO_8859-1
norwegian  none 0x0a    норвежский      no_NO.ISO_8859-1
ukrainian  none 0x0b    украинский      ru_SU.WINDOWS-1251
danish     none 0x0c    датский         da_DK.ISO_8859-1
portugues  none 0x0d    португальский   pt_PT.ISO_8859-1
finnish    none 0x0e    финский         fi_FI.ISO_8859-1
esperanto  none 0x0f    эсперанто       ru_RU.WINDOWS-1251
afrikaan   none 0x10    африканский     ru_RU.WINDOWS-1251
czech      none 0x11    чешский         cs_CZ.ISO_8859-2
dutch      none 0x12    голландский     nl_NL.ISO_8859-1
hebrew     none 0x13    иврит           ru_RU.WINDOWS-1251
polish     none 0x14    польский        pl_PL.ISO_8859-2
slovenian  none 0x15    словенский      sl_SI.ISO_8859-2
slovak     none 0x16    словацкий       sl_SI.ISO_8859-2
indonesian none 0x17    индонезийский   ru_RU.WINDOWS-1251
romanian   none 0x18    румынский       ru_RU.WINDOWS-1251
mat        none 0xff    ненормативный   ru_RU.WINDOWS-1251
Примеры:
	test*
	*test
	*{6}проверка
	*{portugues}test
В первом случае имеет место примерно следующее преобразование (согласно базе данных SP): test* равно (test | test1 | testing | test_123┘.) Количество разворачиваемых форм произвольного окончания определяется с помощью параметра на QP, сами возможные формы слов будут извлечены на SP.
Во втором случае: *test равно (test | tests | testing |┘.) согласно морфологической базе QP для текущего базового языка.
В третьем случае слово проверка будет расширено до всех его морфологических форм в русском языке (проверка | проверок | проверки...).
2.1.9 Поиск в частях документа.
Синтаксис поискового запроса может непосредственно указать на фильтр для конкретного поискового термина или группы терминов. Ограничением области нахождения поисковых терминов являются зарезервированные слова, помещенные в фигурные скобки:

{TITLE}
поисковые термины должны находиться в пределах заголовка документа
{HEADER}
поисковые термины должны находится в пределах HTML тэгов <H1>.┘.<H6>
{MARK}
поисковые термины обязаны находиться в пределах разметки HTML тэгами <B>,<I>,<U>,<STRONG> и т.д.
{ESSENCE}
поисковые термины должны находиться в начале документа в пределах первых 512 байт документа.
{REF}
поисковые термины должны входить в состав ссылки документа
{IMAGE}
поисковые термины должны входить в состав ссылки на image.
{VIDEO}
поисковые термины должны входить в состав на видео ссылку.
{AUDIO}
поисковые термины должны входить в состав на аудио ссылку.
Указанные термины могут применяться единожды и только к операнду. Это связано с текущей реализацией настройки фильтров при чтении записи. Возможно в последующих версиях будет пересмотрено с соответствующими внесениями в данную спецификацию.
Текстовое обозначение, обрамленное символами '{' и '}' не зависит от регистра символов.
2.1.10 Поиск перекрестных ссылок.
Поиск перекрестных ссылок, согласно текущей версии языка запросов TSSQL не может производиться в сочетании с описанными выше операторами. Смешение операторов поиска перекрестных ссылок с другими операторами поиска является ошибкой, и такие запросы не обрабатываются.
Для обозначения поиска документов, которые ссылаются на данный документ, используется конструкция служебного слова {LINK} и лексемы, которая определяет URL документа для поиска ссылок. Для обозначения поиска документов, на которые ссылается данный документ, используется служебное слово {HREF} и следом за ним лексема, определяющая имя URL.
При поиске линков и ссылок на весь сервер в качестве лексемы должно быть определено имя сервера в этих же запросах, а соответствующие служебные слова выглядят как {SRVLINK} и {SRVHREFF}.
Пример:
{LINK} http://www.turtle.ru
{SRVHREFF} www.turtle.ru
Текстовое обозначение, обрамленное символами '{' и '}' не зависит от регистра символов.
2.1.11 Отсутствие операторов между терминами.
Отсутствие операторов между поисковыми терминами (лексемами) не является синтаксической ошибкой. К таким операндам применяется правило использования оператора по умолчанию. Оператором по умолчанию считается логическое пересечение терминов '&', если иное не оговорено интерфейсной поисковой формой, в которой вводится поисковый запрос.
2.1.12 Хранение лексем в базе данных.
В базе данных все поисковые термины (лексемы) хранятся приведенные к нижнему регистру, поэтому парсер запроса должен рассматривать поисковые запросы типа "test", "Test", "TEST" как идентичные и приводить по возможности лексемы запроса к нижнему регистру. Для не английских слов способ приведения к нижнему регистру определяется установленным по умолчанию значением locale, который может быть определен через форму запроса при необходимости. Русские термины хранятся в базе данных поисковой системы в WINDOWS-1251 кодировке. Морфологический модуль русского, украинского и болгарского языков (см. Turtle MMM/1.0) также работают в этой кодировке.
2.1.13 Поиск похожих документов.
Поиск похожих документов по базе в языке запросов обозначается служебным словом {SIMILAR}. При этом, запрос не может содержать других конструкций языка. Аргумент, следующий за таким служебным словом, определяет URL документа для поиска.
Пример:

{SIMILAR} /some_doc.html
3. Примеры поисковых запросов.
Приведем еще несколько примеров комплексных запросов с использованием языка запросов:
(beatles | quin) & {TITLE} group
По данному запросу будут отобраны все документы, содержащие в тексте слова "beatles" или "queen" и не содержащие в заголовке документа слово "group".
boney M | sunny ! song
По данному запросу будут отобраны документы, содержащие в произвольной последовательности на произвольном расстоянии друг от друга слова "boney" и "m" или содержащие слово "sunny" вне зависимости от того имеются ли в документе слова "boney" и "m". Результирующая выборка документов не будет содержать в текстах документов слов "song", ни при каких условиях.
4. Заключение.
В общем случае, предложенный язык запросов может удовлетворить практически любым возможным пожеланиям для выполнения полнотекстового поиска по коллекции документов. Недостатком использования языка запросов является невозможность оптимизации запроса системой для более эффективного и быстрого его исполнения. Поэтому, подразумевается, что языком запросов пользуются продвинутые пользователи поисковой системы, которые хорошо представляют механизмы поиска. По умолчанию в интерфейсной форме запроса язык запросов должен быть выключен и включается самим пользователем по его желанию.

Черепаший Ранк. Реклама на Turtle Логотипы Правовая информация Конфиденциальность Контакты

Код символа	Графическое представление

0x23	#
0x24	$
0x25	%
0x26	&
0x27	'
0x7e	~
0x2b	+
0x2d	-
0x2e	.
0x2f	/
0x3a	:
0x3d	=
0x3f	?
0x40	@
0x5f	_

Код символа	Графическое представление

0x3c	<
0x3e	>
0x3f	?
0x2c	,
0x2e	.
0x2f	/
0x3a	:
0x22	"
0x3b	;
0x7b	{
0x7d	}
0x5b	[
0x5d	]
0x3d	=
0x2d	-
0x28	(
0x29	)
0x21	!

Операция	Усл. обозначение	Приоритет	Порядок выполнения

FILT	{..┘}	0	слева на право
EXP	*	1	справа на лево
CND	"..."	2	слева на право
MUL	^	3	справа на лево
AND	&	4	слева на право
PND	\N	5	слева на право
OR	\|	6	слева на право
POR	-	7	слева на право
XOR	%	8	слева на право
NOT	!	9	слева на право