Warning: Constant WP_MEMORY_LIMIT already defined in /home/elorenzo/domains/arvo.es/public_html/dspace/wp-config.php on line 94
Documentación no técnica | Hablando de DSpace - Part 5

Archivos de Categoría: Documentación no técnica - Paginas 5

Versionado a nivel de ítem en DSpace 3.x

En la versión 3 de DSpace se ha incluido un sistema de versionado a nivel de ítem, que permite acceder a la historia de un ítem y posibilita el citar una versión particular del mismo.

El versionado a nivel de ítem es una nueva funcionalidad que permite construir la historia de un ítem. Los usuarios Administradores generales y los Administradores de Comunidad y Colección, tienen ahora la oportunidad de crear una nueva versión de un ítem existente cada vez que se hace un cambio en el mismo.

Cada versión de un ítem está representada por un identificador de versión independiente, que la deja accesible y permite que pueda ser citada. En las versiones anteriores de un ítem, se muestra un mensaje señalando el identificador de la versión más reciente del mismo.

Es necesario indicar que sólo la versión más reciente de un ítem se muestra en los resultados de las búsquedas.

Por defecto, la funcionalidad de versionado a nivel de ítem, sólo soportada en XMLUI, está desactivada. Para proceder a su activación, hay que descomentar la siguiente línea del fichero xmlui.xconf:

<aspect name="Versioning Aspect" path="resource://aspects/Versioning/" />

Actualmente, no existe una opción de configuración para permitir a los usuarios publicadores crear nuevas versiones de un ítem. Esta funcionalidad se limita a los Administradores generales y a los Administradores de Comunidad y Colección. Sin embargo, en un contexto donde los envíos originales de ítems a DSpace se realizan por usuarios no Administradores, tendría sentido que también pudiesen crear nuevas versiones, especialmente teniendo en cuenta el hecho de que las nuevas versiones tienen que pasar a través del flujo de trabajo definido.

Es importante tener en cuenta que al establecer el versionado a nivel de ítem, por defecto, el nombre y el email de los publicadores son visibles para todos los usuarios en el historial de versiones del ítem.

historial de versiones

De momento, la única solución para esto consiste en ocultar el historial de versiones a los usuarios generales, y dejarlo disponible sólo para usuarios Administradores. Para ello, hay que cambiar a true el valor del parámetro item.history.view.admin del fichero versioning.cfg ubicado en el directorio [dspace]/config/modules/.

¿el XMLUI?.. pero si es muy fácil

Hace muchos años (muchos) tuve que estudiar un libro introductorio a la electrónica cuántica cuyo título terminaba con esa apostilla.  Me parece que ese tipo de literatura se ha reconvertido en la seríe de títulos xxxxx, for dummies,  con lo que no descartamos pasar a la fama con un libro titulado  XMLUI for dummies….

Bromas aparte, comenzemos con un pequeño glosario sobre términos usados en XMLUI:

  • Cocoon:  framework de desarrollo web (del  proyecto Apache) que utiliza los conceptos de pipeline y tiene una arquitectura basada en componentes.
  • Sitemap:   fichero  XML usado para configurar los diversos componentes Cocoon,  que son del tipo: generadores, trasnformadores, serializadores,  …
  • Aspecto/ Aspect: proporciona el conjunto de funcionalidades presentes en la interface de usuario, generando mediante transformaciones encadenadas un documento DRI.
  • DRI (Digital Repository Interface): esquema, codificado en xml,  que estructura y gobierna las páginas XMLUI
  • Tema / Theme : proporciona el estilo al contenido generado, produciendo el XHTML para su visualización. Básicamente es la herramienta que convierte un documento DRI en un formato legible por el usuario.

 

Un proceso de construcción de una página DSpace  en XMLUI realiza las siguientes tareas:

  1. Generar la página DRI, representación xml de la página solicitada, concatenando los diversos aspectos involucrados: eperson, artifact browser, etc…
  2. Añadir referencias a los ficheros CSS que usará el tema. estas referencias se incluyen en la sección pageMeta del documento DRI. De esta manera las XSL que convierten el documento DRI en XHTML pueden encontrar esas referencias y ponerlas en la salida XHTML
  3. Transformar DRI a XHTML.  Generalmente (depende algo del tema y de las personalizaciones efectuadas) se hace a través de la librería dri2xhtml.xsl  o el código modificado que se haya escrito.
  4. Se internacionaliza la página, invocando el transformador Cocoon i18n  para resolver las etiquetas <i18n:text>
  5. Se envía al navegador, aplicando la CSS correspondiente.

 

