Entidades Configurables

Introducción

Los usuarios de DSpace han expresado la necesidad de que DSpace ofrezca un mayor soporte para distintos tipos de objetos digitales relacionados con publicaciones de acceso abierto, como autores/perfiles de autor, conjuntos de datos, etc. Las Entidades Configurables están diseñadas para satisfacer esa necesidad.

En DSpace, una Entidad es un tipo especial de Ítem que frecuentemente tiene Relaciones con otras Entidades. Desglosándolo con más detalle…

• Entidad: Toda Entidad es un Ítem.
  • Esto significa que deben pertenecer a una Colección, al igual que un Ítem normal. (Los objetos Comunidad y Colección no se modifican ni se ven afectados por las Entidades).
  • Los Ítems normales siguen siendo el tipo de Ítem "predeterminado" y no se han modificado. Por lo tanto, no todo Ítem es una Entidad.
  • Dado que las Entidades son Ítems, pueden utilizarse de inmediato en los procesos de envío y flujo de trabajo, importación/exportación por lotes, OAI-PMH, etc.
• Tipo de Entidad (o Ítem): Todas las Entidades tienen un campo de metadatos "dspace.entity.type" que define su "type" de Entidad/Ítem. Por ejemplo, este tipo puede ser "Persona", "Proyecto", "Publicación", "Revista", etc. Es altamente visible en la Interfaz de Usuario como una etiqueta (label).
• Relaciones: Basándose en ese "tipo" (type), una Entidad puede estar relacionada con otras Entidades mediante una Relación. Un tipo de Entidad puede admitir varios tipos de relación a la vez. Ejemplos de tipos de relación incluyen "isPersonOfProject" o "isPublicationOfAuthor". Estos tipos de relación se nombran en función del "tipo" de Entidad (como probablemente se pueda notar). Las relaciones también aparecen en las Entidades como metadatos utilizando el esquema "relation".
• Metadatos Virtuales: Las Entidades de diferentes tipos también pueden tener visualizaciones personalizadas en la Interfaz de Usuario. Estas visualizaciones pueden incluir dinámicamente metadatos de Entidades relacionadas. Por ejemplo, una entidad de tipo Publicación puede mostrarse en la Interfaz de Usuario con el nombre del autor extraído dinámicamente desde una entidad Persona relacionada. Los metadatos "aparecen" como si fueran parte de la Entidad que se está visualizando, pero en realidad se obtienen dinámicamente a través de la Relación.

Las Entidades y sus Relaciones también son completamente configurables. DSpace proporciona algunos modelos de ejemplo listos para usar, que puedes utilizar directamente o adaptar según tus necesidades.

El modelo de Entidades también presenta similitudes con el Portland Common Data Model (PCDM), en el que una Entidad se corresponde aproximadamente con un "pcdm:Object" y las Comunidades y Colecciones existentes se corresponden aproximadamente con un "pcdm:Collection". Sin embargo, en este momento, las Entidades en DSpace se enfocan más en construir una estructura de grafo de relaciones, en lugar de una estructura en árbol.

Modelos de Entidades Predeterminados

Actualmente, DSpace incluye los siguientes modelos de Entidades, ambos definidos en el archivo [dspace]/config/entities/relationship-types.xml.Estos modelos de Entidades no se utilizan de forma predeterminada, pero pueden habilitarse como se describe a continuación.

Entidades de Investigación

Las Entidades de Investigación incluyen Person, OrgUnit, Project y Publication. Estas permiten crear perfiles de autor (Person) en DSpace y relacionar a esas personas con sus departamentos (OrgUnit), proyectos financiados (Project) y trabajos académicos (Publication).

• Cada publication puede estar vinculada a projects, people y org units.
• Cada person puede estar vinculada a projects, publications y org units.
• Cada project puede estar vinculado a publications, people y org units.
• Cada org unit puede estar vinculada a projects, people y publications.

Revistas

Las Entidades de tipo Journal incluyen Journal, Journal Volume, Journal Issue y Publication (artículo). Permiten representar más fácilmente una jerarquía de revista dentro de DSpace, comenzando con la revista general (Journal), que consta de múltiples volúmenes (Volumes), y cada volumen contiene múltiples ediciones (Issues). Luego, las ediciones se vinculan con todos los artículos (Publications) que formaron parte de esa edición de la revista.

NOTA: este modelo incluye la misma entidad "Publication" que el modelo de Entidades de Investigación descrito anteriormente. Esta superposición de entidades permite vincular un artículo (Publication) tanto con su autor (Person) como con la edición de la revista (Journal Issue) en la que fue publicado.

