Skip to content

Ingesta

Jump to bottom Edit New page
pablo edited this page Jul 5, 2018 · 1 revision

El Submission y el Workflow son los mecanismos más importantes que provee para permitir el ingreso de bitstreams al repositorio de parte de los usuarios (E-Person) vinculados al repositorio, a través de una interfaz web, amigable y guiada.

Submission

El proceso de Submission en DSpace es un conjunto de pasos o steps, donde cada step se corresponde con una o más páginas de interfaz. Estos pasos permiten la interacción entre los usuarios y la aplicación a través del envio de formularios de datos. Tambien existen pasos automáticos que no requieren de una vista para ejecutarse, y por lo general, estos son ejecutados automáticamente por DSpace (p.e. un paso para agregar un determinado metadato dinámico). El proceso termina una vez todos los pasos fueron ejecutados, y tras su finalización, el item enviado por el usuario pasa al proceso de Workflow para una revisión por parte de los administradores correspondientes.

Modelo básico

El módulo de Submission persiste datos en la base de datos cada vez que un envío es iniciado, generando una tupla en la tabla workspaceitem. La información guardada principalmente es:

  • ID del usuario (EPerson) que inició el envío.
  • La colección en donde se quiere enviar una publicación.
  • El item generado y asociado al envío.
    • A su vez, se guarda en el sistema los bitstreams (archivos) que el usuario quiere depositar.

workspaceitem_simple_model

Archivos de Configuración

Este módulo se configura principalmente a través de 2 archivos:

  • item-submission.xml
  • input-forms.xml

item-submission.xml

El archivo item-submission.xml es el principal archivo de configuración, ya que en él se define el flujo de pasos a ejecutar para completar el proceso de Submission. Éste se caracteriza por ser lineal, a diferencia del Workflow que tiene un flujo con múltiples caminos de ejecución.

Este archivo XML consta de la siguiente estructura:

<item-submission>
    <!-- Where submission processes are mapped to specific Collections -->
    <submission-map>
        <name-map collection-handle="default" submission-name="traditional" /> ...
    </submission-map>
    <!-- Where "steps" which are used across many submission processes can be defined in a
       single place. They can then be referred to by ID later. -->
    <step-definitions>
        <step id="collection">
            <processing-class>org.dspace.submit.step.SelectCollectionStep</process;/processing-class>
            <workflow-editable>false</workflow-editable>
        </step>
        ...
    </step-definitions>
    <!-- Where actual submission processes are defined and given names. Each <submission-process> has
       many <step> nodes which are in the order that the steps should be in.-->
    <submission-definitions>
        <submission-process name="traditional">
            <!-- Step definitions appear here! -->
            <!-- step A -->
            <!-- step B -->
            ...
        </submission-process>
        ...
    </submission-definitions>
</item-submission>
<submission-map>

Podemos definir varios <submission-process> y mapearlos con las colecciones que querramos en la sección <submission-map> (como por ejemplo un submission para una colección de autoarchivo). Existe un mapeo por defecto llamado traditional, el cual fue diseñado para mapear con cualquier colección que no tenga definido un <name-map> específico.

<step>

Los <steps> pueden definirse tanto en la sección de <step-definitions> como dentro de cada <submission-process>. El orden en el que éstos aparecen en el <submission-process> definen el orden de ejecución que tendrán.

Su estructura consta de los siguientes elementos:

  • <heading>: aquí se coloca una clave i18n, y el texto relacionado a esta clave será utilizado para describir el nombre del paso en el trail que se visualiza durante el submission.
  • <xmlui-binding>: la ruta entera Java (paquete y clase) a la clase que define la vista de este <step> en XMLUI. Si no se define esta clase, el paso se considera como automático.
  • <jspui-binding>: ídem a <xmlui-binding> pero en JSPUI.
  • <processing-class>: la ruta entera Java (paquete y clase) a la clase que procesa la información contenida en el formulario enviado por el usuario cuando termina de ejecutar este paso. Este elemento es obligatorio.
  • <workflow-editable>: Si está en true, indica que los revisores pueden editar la información recolectada en éste paso durante el proceso de Workflow. Por defecto, siempre es true.

DSpace ya ofrece una serie de pasos por defecto: SelectCollectionStep, DescribeStep, UploadStep, LicenseStep, etc. P.e. el DescribeStep es el encargado de recolectar los metadatos relativos a la publicación que el usuario quiere depositar en el repositorio.

input-forms.xml

