Уважаемые разработчики и коллеги!
Давно думаю над вопросом: зачем из состава Авторитетного файла вместе с заголовком рубрики (имени лица и т.п.) в каталогизационную запись вставляется MFN авторитетной записи?

Если в составе АФ произойдет смещение заисей, то изменятся и MFN. Введенные с разными MFN в каталогизационную запись поисковые термины (например, персоналии) при поиске в ЭК по словарю встанут параллельно друг другу как разные термины, что и неаккуратно и реально мешает поиску.
При этом ведь ИРБИС ищет не по MFN - поисковая процедура (при последовательном поиске, поиске для умников) происходит путем сличения поисковых терминов.

В практике ведения авторитетных файлов (тех же персоналий) и при ИРБИС 32 и при ИРБИС 64 несколько лет назад у меня бывало при заполнении поля 510 машина автоматом создавала 100 дублетов. Были и другие сюрпризы. - Все это говорит о том, что как бы мы ни береглись, 100%-й гарантии неизменности MFN нет (хотя в последние годы все работает надежно).

В практике ведения авторитетных файлов поле "Идентификатор записи" - рассматривается как обязательное см. например, http://www.rusmarc.ru/auth/index.html (хотя его функция мне не понятна).

Вероятно этот идентификато чем-то похож по задачам на генератор случайных чисел в 903 поле базы каталога.

В связи с этим вопрос, какова функция MFN авторитетных данных в составе базы каталога? Для меня пока очевидна только одна функция - видеть, откуда каталогизатор взял запись - из авторитетного файла или сам ввел с клавиатуры.

Иван Евгеньевич написал(а):
-------------------------------------------------------
> Уважаемые разработчики и коллеги!
> Давно думаю над вопросом: зачем из состава
> Авторитетного файла вместе с заголовком рубрики
> (имени лица и т.п.) в каталогизационную запись
> вставляется MFN авторитетной записи?
> ....
> В связи с этим вопрос, какова функция MFN
> авторитетных данных в составе базы каталога? Для
> меня пока очевидна только одна функция - видеть,
> откуда каталогизатор взял запись - из
> авторитетного файла или сам ввел с клавиатуры.

Да, именно так. Никакой другой функции MFN не несет

Благодарю Вас!
Может ли ИРБИС игнорировать разницу в MFN у одной и той же персоналии (рубрики), не создавая параллельных рядов при поиске по словарю? Может это можно заложить в число базовых функций в будущей версии ИРБИС (актуальность вопроса относительная, но это было бы желательно!)?

Вопрос этот поднимался со времен начала 2000 годов. Проблема в том, что для построения псевдослучайного кода записи в формате авторитетных записей не хватает полей из набора обязательных, чтобы создать уникальную последовательность символов для кода записи.
Если же сделать эту идентификационную последовательность "совсем случайную", то тогда встает большой вопрос в применимости для создания сводных каталогов.
В авторитетной базе данных MedArt - "Медики России" применяется частное решение, но оно не входит в состав БД ATHRA.
В файле autoin.gbl поле 903 формируется по такому алгоритму:

ADD
903
XXXXXXXXXXXXXXXXXXX
if a(v903) then if p(v1) then v1 else if &unifor('+D'):'ATHRA' then 'A' else if unifor('+D'):'ATHRC' then 'C' else if unifor('+D'):'ATHRS' then 'S' fi fi fi, &unifor('T0'if v210^a*5.1<>'' then v210^a.6 else if v210^a*4.1<>'' then v210^a"_" else if v210^a*3.1<>'' then v210^a"__" else if v210^a*3.1<>'' then v210^a"___" else if v210^a*1.1<>'' then v210^a"____" fi fi fi fi fi),&unifor('T0'if v210^g*3.1<>'' then v210^g.4 else if v210^g*2.1<>'' then v210^g"_" else if v210^g*1.1<>'' then v210^g"__" else '____' fi fi fi),&unifor('T0'if v210^g*0.1<>'' then v210^g.1 else '_'fi), &unifor('3'), '63480700' fi fi
XXXXXXXXXXXXXXXXXXX

и ссылка между базами идет по этому коду в 903 поле.

В словаре каждой авторитетной БД строится "свертка", по которой проводится сверка на дублетность внутри БД.
В БД ATHRS по такой "свертке" идет связь откорректированной рубрики в ATHRS с предметными рубриками в БД ЭК при автоматической корректировке последних.
В принципе эти свертки можно было бы записывать в запись ЭК, но тогда должна работать технология корректировки этого идентификатора при корректировке соответствующих данных в авторитетной БД с переносом его (корректировкой) в запись ЭК - технология достаточно громоздкая и поэтому не реализована