Y visto de otra manera, más directa ¿o más práctica?….  ¿cuáles son los elementos involucrados en una customización de DSpace-XMLUI?

  1. Modificación simples al diseño, creación de temas simples: XHTML + CSS
  2. Modificaciones complejas al diseño, creación de temas complejos: XSL + XHTML + CSS
  3. Añadir nuevas funcionalidades, modificación de los «aspects»: Cocoon + Java

 

Traducción al español de Dspace 3.0 disponible

Ya está puesta a disposición de la comunidad la traducción al español de la versión 3.0 e interfaz XMLUI. El fichero messages_es.xml   está incorporado en la distribución de la versión 3.0, aunque también se encuentra disponible en el ticket jira 1398.

En ese mismo tícket está disponible el fichero de traducción de los mensajes correspondientes al Discovery, y señalar que por premuras de ensamblaje de la versión 3.0, no pudimos incluir la traducción de los módulos SwordClient y XMLWorkflow.  Recordar que desde la version 1.8, cada módulo distribuye su propio messages.xml, separado del messages.xml principal, de manera similar a la fragmentación de los ficheros de configuración…

Como en ocasiones anteriores, hemos revisado algunas de las traducciones de mensajes que veníamos arrastrando de versiones anteriores, intentando luchar algo contra el desorden natural de los mensajes…. Pues eso, sean benevolentes.

 

 

 

BIREDIAL 2012, Universidad del Norte, Barranquilla

Estuvimos presentes en la  II Conferencia Internacional sobre Bibliotecas y Repositorios Digitales -BIREDIAL , que fué organizada por la Universidad del Norte en Barranquilla, Colombia, y en la cual impartí un taller acerca de las tareas de curación en DSpace.

Antes de nada agradecer a la Universidad del Norte su excelente  hospitalidad  y ayuda permanante en toda la estancia.  (nota al margen: además es muy recomendable ir a Barranquilla porque,  aparte de ser la ciudad natal de Shakira, su gente es excepcional y siempre te atenderán magníficamente :-)

BIREDIAL  pudo reunir a profesionales de DSpace y otras herramientas de gestión de repositorios digitales,  Directore/as y resto de personal de Bibliotecas y otras instituciones, siendo un marco adecuado para intercambiar experiencias de los diferentes países a los que pertenecían todos los asistentes.

En las ponencias se comentaron experiencias acerca del uso y características de diferentes herramientas, así como determinadas  carencias que tenían,  lo que sirvió para una interesantísima  puesta en común para dar soluciones a los diferentes tipos de problemas que surgían. Desde Arvo Consultores aportamos nuestra experiencia y conocimiento de DSpace para intentar dar soluciones y orientar a las diferentes instituciones presentes.

Especificamante en el taller que impartí, y que tuvo como tema central  las tareas de curación, expuse  ejemplos prácticos asi como teóricos sobre la inclusión-activación de las tareas de curación en DSpace (para los que no estuvieron presentes, en el blog tenemos unos post acerca de las tareas de curación). Adicionalmente,  en el taller se pudo hacer una pequeña demostración de la aplicación Easydeposit (desarrollada por Stuart Lewis,  mas información aquí  y en unos cuantos post de este blog)

Para acabar el post quiero acabar con un rotundo Gracias a la Universidad del Norte por su acogida, y por supuesto  están invitados a conocer nuestra tierra.

Administradores de Colección y Comunidad

En los repositorios digitales mayores o con estructuras de colecciones y comunidades amplias, la administración puede delegarse en los Administradores de Comunidad y Administradores de Colección. Estos usuarios (en realidad son e-grupos) pueden selecionar los revisores o editores en los flujos de aprobación-revisión,  las políticas de acceso, etc.. en sus respectivos ámbitos.

Los Administradores de Colección tienen privilegios sobre una determinada Colección, y pueden decidir a quién se le permite enviar ítems a la misma, así como añadirlos, editarlos o eliminarlos.