En el archivo input-forms.xml se definen los formularios utilizados por el DescribeStep.

 <!-- Aquí se definen los mapeos entre formularios y colecciones. -->
 <form-map>
   <name-map collection-handle="default" form-name="traditional" />
   ... ... ...
 </form-map>

 <!-- Aquí se definen la estructura que tendrá cada formulario -->
 <form-definitions>
    <form name="traditional">
        <!-- Un formulario puede dividirse en una cantidad ilimitada de páginas,
             cada una con su definición propia de campos -->
        <page number="1">
           <field>  <!-- Primer campo -->
           </field>

           <field>  <!-- Segundo campo -->
           </field>
           ... ... ...
        </page>
        <page number="2">
           ...
        </page>
        ... ... ...
        <page number="N">
           ...
        </page>
    </form>
 </form-definitions>

 <!-- Aquí se definen los conjuntos de valores que se utilizan en los campos cuyo tipo "qualdrop_value" en los formularios -->
 <form-value-pairs>
   <value-pairs value-pairs-name="document_types" dc-term="">
	   	   <pair>
	         <displayed-value>Scientific Article</displayed-value>
	         <stored-value>article</stored-value>
	      </pair>
	      <pair>  
			         <displayed-value>Artistic Article</displayed-value>
			         <stored-value>article</stored-value>
		      </pair>
      <pair>
			         <displayed-value>Book</displayed-value>
			         <stored-value>book</stored-value>         
      </pair>
      ... ...
   </value-pairs>
   ... ... ...

 </form-value-pairs>
<form-map>

Se pueden definir una cantidad arbitraria de formularios, y cada uno mapea con una colección particular. Al igual que en el item-submission.xml, existe un formulario por defecto llamado traditional que aplica para cualquier colección que NO tenga definido un formulario.

<field>

Los <field> son los elementos que permiten la interacción entre el usuario y DSpace. Definen la correspondencia entre un campo del formulario y un metadato del sistema, además de otras restricciones sobre el campo. Los elementos que componen un campo son:

  • <dc-schema>, <dc-element>, <dc-qualifier>: Definen el esquema, elemento y calificador de un metadato. P.e.: dc.date.issued. El único elemento opcional de estos es el <dc-qualifier>.
  • <repeteable>: indica si el campo admite múltiples instancias o no.
  • <label>: indica el texto con el que se visualizará el nombre del campo en el formulario. P.e. para el campo dc.date.issued el label correspondiente podría ser "Fecha de Publicación".
  • <input-type>: indica el tipo de campo (onebox, twobox, textarea, name, date, series dropdown, qualdrop_value, list). Si el campo es el qualdrop_value (sería un <select> en HTML) hay que especificar el atributo "value_pairs_name" que hace referencia a un elemento <value-pair> específico.
  • <hint>: indica el mensaje de ayuda que se mostrará al usuario cuando complete el campo.
  • <required>: si este elemento está presente, indica que el campo en cuestión es obligatorio. Su contenido es un mensaje que se mostrará al usuario si es que no completa este campo obligatorio.
  • <type-bind>: indica una restricción a nivel de tipología documental (dc.type). Existen 2 tipos de patrones a incluir aquí:
    • Patrón positivo: Si el tipo de documento seleccionado por el usuario coincide con el patrón incluido aquí adentro, entonces el campo es mostrado. P.e. si el patrón es <type-bind>Artículo,Objeto de conferencia</type-bind> entonces el campo se mostrará sólo para las tipologías Artículo y Objeto de conferencia.
    • Patrón negativo: El patrón comienza con un "!". Si el tipo de documento seleccionado por el usuario coincide con el patrón incluido aquí adentro, entonces el campo NO es mostrado. P.e. si el patrón es <type-bind>!Artículo,Objeto de conferencia</type-bind> entonces el campo se mostrará para cualquier tipología que NO sea Artículo y Objeto de conferencia.
  • <i18n>: si está en true, entonces despliega al lado del campo un selector de idioma, de tal forma que el campo pueda aceptar varias instancias del mismo campo en diferentes idiomas. Los idiomas a mostrar son tomados de la propiedad webui.supported.locales.

Para más información, ir a la página de Submission User Interface en el wiki de DSpace.

Workflows en UNER (Repositorio Institucional de la Universidad Nacional de Entre Ríos)

  • Submission
    • Proceso que permite enviar un nuevo item al repositorio a través de un formulario de envío. El formulario consta consta de un conjunto de páginas que permiten describir los metadatos de un ítem.
  • Workflow
    • Proceso que permite la revisión de los ítems enviados mediante el Submission.
    • Determina cuándo un envío está apto o no para su archivo en el repositorio.
    • Define un conjunto de pasos o steps a seguir.
    • Cuando todos los pasos son ejecutados sin interrupción hasta el final, entonces el envío es archivado en el repositorio.

En UNER se crearon 3 workflows específicos

  • Autoarchivo
  • Comunidad Dependiente (default)
  • Comunidad Independiente

Workflow autoarchivo

Un usuario registrado (pero sin ningún tipo de permiso) envía un item al repositorio, y luego es revisado por un UNER-ADMIN.

  • La única colección en la que puede realizar envíos es en la llamada "Autoarchivo"