Habilitación de Entidades

De forma predeterminada, las Entidades no se utilizan en DSpace. Sin embargo, como se describió anteriormente, hay varios modelos disponibles listos para usar que pueden habilitarse opcionalmente.

1. Configura tu modelo de entidad (opcionalmente)

Como se describió anteriormente, DSpace proporciona dos modelos de entidad predeterminados definidos en [dspace]/config/entities/relationship-types.xml. Estos modelos pueden utilizarse tal como están o modificarse.

También puedes diseñar tu propio modelo desde cero (consulta la sección “Diseñar tu propio modelo” más abajo). Por lo tanto, si lo prefieres, puedes comenzar modificando el archivo relationship-types.xml o crear tu propio modelo basado en el archivo relationship-types.dtd.

2. Importar el modelo de entidad en la base de datos

Para habilitar un modelo de entidad definido, DEBE importarse en la base de datos de DSpace Esto se logra utilizando el script "initialize-entities". El siguiente ejemplo importará los modelos de entidad "listos para usar" en su instalación de DSpace.

# El comando -f requiere la ruta completa a un archivo de configuración del modelo de Entidades.
[dspace]/bin/dspace initialize-entities -f [dspace]/config/entities/relationship-types.xml

Si ya existe una Entidad (con el mismo nombre de tipo), se actualizará con cualquier nueva relación definida en relationship-types.xml.

Si no existe una Entidad (con el mismo nombre de tipo), se creará el nuevo tipo de Entidad junto con sus relaciones definidas en relationship-types.xml.

Una vez importado en la base de datos, la estructura general es la siguiente:

• Todos los Tipos de Entidad válidos se almacenan en la tabla de base de datos "entity_type".
• Todas las definiciones de tipos de Relación se almacenan en la tabla "relationship_type".
• Todas las Relaciones entre entidades se almacenan en la tabla "relationship".
• Las Entidades en sí mismas se almacenan junto con los Ítems en la tabla 'item'. Cada Entidad debe tener un campo de metadato "dspace.entity.type" cuyo valor sea un Tipo de Entidad válido (de la tabla "entity_type").

Tenga en cuenta que su modelo de Entidad actualmente habilitado está definido en su base de datos, y NO en el archivo "relationship-types.xml". Cada vez que desee actualizar su modelo de datos, debe actualizar/crear una configuración (como relationship-types.xml) y volver a ejecutar el comando "initialize-entities".

3. Configurar colecciones para cada tipo de entidad

Dado que todas las Entidades son Ítems, deben pertenecer a una Colección. Por lo tanto, la forma recomendada de crear formularios de envío diferentes para cada tipo de Entidad (por ejemplo, Person, Project, Journal, Publication, etc.) es asegurarse de crear una Colección para cada tipo de Entidad (ya que cada Colección puede tener un formulario de envío personalizado).

1. Cree al menos una Colección para cada tipo de Entidad que requiera un formulario de envío personalizado. Por ejemplo, una Colección para entidades de tipo "Person" y otra separada para entidades de tipo "Publication".
2. Edite la Colección. En la página "Editar metadatos", use el menú desplegable "Entity Type" para seleccionar el tipo de Entidad de esta Colección.
   1. Esta selección de "Entity Type" asegurará que cada Ítem enviado a esta colección se asigne automáticamente a ese tipo de Entidad. Así, se vincula esta Colección con ese tipo de Entidad (es decir, no se pueden enviar otros tipos de Entidad a esta Colección).
      1. NOTA: Actualmente no se puede modificar el tipo de Entidad una vez establecido. Esto se debe a que cambiarlo puede causar comportamientos inesperados (o errores) con envíos en curso (ya que estos seguirán utilizando el tipo de Entidad anterior). Si realmente necesita modificar el tipo de Entidad, puede hacerlo cambiando el valor de metadato "dspace.entity.type" en el objeto Colección. Por ahora, esta modificación debe realizarse a nivel de base de datos.
   2. NOTA: En la versión 7.0 no existía este menú desplegable "Entity Type". En esa versión, era necesario crear un "Template Item" desde esa página. En dicho Template Item, se debe agregar un solo campo de metadato "dspace.entity.type" con un valor que coincida con el nombre del tipo de Entidad (por ejemplo: Publication, Person, Project, OrgUnit, Journal, JournalVolume, JournalIssue). Este valor distingue mayúsculas y minúsculas y debe coincidir con el nombre del tipo de Entidad definido en relationship-types.xml.
      
      1. A partir de la versión 7.1 (y superiores), si previamente creó un Template Item en 7.0, el valor del campo "dspace.entity.type" se migrará automáticamente al menú desplegable "Entity Type" (mediante una migración en la base de datos).