Un Administrador de Colección, además de disponer de los menús “Listar” y “Mi Cuenta”, dispone del menú “Contexto” para la Colección sobre la que tiene permisos de administración, desde el cual podrá editar dicha Colección, exportarla completamente o exportar sus metadatos, así como relacionar ítems pertenecientes a otras Colecciones en ésa. De la misma forma, tendrá permisos para editar, exportar completamente o solamente los metadatos, de los ítems pertenecientes a esa Colección. Sin embargo, el Administrador de Colección carece del privilegio de restringir el acceso a la lectura de los ítems y archivos entrantes en la Colección, que por defecto está asignado al Grupo Anónimo, ya que este privilegio sólo está disponible para el Administrador General del Sistema.

El Administrador de Colección dispone también del menú “Estadísticas”, desde el cual puede visualizar las estadísticas de uso de su Colección y de sus ítems, pero carece de la opción de visualización de las Estadísticas generales del sistema, así como del acceso a los Informes estadísticos mensuales. Ésta también es una opción disponible sólo para Administradores Generales del Sistema.

Hay que señalar que los Administradores de Colección carecen del menú “Administrativo”, por lo que no poseen funciones generales de control de acceso y gestión de usuarios y grupos, funcionalidades sobre registro de metadatos y formatos, de importación de metadatos, tareas de curación y tampoco acceso al “Panel de control” de la herramienta. Además, un Administrador de Colección no puede crear nuevas Colecciones.

Los Administradores de Comunidad gozan de un mayor número de permisos que los Administradores de Colección, ya que son aquellos usuarios de DSpace que tienen todos los privilegios sobre una determinada Comunidad, y pueden decidir a quién se le permite enviar ítems a sus Colecciones, editar los metadatos, y relacionar ítems existentes en otras Colecciones. Además, pueden crear Subcomunidades y Colecciones, así como gestionar o asignar permisos para las mismas. Sin embargo, no pueden crear nuevas Comunidades, funcionalidad que sólo está permitida para el Administrador General del Sistema.

De manera análoga a los adminitradores de colecciónm , además de los menús “Listar”, “Mi Cuenta” y “Contexto”, el Administrador de Comunidad dispone del menú “Estadísticas”, desde el cual puede visualizar las estadísticas de uso de su Comunidad y de sus Colecciones e ítems, pero carece de la opción de visualización de las Estadísticas generales del sistema, así como del acceso a los Informes estadísticos periódicos, ya que como se ha indicado anteriormente, ésa es una opción disponible sólo para los Administradores Generales del Sistema.

Los Administradores de Comunidad, al igual que los de Colección, carecen del menú “Administrativo”, por lo que tampoco pueden realizar las tareas Administrativas descritas anteriormente.

Traduccion al gallego de Dspace 1.8- XMLUI

La traducción al gallego de la interfaz XMLUI de Dspace para versiones 1.8 y anteriores está ya disponible. El fichero messages_gl.xml se encuentra disponible en el ticket jira 1394.

La traducción se ha realizado en el marco de un proyecto para la Universidade de Vigo, revisándose por el Área de Normalización Lingüistica de dicha universidad.

Auto-Registro y Registro de Usuario

La mayoria de las funciones de Dspace, como buscar documentos o descargarlos si están en acceso abierto, pueden usarse de forma anónima, es decir, sin realizar ningún tipo de autenticación de los usuarios. Sin embargo, ciertas características de DSpace solo son accesibles a usuarios privilegiados, y eso significa ser capaz de identificarlos y una vez hecho esto, asignarles permisos y acceso a esas funciones restringidas.

Las e-personas (e-people) y los grupos son los entes usados por Dspace para identificar usuarios y asignar privilegios. Las e-personas pueden existir mediante proceso de auto-registro o bien registradas (creadas)  por un administrador.  Existen diferencias sustanciales en el uso de cada opción.

En el procedimiento de Auto-Registro de un usuario, éste accede a la sección “Registro de nuevo usuario” e introduce su dirección de correo electrónico. Dspace, de manera automática, envía un correo (con un token de seguridad) a esa dirección para que se pueda continuar el registro. Siguiendo las instrucciones del correo recibido, el usuario crea su cuenta, introducir sus datos y una contraseña. A partir de ese momento, puede acceder a Dspace mediante el formulario de login, con la dirección de correo y contraseña indicadas. Finalizado el proceso de registro, el nuevo usuario es incluido en la Base de Datos de DSpace, con un identificador único asociado.

