Идеология системы DSpace такова, что пользователь либо получит именно тот файл/документ/описание, которые он должен получить, либо не получит ничего, вернее, получит сообщение об ошибке.
Допустим, если в системе был зарегистрирован какой-нибудь документ и ему был присвоен handle, но потом документ был удален, handle не освобождается и навсегда остается пустым. Это делается для того, чтобы по неактуальному PURL не были получены неактуальные сведения.
По большому счету, вопроса о том как правильно оформлять ссылку на документ быть не может, система сама ОДНОЗНАЧНО об этом сообщает:
Но в сети, да и в «бумажных» источниках описания такого типа:
Проблемы пожарной безопасности: пути их решения и совершенствование противопожарной защиты [Электронный ресурс] : материалы всероссийской научно-практической конференции с международным участием. – Екатеринбург: ФГАОУ ВПО «УрФУ имени первого Президента России Б.Н.Ельцина», 2012. – 163 с. – Режим доступа: http://elar.urfu.ru/handle/10995/4053
соседствуют с такими:
Черепанова, Е. С. Педагогика толерантности [Электронный ресурс] : прогр. повышения квалификации / Е. С. Черепанова ; Урал. гос. ун-т им. А. М. Горького. — Режим доступа: http://elar.urfu.ru/bitstream/10995/1533/4/1332204_program.pdf. — (Дата обращения: 26.09.2012).
Показательно, что ссылка http://elar.urfu.ru/bitstream/10995/1533/4/1332204_program.pdf не открывается, хотя ресурс http://elar.urfu.ru/handle/10995/1533/ никуда не делся и файл 1332204_program.pdf никуда не делся.
Что это, излишняя бдительность системы, не верное её использование (несколько файлов в одном handle), не верное библиографическое описание или сочетание этих вариантов — вопрос, выходящий за рамки данной заметки.
Важно то, что путь до конкретного файла изменится если файл перезагрузить (допустим, удалить оригинал и загрузить исправленную версию), если экспортировать и затем импортировать запись, коллекцию, раздел, если при определенных обстоятельствах совершить миграцию фонда или развернуть резервную копию. С точки зрения системы файл «уже не тот». Он либо изменен сам, либо изменены метаданные (время загрузки, учетная запись, под которой была совершена загрузка и пр.) и этого достаточно чтобы считать файл новым и сделать его недоступным по старой ссылке, что мы и видим на примере файла 1332204_program.pdf и его библиографического описания. Это с точки зрения системы правильно, с точки зрения пользователя не удобно, а с точки зрения администратора — вовсе катастрофа. По сути, администратор становится заложником поисковых систем, которые индексируют всё подряд, авторов не точных описаний, которые ссылаются на файл, а не на PURL и пр. и все свои действия администратор архива должен планировать так, чтобы не получить кучу битых ссылок на свой ресурс. Это дискредитирует и ресурс в частности и идею электронного архива в целом, хотя, с точки зрения системы всё в порядке. Файл «изменился», значит по старой ссылке он не доступен.
Особенно печален тот факт, что система толком ничего пользователю в случае клика по «битой» ссылке не сообщает. Всё что видит пользователь, это буквально следующее:
На мой взгляд, этого не достаточно. Да, я знаю что если взять строку http://elar.urfu.ru/bitstream/10995/19688/2/text.pdf, да заменить в ней bitstream на handle, да убрать всё до предпоследнего слэша, то быть может, получится тот самый PURL — http://elar.urfu.ru/handle/10995/19688/, но не все, кликающие по ссылкам в недостоверных описаниях это знают, а текст:
Идентификатор 10995/19688/2/text.pdf не соответствует правильному Поток битов архива электронных ресурсов. Это могло произойти по одной из следующих причин:
— URL текущей страницы неверен. Если Вы попали сюда извне архива электронных ресурсов, то, возможно, адрес набран неправильно или поврежден.
— Вы ввели недопустимый ID в форму — пожалуйста, повторите попытку.Если у Вас возникли проблемы или Вы считаете, что ID должен работать, то свяжитесь с администраторами сайта.
Мягко говоря не намекает на то, как получить PURL из «битой» ссылки.
Для разрешения данной несправедливости было придумно такое решение — файл invalid-id.jsp, находящийся в директории error сервлета JSPUI был модифицирован следующим образом:
В маркированный список был добавлен следующий код:
Более читаемая версия:
В результате получается следующая «модификация» сообщения об ошибке:
Ссылка в первом пункте списка ведет на PURL который получается посредством работы простого javascript скрипта. В принципе, этот код можно переписать и на java, более уместном для JSPUI, но я JAVA не знаю.
[UPD]
Предлагаю обновленный вариант скрипта, который «понимает» где была ошибка handle, а где bitstream:
var a = window.location.href;
var b = window.location.host;
var result = a.match(/(\d+\/\d+)\/(.+)/);
if (result !== null)
{
document.write("\u0424\u0430\u0439\u043B \u043D\u0435 \u043D\u0430\u0439\u0434\u0435\u043D. \u0412\u043E\u0441\u043F\u043E\u043B\u044C\u0437\u0443\u0439\u0442\u0435\u0441\u044C <a href='http://" + b + "/handle/" + result[1]+"' alt='handle'>\u0441\u0442\u0440\u0430\u043D\u0438\u0446\u0435\u0439 \u043E\u043F\u0438\u0441\u0430\u043D\u0438\u044F</a> \u0434\u043B\u044F \u043F\u043E\u0438\u0441\u043A\u0430.");
}
else
{
document.write("\u0420\u0430\u0437\u0434\u0435\u043B \u0438\u043B\u0438 \u043A\u043E\u043B\u043B\u0435\u043A\u0446\u0438\u044F \u043D\u0435 \u043D\u0430\u0439\u0434\u0435\u044B. \u041F\u043E\u0436\u0430\u043B\u0443\u0439\u0441\u0442\u0430 \u043F\u0435\u0440\u0435\u0439\u0434\u0438\u0442\u0435 \u043A <a href='http://" + b + "/community-list' alt='community-list'>\u0441\u043F\u0438\u0441\u043A\u0443 \u0440\u0430\u0437\u0434\u0435\u043B\u043E\u0432</a>.");
}
</script>
Ну и читаемый вариант:
var a = window.location.href;
var b = window.location.host;
var result = a.match(/(\d+\/\d+)\/(.+)/);
if (result !== null)
{
document.write("Файл не найден. Воспользуйтесь <a href='http://" + b + "/handle/" + result[1]+"' alt='handle'>страницей описания</a> для поиска.");
}
else
{
document.write("Раздел или коллекция не найдеы. Пожалуйста перейдите к <a href='http://" + b + "/community-list' alt='community-list'>списку разделов</a>.");
}
</script>