1

Workflow Dependiente

Es el workflow por defecto, y presenta un flujo de trabajo mediado, primero, por un ADMIN de FACULTAD y, luego, por un UNER-ADMIN, centralizando la decisión de publicar un ítem en manos de un UNER-ADMIN.

2

Workflow Comunidad Independiente

Este circuito permite la publicación directa a los ADMIN de FACULTAD, sin la necesidad de una revisión central por parte de un UNER-ADMIN. Hasta ahora ningun ADMIN de FACULTAD tiene configurado este workflow.

3

Configuración de Workflows

Para gestionar la carga de items en un repositorio, DSpace ofrece un mecanismo de revisión para determinar cuándo un envío de una publicación está apto o no para su archivo en el repositorio. Este mecanimos recibe el nombre de "Workflow" y básicamente define un conjunto de pasos a seguir. Cuando estos pasos son ejecutados sin interrupción hasta el final, entonces el envío es archivado en el repositorio.

Existen 2 variante para la implementación del Workflow en DSpace: "Legacy 3-step Workflow" y el "XMLWorkflow". SEDICI viene configurado para utilizar el "XMLWorkflow", aunque en el código fuente de DSpace, el "Legacy 3-step Workflow" viene activado por defecto.

XMLWorkflow

El principal objetivo del XMLWorkflow es crear una solución flexible de configuración, basada en pasos, roles y flujos de ejecucion. Esta variante permite a un desarrollador implementar pasos y flujos de ejecución arbitrarios. A diferencia del antiguo modelo de Workflow en DSpace (basado en 3 pasos únicamente), aquí pueden existir una indefinida cantidad de pasos a ejecutar.

Archivos de configuración

Para verificar si el XMLWorkflow se encuentra activado, verificar que la siguiente configuración se encuentre de éste modo en el archivo xmlui.xconf:

<!-- =========================
     Approval Workflow Systems
     ========================= -->
<!-- By default, DSpace uses a legacy 3-step approval workflow for new submissions -->
<!-- <aspect name="Original Workflow" path="resource://aspects/Workflow/" /> -->

<!-- If you prefer, a Configurable XML-based Workflow is available. To enable it, you can
     uncomment the below aspect and comment out the "Original Workflow" aspect above.
     PLEASE NOTE: in order to use the configurable workflow you must also run the
     database migration scripts as detailed in the DSpace Documentation -->
<aspect name="XMLWorkflow" path="resource://aspects/XMLWorkflow/" />

Además, la siguiente propiedad en el archivo workflow.cfg debe estar configurada:

workflow.framework=xmlworkflow
workflow.xml

Éste es el principal archivo de configuración del XMLWorflow.

<?xml version="1.0" encoding="UTF-8"?>
<wf-config>
    <workflow-map>
        <name-map collection="default" workflow="default"/>
        <name-map collection="11746/2" workflow="autoarchive"/>
    </workflow-map>

	   <workflow start="UNER-ADMIN_review" id="autoarchive">
      		<roles>
   			      <role id="Administrador_UNER" name="UNER-ADMIN" scope="repository" description="Rol asigando para las personas encargadas de gestionar el repositorio, principalmente a partir de la carga."/>
		      </roles>
		      <step id="UNER-ADMIN_review" role="Administrador_UNER" userSelectionMethod="claimaction">
			         <actions>
 				           <action id="changecollection"/>
				            <action id="editaction"/>
			         </actions>
		      </step>
   	</workflow>

	   <workflow start="UNER-ADMIN_review" id="default">
		      <roles>
			         <role id="Administrador_UNER" name="UNER-ADMIN" scope="repository" description="Rol asigando para las personas encargadas de gestionar el repositorio, principalmente a partir de la carga."/>
		      </roles>
		      <step id="UNER-ADMIN_review" role="Administrador_UNER" userSelectionMethod="rejectrole">
			         <actions>
				            <action id="editaction"/>
         			</actions>
		      </step>
	   </workflow>
</wf-config>
<workflow-map>

Acá se definen el mapeo de colecciones a workflows. Al igual que en el Submission, existe un mapeo genérico llamado workflow="default" que mapea con cualquier colección que no tenga definido un mapeo específico. También se pueden definir mapeos específicos para colecciones particulares, como la de autoarchivo con handle 11746/2.

<workflow>

En estos elementos se definen los pasos a ejecutar en un workflow y el flujo de ejecución. Un workflow consta de un nombre (atributo name) y de una indicación del paso inicial (atributo start).

<step>