En el procedimiento de Registro de usuario por el Administrador, es éste quien crea al nuevo usuario, accediendo a la sección de “Gestión de usuarios”, sólo disponible para usuarios con este rol, y pulsando el enlace correspondiente para añadir un nuevo usuario. El Administrador debe introducir la información del nuevo usuario, incluyendo una dirección de correo electrónico, y pulsar el botón “Crear usuario” para crear un nuevo usuario en DSpace. Mediante este procedimiento, el nuevo usuario también es incluido en la Base de Datos de la herramienta con un identificador único asociado. Sin embargo, en un principio no puede acceder a la herramienta mediante contraseña, puesto que no tiene ninguna. Este sistema se emplea principalmente cuando los credenciales de acceso a Dspace se reciben de otros sistemas de identificación como un LDAP. Claro que habrá que configurar Dspace para ello.

Como segundo escenario para que el usuario creado mediante el sistema de Registro por un Administrador pueda acceder a DSpace mediante contraseña, debería ser el Administrador quien, desde la sección de “Gestión de usuarios”, pulse el botón “Restablecer contraseña” correspondiente a dicho usuario. De esta forma, la herramienta envía, de manera automática, un correo a la dirección de ese usuario para que pueda modificar su contraseña, o, en este caso, introducir una contraseña por primera vez.

Probamos DSPACE 3.0. Y nos gusta…

Pues no pudimos esperar más y nos bajamos e instalamos la Dspace 3.0-rc1 release. Realizamos la décimosegunda descarga, y nosotros pensando que llegábamos tarde….

El proceso de instalación, sobre un Ubuntu 9, Postgresql y Tomcat 6 que estaba en una máquina virtualizada  fué nítido y rápido, y voilà, ya teníamos un Dspace3.0 con xmlui para probar. Mientras redactamos una evaluación detenida, os podemos contar algunos de los temas que destacan (y que estábamos esperando) de esta versión. No es una lista exhaustiva de todo lo bueno que contiene esta versión, que es mucho, y que lo podéis encontrar aquí.

Versionado a nivel de item.
La historia de un item está disponible y es posible citar una versión particular de un item.

Modificaciones al sistema de embargo. Ya no se require el uso de los crontab (embargo-setter y embargo-lifter) para aplicar las restricciones, sino que se usa el AuthorizationManager, definiéndose una Embargo Resource Policy que hace uso de las fechas de comienzo y fin de las ResourcePolicies. Tendremos que echar una pensada sobre esta implementación. Ya os contaremos.

Mejoras al Discovery. La gente de @atmire sigue marcando diferencias y en esta versión la lista de propuestas para Discovery/Solr es abrumadora: resaltado de keywords, recomendaciones, nuevo tratamiento de las facetas, etc… Y SOBRE TODO:

  • Han portado el Discovery a JSPUI (gracias al apoyo de la Universidad de Hong Kong). Enhorabuena a los usuarios de JSPUI, ahora tendrán la popsibilidad de usar Discovery
  • Y Solr tiene en cuenta los derechos de acceso a un item, de modo que detecta que si el usuario no tiene accesos de lectura, ese ítem no se muestra en los resultados en las búsquedas. Para todos aquellos que en un momento dado buscamos ocultar items y colecciones y no lo logramos porque al final aparecían en los resultados de los buscadores, este es un avance sustancial. Habrá que probar esta función en detalle.

Mejoras al sistema de estadísticas. Aparte de que se han incluído estadísticas de search en colecciones/comunidades específicas y estadísticas de los workflow, aparecen una serie de utilidades para el tratamiento de grandes ficheros de log, con el fin de intentar minimizar el problema que generan los logs en instalaciones con mucho tráfico.

Envíos basados en tipo de documentos. Esta era una solicitud que venía de lejos (Google Summer of Code, un ticket jira DS-464, muy antiguo y una adaptación-patch a la versión 1.8 con el código del ticket jira DS-1127). Se dirige a la necesidad de muchos repositorios de adaptar los formularios de envío (input-forms) a los diversos tipos de objetos del repositorio. Hasta ahora la única solución era definir colecciones diferenciadas, cada una con un <form> adaptado. El enfoque ha cambiado, y se han incorporado en los <field> restricciones a su visualización dependiendo de determinadas características de los objetos que se describen. Posiblemente un enfoque más cómodo que el anterior.

OAI 2.0 basado en xOAI, aportado por la empresa Lyncode, antiguos Universidad do Minho y Keep solutions, creo. Permite la creación de sets virtuales, filtrado y transformación. Entendemos que es una reforma completa, o quizá evolución natural del OAIextended, pero basado en un framework OAI mejorado. Lo evaluaremos.