3. En la página de edición de la Colección, cambie a la pestaña "Assign Roles" y cree un grupo "Submitters". Agregue a todas las personas que deberían poder enviar/crear este nuevo tipo de Entidad.
   1. Si solo desea que los Administradores puedan crear este tipo de Entidad, puede omitir este paso. Los Administradores pueden enviar ítems a cualquier colección.
4. Si desea ocultar esta Colección, puede optar por hacerla visible únicamente para ese mismo grupo de Submitters (o para Administradores). Esto no oculta las Entidades de la búsqueda o navegación, pero sí oculta la Colección en sí.
   1. En la página de edición de la Colección, cambie a la pestaña "Authorizations".
   2. Agregue una nueva autorización de tipo TYPE_CUSTOM, restringiendo el permiso "READ" al grupo de Submitters creado anteriormente (o a los Administradores si no hay grupo de Submitters). También puede añadir múltiples políticas "READ" según sea necesario. ADVERTENCIA: El grupo Submitters debe tener privilegios de "READ" para poder enviar/crear nuevas Entidades.
   3. Elimine la política de lectura predeterminada que otorga permisos a "Anonymous".
   4. Si desea que las Entidades sigan siendo públicamente accesibles, asegúrese de que la política DEFAULT_ITEM_READ esté configurada como "Anonymous".

Cada una de estas Colecciones debe estar contenida en una Comunidad. Lo más sencillo sería crear una nueva Comunidad de nivel superior, ubicar allí tus Colecciones de entidades y (opcionalmente) ocultar la Comunidad de manera similar a como se oculta una Colección, como se explicó anteriormente.

Evidentemente, la forma en que organices tus Tipos de Entidad en Colecciones depende de ti. Puedes crear una sola Colección para todas las Entidades de ese tipo (por ejemplo, una colección de “Perfiles de Autores” podría ser donde se presenten/almacenen todas las Entidades del tipo “Persona”). O bien, podrías crear múltiples Colecciones para cada Tipo de Entidad (por ejemplo, cada Departamento de tu Universidad podría tener su propia Comunidad y, dentro de esta, una Colección de “Perfiles del Personal” donde se almacenen todas las Entidades “Persona” de ese departamento). A continuación, se muestran algunos ejemplos de estructuras.

Ejemplo de estructura basada en los departamentos:

• Departamento de Arquitectura
• Programa de Tecnología de la Edificación
• Tesis - Departamento de Arquitectura
• Departamento de Biología
• Tesis - Biología
• Personas
• Proyectos

O

• Departamento de Arquitectura
• Programa de Tecnología de la Edificación
• Tesis - Departamento de Arquitectura
• Personas del Departamento de Arquitectura
• Proyectos en el Departamento de Arquitectura
• Departamento de Biología
• Tesis - Biología
• Personas en el Departamento de Biología
• Proyectos en el Departamento de Biología

Estructura de ejemplo basada en el tipo de publicación:

• Libros
• Capítulo de libro
• Volumen Editado
• Monografía
• Tesis
• Tesis de Licenciatura
• Tesis Doctoral
• Tesis de Habilitación
• Tesis de Maestría
• Personas
• Proyectos

4. Configurar formularios de envío para cada tipo de entidad.

Ya deberías haber creado colecciones específicas para cada entidad en el paso anterior. Ahora, solo necesitamos vincular esas colecciones con los procesos de envío correspondientes a cada tipo de entidad.

En el backend, ahora deberás modificar el archivo [dspace]/config/item-submission.xml para "mapear" esta colección (o colecciones) al proceso de envío para este tipo de entidad.

• DSpace incluye formularios de envío de ejemplo para cada tipo de entidad.
  • El <submission-process> de ejemplo está definido en el archivo item-submission.xml y se nombra según el tipo de entidad (por ejemplo: Publication, Person, Project, etc.).
  • Los campos de metadatos capturados para cada entidad se definen en un paso personalizado dentro del archivo submission-forms.xml, y se nombran con el formato "[entityType]Step" (donde el tipo de entidad está en camelCase). Por ejemplo: "publicationStep", "personStep", "projectStep".
• Opcionalmente, puedes modificar esos formularios de envío por ejemplo. Consulta la sección Submission User Interface para obtener sugerencias y consejos sobre cómo personalizar los archivos item-submission.xml o submission-forms.xml.

• A partir de la versión 7.6, puedes simplemente mapear cada tipo de entidad a un formulario de envío específico de la siguiente manera en tu archivo item-submission.xml (Esta sección ya existe, solo debes descomentarla)

  <name-map collection-entity-type="Publication" submission-name="Publication"/>
  <name-map collection-entity-type="Person" submission-name="Person"/>
  <name-map collection-entity-type="Project" submission-name="Project"/>
  <name-map collection-entity-type="OrgUnit" submission-name="OrgUnit"/>
  <name-map collection-entity-type="Journal" submission-name="Journal"/>
  <name-map collection-entity-type="JournalVolume" submission-name="JournalVolume"/>
  <name-map collection-entity-type="JournalIssue" submission-name="JournalIssue"/>

  • ADVERTENCIA: Si creas una nueva Colección utilizando un tipo de entidad específico, actualmente debes reiniciar tu contenedor de servlets (por ejemplo, Tomcat) para que la configuración del formulario de envío surta efecto en la nueva Colección. Esto se debe a un error conocido en el que los formularios de envío se almacenan en caché hasta que se reinicia el contenedor de servlets. Consulta el ticket del problema aquí: https://github.com/DSpace/DSpace/issues/7985

  • En la versión 7.5 y anteriores, era necesario mapear manualmente el handle de cada Colección a un formulario de envío en el archivo item-submission.xml. Debes vincular el handle de tu Colección (que puedes encontrar en la página principal de la Colección) al formulario de envío que deseas que utilice. En el siguiente ejemplo, se ha mapeado una única Colección para cada uno de los tipos de entidad incluidos por defecto.

    <name-map collection-handle="123456789/5" submission-name="Publication"/>
    <name-map collection-handle="123456789/6" submission-name="Person"/>
    <name-map collection-handle="123456789/7" submission-name="Project"/>
    <name-map collection-handle="123456789/8" submission-name="OrgUnit"/>
    <name-map collection-handle="123456789/28" submission-name="Journal"/>
    <name-map collection-handle="123456789/29" submission-name="JournalVolume"/>
    <name-map collection-handle="123456789/30" submission-name="JournalIssue"/>

Una vez que hayas completado tus modificaciones al proceso de envío, deberás reiniciar rápidamente Tomcat (o tu contenedor de servlets) para recargar la configuración actual.

4.1 Uso del atributo collection-entity-type para formularios de envío predeterminados por tipo de entidad

Como alternativa al handle de una colección, se pueden usar los tipos de entidad como un atributo. En lugar de especificar el handle de la colección, deberás usar el atributo collection-entity-type y el tipo de entidad correspondiente (por ejemplo: Person, Project). Ten en cuenta que las Colecciones con el tipo de entidad deben haber sido creadas previamente.

<name-map collection-entity-type="Publication" submission-name="Publication"/>
<name-map collection-entity-type="Person" submission-name="Person"/>
<name-map collection-entity-type="Project" submission-name="Project"/>
<name-map collection-entity-type="OrgUnit" submission-name="OrgUnit"/>
<name-map collection-entity-type="Journal" submission-name="Journal"/>
<name-map collection-entity-type="JournalVolume" submission-name="JournalVolume"/>
<name-map collection-entity-type="JournalIssue" submission-name="JournalIssue"/>

Una vez que hayas completado tus modificaciones al proceso de envío, deberás reiniciar rápidamente Tomcat (o tu contenedor de servlets) para que se recargue la configuración actual.

5. Configurar flujo de trabajo para cada tipo de entidad (opcionalmente)

El flujo de trabajo de DSpace puede utilizarse para revisar todos los objetos en el Modelo de Objetos, ya que estos objetos son todos Ítems, y se pueden usar colecciones separadas. El flujo de trabajo utilizado, por ejemplo, para un objeto de tipo Person puede configurarse de manera idéntica al de una publicación, diferente al de una publicación, o no usar ningún flujo de trabajo en absoluto.

Consulta Configurable Workflow para obtener más información sobre cómo configurar flujos de trabajo por Colección.

6. Configurar metadatos virtuales para mostrar en entidades relacionadas (opcionalmente)

Los metadatos virtuales son metadatos que se determinan dinámicamente (en el momento del acceso) con base en la relación de una entidad con otras entidades. Un ejemplo básico es mostrar el nombre de una entidad Person en el campo "dc.contributor.author" de una entidad Publication relacionada. Ese campo "dc.contributor.author" en realidad no existe en la Publication, sino que se agrega dinámicamente como metadato virtual simplemente porque la Publication está vinculada con la Person (a través de una relación).

