Dspace, дополнительный реестр метаданных и ошибки статистики.

Рано или поздно многие пользователи системы DSpace сталкиваются с нехваткой возможностей стандартного реестра метаданных DublinCore. Кому-то необходимо отдельным полем описать код специальности ВАК, кому-то указать даты проведения конференции, кому-то уточнить источник поступления/оцифровки документа, или его тип.

В принципе, DSpace позволяет ввести дополнительный реестр метаданных, который, например, можно назвать local.

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

Если внести новые «поля» в параметр webui.itemdisplay.default файла dspace.cfg и соответствующим образом модифицировать перевод — поля нового реестра метаданных можно без проблем созерцать и в кратком виде записи, в т.ч. на нескольких языках, как, например, тут.

Всегда есть соблазн дополнить существующий DC реестр метаданных, но тогда начинаются проблемы с импортом и экспортом, PMH харвестом и другими процедурами, в рамках которых от DSpace ждут чистый DublinCore.

Ситуация, описываемая далее характерна для «старых» версий DSpace, версия 4.1 от неё свободна, а заключается ситуация в следующем — вводим реестр метаданных local, вводим поле local.type, запускаем dspace stat-initial и получаем:

C:\dspace>dspace stat-monthly
Using DSpace installation in: C:\dspace
Exception: ОШИБКА: подзапрос в выражении вернул больше одной строки
org.postgresql.util.PSQLException: ОШИБКА: подзапрос в выражении вернул больше одной строки
        at org.postgresql.core.v3.QueryExecutorImpl.receiveErrorResponse(QueryExecutorImpl.java:1531)
        at org.postgresql.core.v3.QueryExecutorImpl.processResults(QueryExecutorImpl.java:1313)
        at org.postgresql.core.v3.QueryExecutorImpl.execute(QueryExecutorImpl.java:188)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.execute(AbstractJdbc2Statement.java:452)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeWithFlags(AbstractJdbc2Statement.java:354)
        at org.postgresql.jdbc2.AbstractJdbc2Statement.executeQuery(AbstractJdbc2Statement.java:258)
        at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
        at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
        at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:96)
        at org.dspace.storage.rdbms.DatabaseManager.query(DatabaseManager.java:284)
        at org.dspace.storage.rdbms.DatabaseManager.querySingle(DatabaseManager.java:330)
        at org.dspace.app.statistics.LogAnalyser.getNumItems(LogAnalyser.java:1255)
        at org.dspace.app.statistics.LogAnalyser.processLogs(LogAnalyser.java:498)
        at org.dspace.app.statistics.CreateStatReport.statMonthly(CreateStatReport.java:181)
        at org.dspace.app.statistics.CreateStatReport.main(CreateStatReport.java:121)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.dspace.app.launcher.ScriptLauncher.main(ScriptLauncher.java:183)

C:\dspace>

Суть в том, что в некоторых версиях DSpace имел место такой вот кривенький SQL запрос:

SELECT COUNT(*) AS num FROM item WHERE in_archive = TRUE AND withdrawn = FALSE  AND item_id IN ( SELECT item_id FROM metadatavalue WHERE metadata_field_id = ( SELECT etadata_field_id  FROM metadatafieldregistry  WHERE element = 'date'  AND qualifier = 'accessioned')  AND text_value::TIMESTAMP > '2013-12-01'::TIMESTAMP  AND text_value::TIMESTAMP < '2013-12-31'::TIMESTAMP )  AND item_id IN ( SELECT item_id FROM metadatavalue WHERE text_value LIKE '%Thesis or Dissertation%' AND metadata_field_id = ( SELECT metadata_field_id  FROM metadatafieldregistry  WHERE element = 'type'  AND qualifier IS NULL) );

Который собственно два значения и возвращал. Если перевести запрос в человекопонятный вид, то он будет звучать так: Найдем все поля *.type со значением Thesis or Dissertation в промежутке от 01.12.2013 до 31.12.2013, сложим их, и выдадим результат. Но проблема в том, что и dc.type и local.type под эти условия попадают. И возвращает система два результата, в случае с local.type она возвращает ноль.

Данная ситуация была описана здесь в 2011 году в пору актуальности DSpace 1.7, но не была исправлена и в 1.8. Там человек получил ту же проблему, использовав дополнительный реестр метаданных от плагина Europeana.

Собственно, решения у данной проблемы три:

  • 1. Обновить DSPACE
  • 2. Избегать совпадения названий полей реестра метаданных DC и своего собственного. Имеющуюся проблему легко устранить просто переименовав поле в реестре метаданных один раз и поправить перевод и файл конфигурации DSpace.
  • 3. Залезть в код DSpace и модифицировать SQL запрос, до вида:
    SELECT COUNT(*) AS num FROM item WHERE in_archive = TRUE AND withdrawn = FALSE  AND item_id IN ( SELECT item_id FROM metadatavalue WHERE metadata_field_id = ( SELECT metadata_field_id  FROM metadatafieldregistry  WHERE element = 'date'  AND qualifier = 'accessioned')  AND text_value::TIMESTAMP > '2014-08-01'::TIMESTAMP  AND text_value::TIMESTAMP < '2014-08-31'::TIMESTAMP )  AND item_id IN ( SELECT item_id FROM metadatavalue WHERE text_value LIKE '%Thesis or Dissertation%' AND metadata_field_id = ( SELECT metadata_field_id  FROM metadatafieldregistry  WHERE element = 'type'  AND qualifier IS NULL LIMIT 1) );
Запись опубликована в рубрике Библиотека с метками . Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *