Здравствуйте.

Я сейчас конвертирую БД из марка больше 60000 записей.
Потом их надо откорректировать глобальной корректировкой.
Потом создать словари.

Вот сижу я и жду пока закончится первый этап, чтобы перейти ко второму (запустить его вручную) и т. д.

А нет ли в ирбисе такой возможности, чтобы задать набор команд (например, в bat-файле) и оставить сервак ночью пахать. Все три этапа вполне уложатся в одну ночь. А то ведь не приятно сидеть и караулить.

Дмитрий.

Конечно, есть - это пакетные задания (*.ibf)

Вопрос к Дмитрию. Марк - это MARK 4 или просто формат исходных записей MARC? Мне это интересно очень-очень. Просто я из этого самого марка тоже конверчу и есть некоторые проблемы.

> Конечно, есть - это пакетные задания (*.ibf)
Нашел. Спасибо.
А как быть с глобальной корректировкой. Необходимо откорректировать БД после импорта из марка (uspm.fst)?


>Марк - это MARK 4
Он самый.
mailto:dmitriy@library.kamensktel.ru

Единственное, что нельзя делать с помощью пакетных заданий - это проводить ГК, что ОЧЕНЬ не удобно. У меня сейчас читатели каждый день из другой базы конвертяца, после мне надо ГК проводить (или чтоб при импорте autoin.gbl выполнялся). У меня только импорт и создание словаря автоматически. Но словарь без ГК не так уж и актуален. ОЧЕНЬ не удобно. Что по этому поводу думают остальные?



Отправка отредактированного (16-04-04 12:41)

г. Ярославль

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

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

В моем-то случае можно и на входе получить желаемый результат, а вот в случае марка...

А что в Марке данные с другой планеты? Формат стандартный, люди тоже не сильно отличаются, т.е. данные аналогичны. В результате, все може сконвертить :)

Дело в том, что в марке нет средств экспорта. Конвертится исходная база. По этому обработка должна происходить на стороне Ирбиса.

Так я про ИРБИС и говорил. Пишется свой файл smarci.fst только для МАРКа. На время импорта подменяется, а потом ставится стандартный ИРБИСовский.

Так веть трабл-то не в этом совсем, а вом, что автоматически нельзя выполнять ГК при конвертировании.

Так я и не понял, зачем ее выполнять? Вы же можете те же самые функции прописать и в fst файл. Вы же пишете только один раз на перенос данные для своего же формата, а не для среднего "гипотетического", для которого потом и написана ГК. И как я понял, все это нужно сделать красиво, но один раз.

С одной стороны, я согласен с Караушем. Надо сделать smarci.fst так, чтобы после конвертирования не пришлось выполнять ГК. Сложно, но можно.

С другой стороны, включить ГК в пакетное задание всетаки надо. Пример из моей жизни. Составил я пару месяцев назад *.gbl для корректирования "Типичных ошибок" библиографов (не всех, и тех, которые поддаются корректировке средствами ирбиса): пробелы двойные убрать, вставить недостающие Еденицы измерения местоположения статьи, заменить № на N, заменить запятую на запятую с пробелом и т.п. У нас 18 шт. БД. И для всех в целях профилактики надо было выполнить ГК. Это было бы более удобно делать с помощью пакетного задания ночью.

А вообще вопрос философский. Купили мы ирбис, заплатили кучу денег, и вдруг выясняется, что для конвертирования из марка в ирбис надо использовать сначала smarci.fst, а потом uspm.gbl. Почему разработчики сами не сделали нормальный smarci.fst. Почему каждый, кому надо заниматься конвертированием из марка, должен сам объединять smarci.fst и uspm.gbl (разве-что допускается незначительные изменения .fst под особенности библиотеки).
Безобразие.
Вот и приходится выбирать между тщательным переписыванием smarci.fst и использованием сначала smarci.fst (незначительно откорректированного), а потом uspm.gbl. Второй способ легче и предпочтительнее, что приводит нас опять к необходимости наличия ГК в пакетном задании.

Дмитрий.

Проблемы в рамках страны такие, что у каждого пользователя свои "тараканы" в базе. Каждый каталогизатор делает такие "плюхи", что в пору большинство этих "профессионалов" списывать к внукам.
Типичные (систематические) ошибки у каждой библиотеки свои и зависят от кучи факторов. Мы их пытались в рамках дипломной работы в 2001 году систематизировать, чтобы посмотреть, есть ли общие ошибки. Взяли библиотек 20: из Москвы, городов Золотого кольца, Сибири, Урала и пр. И выяснилось, что ГК неприменима, поскольку в одном случае она правит, а в другом "калечит" данные. Особенно это касается вопросов выходных данных описаний статей. И сейчас у меня более 10 конверторов из формата RUSMARC для многих библиотек, поскольку в каждой библиотеке свой RUSMARC :)
А ГК я не использую по причине нецелесообразности, долгое это дело. Проще один раз переписать конвертор и отказаться от такого "страшного" и опасного блока, как ГК. На моей памяти столько неудачных ГК, даже от людей, пребывающих в сознании, что я совсем не люблю данную штуку в руках каталогизаторов.

Вопрос такой - а почему бы авторам МАРКа не сделать конвертор в стандартный UNIMARC или аля-MARC (какой-либо) формат? Иногда мне хочется сказать, что когда кто-то выбирает программу, то он должен думать на 10 лет вперед, чтобы потом не оказаться с потерями данных. Спросите, кто покупал для Вашей библиотеки МАРК? Подойдите к нему и скажите: "Спасибо!". Он все сделал правильно для того, чтобы Вас сейчас обеспечить работой в наше неспокойное время :)



Отправка отредактированного (18-04-04 06:03)

{ У нас ирбис, а не марк (см. выше) }

1. Я не собираюсь писать универсальный *.fst.

2. У точните пожалуйста, вы хотите сказать, что все БД идеальны и в корректировке не нуждаются?

>1. Я не собираюсь писать универсальный *.fst.
Про универсальный конвертор никто и не писал.

>2. У точните пожалуйста, вы хотите сказать, что все БД идеальны и в корректировке не нуждаются?
Наоборот, нет баз, даже сделанных по стандрату, которые бы этому стандарту удовлетворяли в полной мере. Особенно от DOS-программ.

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



Отправка отредактированного (19-04-04 10:24)

г. Ярославль

Да ни про то я писал!
1. Записи в системе МАРК - одноуровневые (плоские).
2. В каждой конкретной БД ошибки статичные. Т.е. если в БД не ставили пробела между инициалами, а их ставить нужно, то это везде по всей базе.

И, соответственно, можно это дело сделать в fst-файле. Я же не писал, что писать один конвертер на все случаи и для всех форматов. А только для конкретных данных в конкретной БД под конкретную корректировку.