Los metadatos virtuales son configurables para todas las entidades y todas las relaciones. DSpace incluye una configuración predeterminada para su modelo de entidades por defecto, la cual se encuentra en [dspace]/config/spring/api/virtual-metadata.xml. En ese archivo de configuración de Spring Bean, encontrarás un mapa que vincula cada tipo de relación con un campo de metadato y su valor. A continuación, se presenta un resumen de cómo funciona:

• El bean "org.dspace.content.virtual.VirtualMetadataPopulator" mapea cada tipo de relación (definido en relationship-types.xml) a una definición <util:map> (con un ID específico) que también se encuentra en el archivo virtual-metadata.xml.

  <!-- Por ejemplo, la relación isAuthorOfPublication está vinculada a un mapa con el ID "isAuthorOfPublicationMap" -->
  <entry key="isAuthorOfPublication" value-ref="isAuthorOfPublicationMap"/>

• Esa definición de <util:map> especifica qué campo de metadato de DSpace almacenará el metadato virtual. Además, enlaza con el bean que definirá dinámicamente el valor de dicho campo de metadato.

  <!-- En este ejemplo, isAuthorOfPublication se mostrará en el campo "dc.contributor.author" -->
  <!-- El *valor* de ese campo será definido por el bean "publicationAuthor_author" -->
  <util:map id="isAuthorOfPublicationMap">
      <entry key="dc.contributor.author" value-ref="publicationAuthor_author"/>
  </util:map>

• Un bean con ese ID define luego el valor del campo, basado en la entidad relacionada. En este ejemplo, estos campos se obtienen de la entidad Person relacionada y se concatenan. Si la persona tiene "person.familyName=Jones" y "person.givenName=Jane", entonces el valor de "dc.contributor.author" en la Publication relacionada se establecerá dinámicamente como "Jones, Jane".

   <bean class="org.dspace.content.virtual.Concatenate" id="publicationAuthor_author">
      <property name="fields">
          <util:list>
              <value>person.familyName</value>
              <value>person.givenName</value>
              <value>organization.legalName</value>
          </util:list>
      </property>
      <property name="separator">
          <value>, </value>
      </property>
      <property name="useForPlace" value="true"/>
      <property name="populateWithNameVariant" value="true"/>
  </bean>

Si los metadatos virtuales predeterminados te parecen adecuados, no es necesario realizar cambios. Si realizas alguna modificación, asegúrate de reiniciar Tomcat para actualizar las definiciones de los beans.

Diseñar tu propio modelo de entidades

Cuando se utiliza un modelo de entidades diferente, dicho modelo debe ser configurado y cargado en tu repositorio.

Pensando en el modelo de objetos

Primer paso: identificar los tipos de entidad

• ¿Qué tipos de objetos deseas que se conviertan en ítems? Por ejemplo: Person, Publication, JournalVolume.
• Ten cuidado de no confundir un tipo con una relación. Person es un tipo; un autor es una relación entre la publicación y la persona.

Segundo paso: identificar los tipos de relación

• ¿Qué tipos de relación deseas crear entre los ítems de entidad identificados en el paso anterior? Por ejemplo: isAuthorOfPublication, isEditorOfPublication, isProjectOfPublication, isOrgUnitOfPerson, isJournalIssueOfPublication.
• Se pueden crear múltiples relaciones entre los mismos dos tipos de entidad: isAuthorOfPublication, isEditorOfPublication.
• Las relaciones son automáticamente bidireccionales, por lo que no es necesario preocuparse por si deseas mostrar los autores de una publicación o las publicaciones de un autor.

Tercer paso: visualiza tu modelo

• Al crear un esquema de tu modelo, podrás verificar rápidamente si falta algo.

Configuración del modelo de objetos

Configura el modelo en relationship-types.xml.

• De manera similar al archivo relationship-types.xml predeterminado, configura un tipo de relación por cada conexión entre dos tipos de entidad.
• Incluye los nombres de los dos tipos de entidad que están siendo conectados.
• Determina un nombre claro y no ambiguo para la relación en ambas direcciones.
• Opcionalmente: define la cardinalidad (mínimo/máximo de ocurrencias) para las relaciones.
• Opcionalmente: define el comportamiento predeterminado para la copia de metadatos si la relación es eliminada.

Configuración de los campos de metadatos

Determinación de los campos de metadatos a utilizar

• Dublin Core funciona para publicaciones, pero no para una Person, JournalVolume, etc.
• Existen muchos estándares que pueden configurarse fácilmente: schema.org , euroCRIS, DataCite, entre otros.
• Elige un esquema que se ajuste a tus necesidades.