Tratamiento de formatos bibliográficos. Los scripts de importación disponen ahora de una opción que a partir del Biblio-Transformation-Engine es capaz de importar metadatos ¿y bitstreams? de los formatos Endnote, BibTex, RIS, TSV, CSV. Pues esto hay que probarlo en detalle..

Sobre los Formatos de ficheros

Como indica el documento ISO/TC 46/ SC 11 Digital records preservation: Where to start Guide, la naturaleza de los registros digitales origina una serie de desafíos que deben ser contemplados si se busca la preservación de los registros en el transcurso del tiempo. Los desafios principales son:

  • Obsolescencia y degradación de los formatos físicos (media)
  • Obsolescencia de los formatos de ficheros
  • Obsolescencia del software ( sistemas operativos, bases de datos, ofimática…)
  • Obsolescencia de Hardware

The current rate of technological change may mean that preservation actions, such as migrating to more accessible or durable formats may be required after as little as five years. Digital preservation should therefore be addressed from as early in the object life cycle as possible, particularly as the manner in which a resource is created has a significant impact on its durability. “Digital Preservation: Continued access to authentic digital assets»; Briefing paper; JISC; nov 2006.

Como consecuencia, se requiere la intervención casi continua y desde el primer momento, de los archivistas para preservar los contenidos digitales.

Obsolescencia de Formatos de ficheros

Principalmente se requiere un enfoque de anticipación, puesto que continuamente aparecen nuevos formatos, aunque estudios recientes sobre repositorios científicos de acceso abierto muestran un dominio del formato PDF y una larga cola (long tail) de otros formatos.  «Characterising and Preserving Digital Repositories: File Format Profiles»; Steve Hitchcock and David Tarrant; 30-January-2011; Ariadne Issue 66.

En un momento dado, una comunidad de usuarios como la que conforma nuestros repositorios Dspace podría estar usando decenas de aplicaciones y cientos de formatos, y lo que es más importante, deseando efectuar depósitos con las menores restricciones posibles. Al fin y al cabo, ¿a quién le gusta convertir formatos?

Los responsables de un repositorio, si son precavidos, deberían tener en cuenta este escenario de cambio, evolución y desorden, ya que una política de preservación que no considere el cambio, no es una buena política.

Formatos de Archivo (Archival Data Formats)

Uno de los elementos principales de un enfoque de preservación es el uso (sugerencia, recomendación u obligación) de formatos de archivo que no sean propietarios (se caen los formatos ms-office y decenas de otros) y que además estén específicamente definidos para el acceso en el largo plazo y desde diferentes plataformas tecnológicas.

Entre los candidatos a formato estable para documentos típicos, se considera normalmente el uso del Portable Document Format (PDF) de Adobe. Por ello nuestros repositorios están repletos de este formato, gusta a los usuarios y por tanto PDF es un buen candidato para formato de archivo.

Incidentalmente, PDF puede corresponder a Portable Document Format (Adobe), Printer Definition File (Netware) o a Package Definition File (Microsoft Systems Management Server) y aunque posiblemente no veremos nunca por nuestros Dspaces un PDF no-Adobe, el ejemplo ilustra los riesgos de asumir la extensión como indicación del formato. La extensión del nombre de fichero de tres caracteres no está ni estandarizada, ni es única, siendo además interpretada diferentemente por diferentes entornos.

Y a efectos de preservación, PDF significa al menos 17 formatos diferentes de Adobe: Acrobat pdf 1.0, 1.2, 1.3,..1.7, Acrobat PDF/A, Acrobat PDF/X Exchange 1a:2003, etc… con estrategias de preservación (migración y conversión) igualmente diferentes. Si a esto le añadimos las funcionalidades de protección de documentos de Adobe, la amenaza de los Digital Rights Management, u otras curiosas posibilidades de este magnífico software, pues entenderemos que la tarea de preservación puede ser muy complicada.

Recomendamos: Asomarse un poco a a la complejidad de los formatos, y de sus efectos en la preservación, en el registro PRONOM de los National Archives del Reino Unido.

 

Los formatos en Dspace

Por contra de otras muchas virtudes que tiene Dspace, en el asunto de formatos considero que nos ofrece poca ayuda a nuestra tarea. Expliquémosnos.

DSpace usa la extensión de fichero como indicación de la codificación (formato) del fichero. En ese sentido, Dspace considera la extensión como un «metadato» y a partir de ahí, mediante un macheo con el format-registry, asume el formato del fichero y el nivel de soporte que se determina sobre el formato. Sobre el soporte de formatos y el format-registry en DSpace ya escribiremos un post detallado.

