Konfiguracja wieloformatowości

Od wersji 6.0 dLibra pozwala dla każdego obiektu przechowywać i udostępniać pliki w różnych formatach. System dLibra nie kontroluje tego, jakie faktycznie pliki trafią do konkretnego formatu (np. po rozszerzeniach), to redaktor musi o to zadbać.

Dostępne formaty są zdefiniowane w pliku conf/ms/formats.xml, którego przykład zaprezentowany jest poniżej:

<?xml version='1.0' encoding='utf-8'?>
<formats>
    <format>
        <id>1</id>
        <name>DjVu</name>
        <index-priority>1</index-priority>
    </format>
    <format>
        <id>2</id>
        <name>PDF</name>
        <index-priority>2</index-priority>
    </format>
	....
</formats>

Dla każdego formatu przypisane są następujące wartości:

• id - numer używany do przypisywania formatów w bazie danych. Każdy format musi mieć inną wartość, najlepiej jak są to kolejne liczby.
• name - nazwa formatu, używana głównie w Aplikacji Redaktora. Standardowo jest to też nazwa podkatalogu w ramach obiektu cyfrowego, używana w ścieżce wszystkich plików należących do danego formatu. Nazwa ta nie jest bezpośrednio widoczna na stronach Aplikacji Czytelnika - tam są stosowane tłumaczenia, zdefiniowane w plikach WEB-INF/components/resources/WEBAPP_xx.xml
• index-priority - priorytet formatu przy ekstrakcji warstwy tekstowej do celów indeksowania/wyszukiwania. System najpierw analizuje format o największej wartości index-priority, a w razie niepowodzenia (jeśli pliki w takim formacie nie istnieją lub nie znaleziono w nich tekstu), próbuje następne z coraz mniejszym priorytetem. Jeśli kilka formatów ma taki sam priorytet, to tekst ze wszystkich tych formatów zostanie zaindeksowany (o ile nie ma innego formatu z wyższym priorytetem, w którym udało się znaleźć tekst). Ujemna wartość index-priority oznacza, że dany format nigdy nie będzie używany do utworzenia warstwy tekstowej.

Zarządzanie atrybutami - konfiguracja eksportu metadanych

Mimo że schemat atrybutów można modyfikować z poziomu Aplikacji Administratora, należy pamiętać, że po dodaniu nowych atrybutów warto uwzględnić je w konfiguracji eksportu metadanych. Konfiguracja ta znajduje się w katalogu serwera dLibra: conf/ms, w plikach o nazwach kończących się na -export.properties, np. dc-export.properties. Pierwszy człon nazwy pliku wskazuje format eksportowy, którego dotyczy plik:

• dc - Dublin Core, najbardziej podstawowy format w bibliotekach cyfrowych. Dane w tym formacie są eksportowane przez strony z opisem i treścią obiektu jako ukryte tagi meta, z których mogą korzystać różne systemy pobierające dane. Format ten jest również wykorzystywany przez protokół OAI-PMH. System dLibra wykorzystuje definicję tego formatu do rozpoznania, jakie role pełnią poszczególne atrybuty, np. który atrybut jest tytułem i powinien być wyszczególniony na stronie z opisem obiektu, a który zawiera tagi/słowa kluczowe, które powinny być wyświetlone w specjalny sposób pod opisem.
• dcterms - rozszerzenie standardu DC. Format udostępniany przez OAI-PMH (prefix=oai_qdc)
• bibtex, ris - formaty używane przez narzędzia do zarządzania bibliografią, dane udostępniane są na stronie z opisem obiektu, pod przyciskiem "Pobierz opis bibliograficzny".
• highwire - format wykorzystywany głównie przez Google Scholar, udostępniany jako ukryte tagi meta na stronie z opisem obiektu.
• edt - format wykorzystywany głównie przez organizację NDLTD, udostępniany przez OAI-PMH (prefix=aoi_etdms).

Przykładowy fragment pliku dc-export.properties:

contributor = Contributor
coverage    = Coverage, Spatial, Temporal
creator     = Creator

Każda linijka zaczyna się od nazwy pola/atrybutu w eksportowanym formacie, a po znaku równości znajduje się nazwa RDF atrybutu w dLibrze, lub lista takich nazw rozdzielanych przecinkiem.

Konfiguracja Self-Archiving

Funkcja self-archiving w standardowej konfiguracji jest dostępna tylko dla tych użytkowników, którym ustawiono katalog domowy. Zazwyczaj wystarczy wybrać w tym celu standardowy katalog Publikacje Użytkowników, ponieważ obiekty stworzone przez self-archiving trafiają nie bezpośrednio do wybranego katalogu domowego, ale do podkatalogu o nazwie o nazwie takiej samej, jak logino użytkownika dodającego publikację (ten podkatalog jest tworzony automatycznie). W niektórych instytucjach może się przydać zmiana, żeby wszyscy użytkownicy mogli dodawać swoje obiekty. W tym celu należy zmienić w pliku /conf/ms/service.properties wartość wpisu wwwPublicationAllowed na true. Przyniesie to taki efekt, jakby wszyscy użytkownicy mieli ustawiony katalog domowy na Publikacje Użytkowników. Gdyby podkatalogi miały być tworzone w innym katalogu, wystarczy wstawić jego identyfikator w wartości publicDirectoryId.