Configura los formularios de envío

• Agrega un formulario en submission-forms.xml para cada tipo de entidad, incluyendo los campos de metadatos correspondientes.
• Consulta también la documentación de la Submission User Interface.
• Configura qué relaciones deben crearse

Configuración de las páginas de visualización de ítems

• La configuración de metadatos no es exclusiva de las entidades configurables.
• Al igual que con otras personalizaciones de las páginas de visualización de ítems, configura en Angular qué campos de metadatos se mostrarán y con qué etiqueta. Se puede crear una plantilla por tipo de entidad.
• La visualización de relaciones es similar a la configuración de metadatos.
• De manera similar: configura en Angular qué relaciones se deben mostrar y con qué etiqueta.

Configuración de metadatos virtuales

• La relación isAuthorOfPublication puede mostrarse para el ítem Publication como dc.contributor.author.
• La relación isOrgUnitOfPerson puede mostrarse para el ítem Person como organization.legalName.
• Esto puede configurarse en el archivo virtual-metadata.xml .

Configuración de discovery

• Configura los facets, filtros, opciones de ordenamiento de discovery, etc.
• Los facets para una Persona pueden ser el cargo, la organización, el proyecto, etc.
• Los filtros para una Persona pueden ser person.familyName, person.givenName, etc.

Detalles Técnicos Adicionales

El documento original de diseño de Entities está disponible en Google Docs en: https://docs.google.com/document/d/1wEmHirFzrY3qgGtRr2YBQwGOvH1IuTVGmxDIdnqvwxM/edit

Estamos trabajando en migrar esa información a este espacio Wiki como su ubicación final, pero actualmente algunos detalles técnicos solo existen en ese documento.

También se presentó una charla sobre Configurable Entities en DSpace 7 at OR2021.

Relaciones tilted

Las relaciones tilted son una funcionalidad predeterminada de DSpace 7, desarrollada en https://github.com/DSpace/DSpace/pull/3134

Están diseñadas para mejorar el rendimiento cuando una entidad tiene miles de relaciones. Evitan cargar las relaciones en la dirección configurada a menos que se solicite explícitamente su recuperación. Se utilizan principalmente en configuraciones donde hay tantos ítems relacionados que no tiene sentido listarlos todos, y en su lugar se hacen accesibles mediante búsqueda. Al utilizar relaciones tilted, estas configuraciones pueden obtener una mejora significativa en el rendimiento.

Este comportamiento puede explicarse más fácilmente con un ejemplo de la vida real.

Caso de uso: relación entre OrgUnit y Publication

DSpace 7 tiene un tipo de relación isOrgUnitOfPublication definido por defecto. Cuando hay unidades organizativas (OrgUnits) con miles o más publicaciones vinculadas a ellas, la relación isOrgUnitOfPublication predeterminada puede presentar problemas de rendimiento.

Al configurar la relación como tilted hacia la izquierda —donde el tipo de entidad izquierda es Publication y el tipo de entidad derecha es OrgUnit— estás especificando que la publicación aún debe cargar las OrgUnits relacionadas (que se espera sean pocas), pero la OrgUnit no debe cargar todas las Publications relacionadas.

Las implicaciones de esta configuración son:

• Al revisar los metadatos de la OrgUnit, no se poblará el metadato virtual relation.isPublicationOfOrgUnit.

• Al revisar las relaciones de la OrgUnit, no se devolverán las relaciones basadas en este tipo.

• Pero al utilizar el componente Angular de búsqueda de relaciones (relationship search), las Publications relacionadas aún pueden mostrarse en la página del ítem OrgUnit.

• También es posible utilizar el componente Angular de lista de relaciones (relationship list) en la página del ítem OrgUnit sin impacto en el rendimiento, aunque para las entidades OrgUnit, una lista paginada no aporta mucho valor.

• Al revisar los metadatos de la Publication, se seguirá poblando el metadato virtual relation.isOrgUnitOfPublication, y también se podrán poblar otros metadatos virtuales, como el nombre de la OrgUnit en la publicación.

• Al revisar las relaciones de la Publication, se incluirán las relaciones basadas en este tipo.

• El componente Angular de lista de relaciones en la página del ítem Publication se puede utilizar y no tendrá ningún problema.

Impacto de las relaciones tilted

Se realizaron pruebas de rendimiento en https://github.com/DSpace/DSpace/pull/3134 (algunas pruebas fueron específicas de mejoras independientes de las relaciones tilted, y que ya se aplican en todos los casos).

En general:

