DSpace admite bitstreams en una diversidad de formatos (formato: forma particular en que una información se codifica en un fichero o medio digital). La concepción inicial de Dspace se realizó con una política amplia respecto de los formatos: reconocer y soportar la mayor cantidad de formatos posibles, aunque la naturaleza propietaria de muchos formatos hace dificil garantizar lo anterior.
Administrar correctamente los formatos admitidos (en parte, mediante el registro de formatos), tal y como hablábamos en un post anterior, es una de las tareas claves de la preservación digital.
Cuando se sube un fichero a DSpace, dependiendo del formato inferido de la extensión del mismo, se le asignará uno de los tres niveles de soporte siguientes:
- Soportado (Supported). Se reconoce y soporta completamente el formato. El administrador de Dspace lo mantendrá legible en el futuro, usando las técnicas que en cada momento considere más convenientes (conversión, migración, emulación…)
- Conocido (Known): el formato está declarado como reconocible en el registro, pero el administrador del repositorio no puede garantizar o no ha tomado aún una decisión sobre un soporte pleno a efectos de preservación. Este podía ser el caso de formatos propietarios, pero de muy amplia difusión, (como los de Microsoft, p.ej)
- No soportado (Unknown): el formato no está en la lista de reconocimiento de DSpace; esos ficheros aparecerán con listados como «application/octet-stream», or «Unknown»
Con el nivel de soporte, estamos haciendo una declaración sobre su uso futuro, y es responsabilidad del administrador seleccionar qué formatos aceptará y qué servicios de evolución de los mismos se requieren para satisfacer las necesidades de los usuarios con el mejor contexto de preservación posible.
El directorio ../[dspace_inst]/config/registries contiene tres ficheros XML. El de nuestro interés es el bitstream-formats.xml. En el arranque inicial del sistema, el ant fresh_install realiza una carga inicial de dicho fichero en la BBDD.
Nota: Cualquier cambio posterior que se realice con la UI, no actualiza el fichero xml. Si efectuamos posteriormente una carga del fichero, mediante el comando registry-loader, es decir :
..\dspace_inst*\bin\dspace registry-loader bitstream-formats.xml
pues se perderán aquellos cambios que hubíesemos realizado mediante la interfaz de usuario. Lo cual es importante porque en algunos procesos de actualización de versiones (p.ej 1.7 a 1.8) hay que ejecutar este comando desde la CLI.
Los contenidos del registro de formatos de bitstreams son responsabilidad del administrador del repositorio, aunque Dspace obliga a que al menos los formatos «unknown» y «license» estén definidos. Una entrada típica de un formato definido en este registro es de la forma:
entrada <bitstream-type> del bitstream-formats.xml
<bitstream-type>
<mimetype>application/vnd.sun.xml.draw</mimetype>
<short_description>Draw 6.0 documents</short_description>
<description>Draw 6.0 documents</description>
<support_level>1</support_level>
<internal>false</internal>
<extension>sxd</extension>
</bitstream-type>
Ejemplo Descripción <mimetype> application/vnd.sun.xml.draw Identificador de tipo MIME (Multipurpose Internet Mail Extensions) <short_description> Draw 6.0 documents El nombre de formato más usual de este formato <description> Draw 6.0 documents id <support_level> 1 Nivel de soporte Dspace de este formato, codificado como:0= Desconocido, unknown 1 = Conocido, known
2 = Soportado, supported
<internal> false Los formatos marcados como «internal», es decir, este campo a true, se usan por el sistema, y no se representan a los usuarios <extension> sxd Extensión habitual de filename, la parte tras el «.» del nombre completo del fichero
Los comentarios están cerrados.