Las consecuencias de esta sobre-simplificación de la identificación de formato son diversas, ya que podemos tener:

  • Un único saco para varios formatos similares y teóricamente compatibles, pero no lo olvidemos, a efectos de preservación, distintos: el caso explicado antes de los 17 formatos de Adobe PDF.
  • Asignaciones incorrectas tipo 1: considerar que tenemos un Adobe/pdf  y en realidad estamos «custodiando» un MS-Package Definition File, o cualquier otra cosa que el autor ha decidido renombrar con esa extensión.
  • Asignaciones incorrectas tipo 2: considerar que un fichero no está soportado, porque su extensión no corresponde a una soportada (el caso más obvio, los ficheros sin extensión)
  • etc..

Las soluciones que podemos vislumbrar, no son complejas, y están desde hace tiempo en la línea de evolución y desarrollo de Dspace, con una mezcla de tareas automáticas, como procesos batch o empotradas en los workflows de envio, de data profiling basadas en el software Droid (también de los National Archives del Reino Unido, qué bárbaros) o el framework Jhove2 (que usa Droid para la identificación de formatos) o alguna otra alternativa.

CommunityFiliator, reorganizando estructuras de comunidades

Aviso a navegantes, éste puede considerarse un post «raro». Si quedaste extrañado cuando explicamos el structure-builder, quizá sea mejor que no sigas leyendo.

Cuando hace tiempo nos topamos con el comando communityFiliator, la sensación de extrañeza fué mayúscula ¿y esto para qué sirve?. Ahora la pregunta sería diferente ¿y esto se usa en alguna parte?

Un poco de historia

Antes de la versión 1.2 no existía la posibilidad de definir sub-comunidades, es decir sólo habia Comunidades y Colecciones colgando de ellas.

En la actualidad se pueden definir n-elementos, sub-comunidades, entre la Comunidad de nivel superior y las Colecciones.

Pues bien, este comando sirvió a las instalaciones Dspace para «re-colocar» estructuras planas, dos niveles, en estructuras más piramidales.

Una comunidad en DSpace se puede considerar

  1. ‘padre’ (en realidad madre) en el sentido que hay al menos otra comunidad (sub-comunidad) dependiendo de ella. [Por ejemplo, en la figura anterior, las comunidades 2, i, i.j serían ‘madres’]
  2. ‘hij@’, significando que depende de una comunidad de un nivel superior. [Comunidades 2.1, 2.2, i.j, i.j.k]
  3. Ninguna de las dos cosas (no tiene sub-comunidades dependientes y su vez no depende de otra comunidad). [Comunidad 1]
  4. Ambas cosas (tiene sub-comunidades dependientes y a la vez depende de otra comunidad). [Comunidad i.j]

En estos términos, una comunidad ‘huérfana’ es quien no tiene ‘madre’, a éstas también las llamamos comunidades de nivel superior (top-level communities).

El comando tiene dos sabores: Set y Remove, para establecer y deshacer relaciones madre-hija.
Set sirve para coger una comunidad huérfana, es decir de nivel superior, y hacerla dependiente de otra comunidad, moviendo toda la estructura debajo de la especificada en el comando. Y Remove convierte a una comunidad ‘hija’ en ‘huérfana’.

Igual que el structure-builder, el CommunityFiliator se incluye en la clase Org.Dspace.administer y se invoca con un

[dspace]/bin/dspace community-filiator parámetros…

Los comandos tienen la sintaxis siguiente:

[dspace]/bin/dspace community-filiator -s -p ID1 -c ID2

en donde ‘-s’ o ‘–set’ significa que a la comunidad ‘huérfana’ con ID2 la hacemos depender de la ID1

y usando el comando Remove, con la sintaxis alternativa que la mayoría de comandos Dspace tienen:

[dspace]/bin/dspace community-filiator –remove –parent=ID1 –child=ID2

en donde hacemos huérfana a la comunidad ID2, ‘matando’ la relación de dependencia con la ID1

Lamentablemente, y por si no nos habíamos dado cuenta hasta ahora, el comando no sirve para mover colecciones (SOLO comunidades y sus colecciones dependientes) de una comunidad a otra, o dicho de otro modo los IDs corresponden a entradas en la tabla comunidades, no en la tabla colecciones. De hecho el comando re-escribe justamente la tabla comunidades…