• Recuperar la representación REST del ítem que incluye metadatos virtuales, al utilizar relaciones tilted en ítems con 600 relaciones, redujo la duración al 5% (es decir, una reducción del 95% en el tiempo empleado).

• Crear nuevas relaciones al utilizar relaciones tilted en ítems con 1000 relaciones o más también redujo la duración, aunque pruebas más recientes revelaron que esta se redujo al 25% (es decir, una reducción del 75% en el tiempo empleado).

Al utilizar relaciones tilted, existen entornos en producción con entidades individuales que tienen más de 40,000 relaciones utilizando un solo tipo de relación. Gracias a las relaciones tilted, esta configuración no afecta el rendimiento.

Utilizando la relación de OrgUnit a Person, es posible tener una OrgUnit con 40,000 entidades Person, y los metadatos virtuales de la entidad Person contienen el nombre, ID, etc., de la OrgUnit.

Soporte de Versionado

Las entidades de DSpace son totalmente compatibles con el versionado. En general, esto funciona como con cualquier otro ítem. Por ejemplo, al crear una nueva versión de un ítem, se crea un nuevo ítem y todos los valores de metadatos del ítem anterior se copian en el nuevo. Se ha prestado especial atención al versionado de las relaciones entre entidades.

Ejemplo del estado más reciente de una relación (detalles técnicos)

Para comprender cómo funciona el versionado entre entidades con relaciones, revisemos el siguiente ejemplo:

Considera el Volumen 1.1 (lado izquierdo) y el Número 1.1 (Issue) (lado derecho). Ambos están archivados y son la primera versión. Nota que en la flecha, que representa la relación entre el volumen y el número, se indican dos valores booleanos y dos números.

• El valor booleano del lado (v) es verdadero si y solo si el volumen 1.1 es la versión más reciente que es relevante para el número 1 (aunque puede que exista el volumen 1.2, la segunda versión del volumen 1). Esto significa que en la página del ítem del número 1.1, debe mostrarse un enlace hacia la página del ítem del volumen 1.1. También implica que al buscar (el UUID de) issue 1.1, debe aparecer el volumen 1.1.
• El valor booleano del lado (i) es verdadero si y solo si el número 1.1 (issue) es la versión más reciente que es relevante para el volumen 1.1 (aunque puede que exista issue 1.2, la segunda versión del número 1). Esto significa que en la página del ítem del volumen 1.1 debe mostrarse un enlace hacia la página del ítem del número 1.1. También implica que al buscar (el UUID de) volumen 1.1, debe aparecer issue 1.1.
• El número del lado (v) indica la posición en la que aparecerán los metadatos virtuales que representan esta relación (si existen) en el volumen 1.1. Por ejemplo, usando la configuración predeterminada en virtual-metadata.xml, el campo de metadatos publicationissue.issueNumber de issue 1.1 aparecería como el campo publicationissue.issueNumber en el volumen 1.1 en la posición 0 (i.e. como el primer valor de metadato).
• El número del lado (i) indica la posición en la que aparecerán los metadatos virtuales que representan esta relación (si existen) en issue 1.1. Por ejemplo, usando la configuración predeterminada en virtual-metadata.xml, el campo de metadatos publicationvolume.volumeNumber de volumen 1.1 aparecería como el campo publicationvolume.volumeNumber en issue 1.1 en la posición 0 (i.e. como el primer valor de metadato).

Con esta base, veamos qué sucede al crear una nueva versión del volumen 1.1. La nueva versión aún no está archivada, ya que debe editarse primero en la interfaz de envío.

En este momento, al visualizar la página del ítem correspondiente al número 1.1 (issue 1.1), el usuario solo debería ver el volumen 1.1 (ya que el volumen 1.2 aún no está archivado). Al visualizar la página del ítem del volumen 1.1, no habrá cambios: solo aparecerá un enlace al número 1.1. Al visualizar la página del ítem del volumen 1.2 (por ejemplo, como administrador), también aparecerá un enlace al número 1.1.

Tan pronto como el volumen 1.2 se deposita (archiva), el "estado más reciente" tanto del volumen 1.1 como del volumen 1.2 se actualiza. Al visualizar la página del ítem del número 1.1 (issue 1.1), el volumen 1.2 debería ser visible. Al visualizar las páginas de los ítems de los volúmenes, no hay cambios.

Ahora, creemos otra versión del volumen (aún no archivada):

Y después de archivar el volumen 1.3:

¿Qué sucede si creamos una nueva versión del número 1.1 (issue 1.1)?