Dentro de cada workflow se pueden escribir la serie de pasos a ejecutar, y el orden de ejecución no depende del orden de aparición en este archivo, sino del flujo definido. Un paso consta de:

  • id: string que identifica al paso.
  • role: define qué conjunto de usuarios podría ejecutar este paso. Cuando alguno de todo el conjunto de usuarios posibles se le adjudica la ejecución del paso, entonces este paso deja de ser visible para el resto de los usuarios hasta que éste último termine de ejecutarlo.
  • userSelectionMethod: define cómo los usuarios derivados del "role" pueden interactuar con el paso actual, por ejemplo, la interacción clásica es la elección del paso por algún usuario desde un taskpool.
  • nextStep: si la ejecución de este paso termina correctamente, este atributo indica el paso siguiente a ejecutar.
  • <alternativeOutcome>: desde acá también se puede definir el próximo paso a ejecutarse, pero en esta sección se puede determinar el siguiente paso a ejecutar según el código de salida resultante de la ejecución del paso actual (a través del atributo status).
<actions>

Son la unidades básicas de ejecución dentro de un paso. Cada acción son realizadas de forma automáticas o mediante un usuario. Una vez que un usuario se adjudica la ejecución de un paso, pasará a ejecutar todas sus acciones

<roles>
<role id="Administrador_UNER" name="UNER-ADMIN" scope="repository" description="Rol asigando para las personas encargadas de gestionar el repositorio, principalmente a partir de la carga."/>

Este elemento indica una correspondencia con algún grupo o entidad en el sistema, quedando determinado a traves del atributo scope principalmente, junto a otro atributos más según el tipo de scope. Existen 3 tipos de scope:

  1. repository: se buscará en el sistema un Grupo con el mismo nombre que el atributo 'name'. Si existen un grupo con éste nombre, el step se ejecutará dejando la tarea de revisión en el taskpool de los miembros del Grupo seleccionado desde el role.
  2. collection: se buscará la entidad/objeto CollectionRole asociado a la colección en donde se quiere agregar el ítem. El identificador del CollectionRole a buscar debe ser el mismo que el atributo 'id' configurado en el role. Si existen un CollectionRole con éste identificador, el step se ejecutará dejando la tarea de revisión en el taskpool de los miembros del CollectionRole seleccionado desde el role.
  3. item

CollectionRole explanation.

Para más información, ir a la página de Configurable Workflow en el wiki de DSpace.

Importación / exportación de metadatos

Existen dos formas para exportar e importar metadatos, vía interface web o por línea de comandos.

Exportación de metadatos

  • Web

    • Loguearse como usuario Administrador
    • Navegar a la Comunidad o Colección a exportar a CSV.
    • Click en "Exportar metadatos" en el menú "Contexto" en el navbar

  • Por línea de comandos a través del comando [dspace]/bin/dspace metadata-export con flag:

    • -f o --file
      • Requerido. Nombre del archivo CSV resultante.
    • -i o --id
      • Handle del Item, Colección o Comunidad; o ID de la base de datos a exportar. Si no se especifica se exportan todos los items.
    • -a o --all
      • Incluye todos los metadatos que normalmente no son modificados o aquellos que se configuraron en [dspace]/config/modules/bulkedit.cfg para que sean ignorados en la exportación.

Importación de metadatos

  • Web
    • Editar archivo CSV correspondiente
    • Loguarse como usuario Administrador
    • Click en "Importar metadatos" y seleccionar archivo CSV
    • Luego de subir el archivo CSV, si no hay ningun error, se mostraron los cambios a realizarse.

Por defecto se permiten importar 1000 items. Para cambiar esta configurarción editar la propiedad bulkedit.gui-item-limit en bulkedit.cfg

  • Por línea de comandos a través del comando [dspace]/bin/dspace metadata-import con flag:
    • -f o --file:
      • Requerido. Nombre del archivo CSV a importar.
    • -s o --silent
      • Modo silencioso. Esta función no pregunta si uno quiere hacer los cambios.
    • -e o --email
      • Requerida para agregar items. Email del usuario responsable de importar los items.
    • -w o --workflow
      • Cuando se importan items, estos se agregan al workflow para revisión en la colección correspondiente.
    • -n o --notify
      • Cuando se agregan items usando el flag -w, se envían emails de notificación a sus responsables.

Formato de CSV

La primera columna de el CSV debe definir los metadatos a importar. La primera columna debe ser la de "id" mientras que el resto de las otras columnas son opcionales. Estas últimas deben contener el nombre del metadato.

Ejemplo:

id,collection,dc.title,dc.contributor,dc.date.issued,etc,etc,etc.

Las filas que le siguen, se deben ver de la siguiente manera

350,2292,Item title,"Perez, Juan",2008

Si se quieren almacenar múltiples valores, estos se pueden separar mediante '||' (u otro caracter que uno haya definido en bulkedit.cfg )

Ejemplo:

Caballos||Perros||Gatos

Mas info en Dspace - Batch Metadata Editing

Desarrollado por el repositorio institucional de la Universidad Nacional de La Plata SEDICI.

SEDICI

Add a custom sidebar
Clone this wiki locally