Solo se copia la relación con el volumen 1.3. Para el número 1.1 (issue 1.1), no se mostraba ninguna relación con los volúmenes 1.1 y 1.2. (Las relaciones aún existen en la base de datos, pero no son visibles en la interfaz de usuario). Para el volumen 1.1, permanece una relación con el número 1.1, pero no debe actualizarse al número 1.2. Para el número 1.2 (issue 1.2), estas relaciones ya no son relevantes, por lo que no se copian.

En las páginas del ítem de los volúmenes 1.1, 1.2 y 1.3, debería verse el número 1.1 (ya que el 1.2 aún no está archivado).

Como el número 1.2 aún no está archivado, todos los volúmenes siguen apuntando al número 1.1. Archivémoslo:

Ahora, en las páginas del ítem de los volúmenes 1.1 y 1.2, deberías ver el número 1.1 (issue 1.1); es el número más reciente en el momento en que esos volúmenes fueron reemplazados por el volumen 1.3. En la página del ítem del volumen 1.3, verás el número 1.3 (issue 1.3). En la página del ítem del número 1.1, aún verás también el volumen 1.3.

Campos de metadatos que representan relaciones

Si observas más de cerca los ítems con relaciones, notarás dos categorías de campos de metadatos que están controlados por DSpace:

• Campos relation.* por ejemplo, relation.isIssueOfJournalVolume en ítems de tipo volumen
• Campos relation.*.latestForDiscovery*, por ejemplo, relation.isIssueOfJournalVolume.latestForDiscovery en ítems de tipo volumen

Los campos de metadatos de la primera categoría (relation.*) contienen todos los UUID de los ítems relacionados que el ítem actual puede ver. Es decir, debe existir una relación entre el ítem actual y el otro ítem, y el otro ítem debe tener el "estado más reciente" para esa relación específica.

Como ejemplo, tomemos el siguiente estado de la sección anterior:

El ítem issue 1.1 contendrá el campo de metadatos relation.isJournalVolumeOfIssue con el valor del UUID del volume 1.3. Los volúmenes 1.1 y 1.2 no se incluyen porque no tienen el "estado más reciente" en las relaciones relevantes.

Los campos de metadatos de la segunda categoría (relation.*.latestForDiscovery) contienen todos los UUID de los ítems para los cuales el ítem actual es visible. Es decir, debe existir una relación entre el ítem actual y el otro ítem, y el ítem actual debe tener el "estado más reciente" para esa relación específica. Estos campos son particularmente importantes para la indexación y la búsqueda, porque permiten mostrar todos los ítems a los que un ítem en particular hace referencia.

Continuando con el ejemplo anterior, issue 1.1 tendrá el campo de metadatos relation.isJournalVolumeOfIssue.latestForDiscovery que contiene los UUID de los volúmenes 1.1 y 1.2.

Dado que issue 1.1 contiene a los volúmenes 1.1 y 1.2 en relation.isJournalVolumeOfIssue.latestForDiscovery, una búsqueda en la página del volumen 1.1 de todas las ediciones que lo contengan mostrará issue 1.1 gracias a esta configuración.

Configurar el versionado para un tipo de entidad

DSpace incluye varios tipos de entidad de ejemplo que admiten versionado de forma predeterminada. A continuación, se presenta una visión general de los requisitos necesarios para que el versionado de entidades funcione correctamente.

1. Al introducir un tipo de relación, asegúrate de añadir cuatro nuevos campos de metadatos en config/registries/relationship-formats.xml. Por ejemplo: relation.isAuthorOfPublication, relation.isAuthorOfPublication.latestForDiscovery, relation.isPublicationOfAuthor y relation.isPublicationOfAuthor.latestForDiscovery.
2. Al introducir un tipo de entidad, filtra los ítems con latestVersion:true en discovery.xml. Esta será la búsqueda predeterminada, lo que garantiza que no se muestren versiones anteriores.
   • Si deseas mostrar todos los ítems relacionados, incluidas las versiones anteriores, puedes crear otra configuración de discovery sin latestVersion:true. Esta debe usarse en las páginas de ítems que muestran los ítems relacionados con el ítem actual mediante la búsqueda de discovery.
   • Los tipos de entidad configurados por defecto incluyen una configuración de discovery <entity-type> y otra configuración <entity-type>Relationships para ese propósito.

Ten en cuenta que el soporte para versionado está habilitado por defecto, pero puede desactivarse configurando versioning.enabled = false en versioning.cfg o local.cfg. Para más detalles sobre el versionado a nivel de ítem, consulta: https://wiki.lyrasis.org/display/DSDOC7x/Item+Level+Versioning.