Fedora Digital Object Model

Fedora cuenta con un modelo de objetos digitales que pueden ser usados para definir y proveer las características esenciales de distintos tipos de contenidos digitales, incluyendo documentos, imágenes, libros electrónicos, objetos de aprendizaje multimedia, conjuntos de datos, metadatos y otros. Este modelo de objetos digital es el bloque de construcción fundamental de la arquitectura de modelos de contenido y de toda la funcionalidad provista por Fedora.

El modelo de objetos digitales de Fedora

(The Fedora Digital Object Model)

Fedora usa un diseño de "Objeto digital compuesto" (compound digital object), el cual agrega uno o más ítem de contenido al mismo objeto digital. Los Ítem de contenido pueden ser de cualquier formato y pueden ser almacenados localmente en el repositorio o externamente y sólo ser referenciados por el objeto digital. El modelo de objeto digital de Fedora es simple y flexible, de esta forma muchos tipos diferentes de objetos digitales pueden ser creados, sin embargo, el carácter genérico de objeto digital Fedora permite que todos los objetos sean administrados de una manera consistente en un repositorio de Fedora.

Una buena discusión acerca del modelo de objetos digitales de Fedora está en un paper reciente publicado en International Journal of Digital Libraries. Mientras algunos detalles de este paper se han vuelto obsoletos para el CMA, por ejemplo: diseminadores, los principios centrales del modelo siguen siendo parte del CMA. El modelo de objeto digital de Fedora es definido en el lenguaje de esquemas XML (ver Fedora Object XML: FOXML). Para más información ver [Introduction to FOXML] en el sistema de información Fedora.

Los componentes básicos de un objeto digital de Fedora son:

• PID: un identificador único y persistente del objeto
• Propiedades del Objeto: Conjunto de propiedades definidas por el sistema que sirven para manejar y seguir el objeto por el sistema.
• Datastream(s): Un Datastream es el elemento en Fedora que representa el contenido

Datastreams

Un Datastream es un elemento de un objeto digital Fedora que representa el contenido de un ítem. Un objeto digital puede tener más de un Datastream. Cada Datastream registra atributos útiles acerca del contenido que representa, tal como el MIME-Type (para verificar compatibilidad en el web) y, opcionalmente, el identificador URI del formato del contenido (del registro de formatos). El contenido representado por el Datastream es tratado como un flujo de bits opaco; corresponde al usuario determinar cómo interpretar el contenido (por ejemplo, data o metadata). El contenido puede ser almacenado internamente en el repositorio Fedora, o almacenado remotamente (en cuyo caso Fedora tiene un puntero al contenido en forma de URL). El modelo de objeto digital de Fedora también soporta el manejo de versiones del contenido del Datastream (ver Fedora Versioning guide).

Cada Datastream tiene un identificador el cual es único dentro del alcance del objeto digital. Fedora reserva cuatro identificadores da Datastream para su uso "DC", "AUDIT", "RELS-EXT", "RELS-INT". Cada objeto digital tiene un Datastream "DC" (Dublin Core) por defecto, el cual contiene metadata acerca del objeto (y creará uno automáticamente si no es entregado). Fedora también mantiene un Datastream especial "AUDIT", que registra un sendero auditable de todos los cambios realizados al objeto, y que no puede ser editado ya que sólo el sistema lo controla. El Datastream "RELS_EXT" es usado principalmente como el lugar para describir las relaciones con otros objetos digitales externos, y el Datastream "RELS-INT" para hacer lo mismo con los objetos internos. Adicionalmente, un objeto digital Fedora puede contener cualquier número de Datastreams personalizados representando contenido definido por el usuario.

Las decisiones acerca de qué contiene un objeto digital Fedora y como configurar sus Datastreams son tomadas en la medida que se va desarrollando el contenido del repositorio. Los ejemplos en este tutorial muestran algunos modelos comunes que usted puede encontrar útiles a la hora de desarrollar su aplicación. Diferentes patrones de Datastream en torno a un "genero" particular. (ej: artículo, libro, conjunto de datos, imágen de museo, objeto de aprendizaje) son conocidos como modelos de contenido en Fedora.

Las propiedades básicas que el modelo de objetos de Fedora define para un Datastream son las siguientes:

• Datastream Identifier : un identificador para el Datastream que es único dentro del objeto digital (pero no necesariamente globalmente único).

• State : {Active, Inactive, Deleted}

• Created Date : el día/hora que el Datastream fue creado (asignado por el servicio del repositorio)

• Modified Date : el día/hora en que el Datastream fue modificado (asignado por el servicio del repositorio)

• Versionable : {true, false}, determina cuando el servicio del repositorio puede versionarlo (por defecto el repositorio versiona todos los Datastreams)

• Label : Una etiqueta descriptiva para el Datastream

• MIME Type : el tipo MIME del Dstastream (requerido)

• Format Identifier : un identificador de formato opcional para Datastream de esquemas emergentes como "PRONOM" y el registro de formatos globales digitales (GDRF).

• Alternate Identifiers : uno o más identificadores alternativos para el Datastream (estos identificadores pueden ser locales o globales como los HANDLES o DOI)

• Checksum : una estampilla de integridad para el contenido del Datastream la cual puede ser calculada usando uno de muchos algoritmos estándar (MDS, SHA-1, ETC.)

• Bytestream Content : el contenido (como recurso Datastream) representado o encapsulado por el Datastream (como documento, imágen digital, video, registro de metadata).

Control Group : la forma en que el Datastream representa o encapsula el contenido, es una de cuatro posibles grupos de control:

• • Internal XML Content - el contenido es almacenado como XML in-line dentro del objeto digital archivo XML.
• • Managed Content - el contenido es almacenado en un repositorio y el objeto digital XML mantiene un identificador interno que puede ser usado para traer el contenido desde el almacenamiento.
• • Externally Referenced Content - el contenido es almacenado fuera del repositorio y el objeto digital XML mantiene una URL que puede ser de-referenciada por el repositorio para traer el contenido desde la ubicación remota. Mientras el contenido del Datastream es almacenado fuera del repositorio Fedora, en tiempo de ejecución, cuando un pedido de acceso para este tipo de Datastream es realizado, el repositorio Fedora usará este URL para traer el contenido desde su ubicación remota, y el repositorio Fedora mediará el acceso al contenido. Esto significa que tras bambalina, Fedora alcanzará el contenido y será servido al cliente solicitando el contenido como si fuera servido directamente por Fedora. Esta es una buena forma de crear objetos digitales que apuntan a contenido distribuidos, pero aún el repositorio está a cargo de servirlos.
• • Redirect Referenced Content - el contenido es almacenado fuera del repositorio y el objeto digital XML mantiene una URL que es usada para re-direccionar al cliente cuando una solicitud de acceso es realizada. El contenido no es "streamed" a través del repositorio. Esto es beneficioso cuando deseas un objeto digital que tenga un Datastream que esté almacenado y servirlo por algún servicio externo con el repositorio fuera de camino a la hora de servir el contenido. Un buen ejemplo es cuando deseamos un Datastream que sea contenido en un servidor por un servidor de media streaming. En tal caso, usted desearía pasar el control al servidor de medios para que "streamee" el contenido al cliente. (ej: video streaming), en vez de tener a Fedora en medio "streameando" nuevamente el contenido.

Modelo de Objeto Digital - Perspectiva de Acceso

Digital Object Model - Access Perspective

El diagrama muestra una vista alternativa de un objeto digital Fedora, la que muestra el objeto de una perspectiva de acceso. El objeto digital contiene Datastreams y un conjunto de propiedades del objeto (simplificadas para representarlas) descritas anteriormente. Un conjunto de puntos de acceso son definidos para el objeto usando el método descrito a continuación. Cada punto de acceso es capaz de diseminar una "representación" del objeto digital. Una representación puede ser considerada una expresión definida de una parte de todas las características esenciales del contenido. En muchos casos, la diseminación directa de un stream de bit es el único método de acceso requerido; en muchos productos repositorios este es el único método soportado. Sin embargo, Fedora soporta también diseminación de representaciones virtuales basadas en las elecciones de modeladores y presentadores de contenidos usando un completo rango de recursos de información y procesamiento. El diagrama muestra todos los puntos de acceso definidos para nuestro objeto ejemplo.

Para la perspectiva de acceso, sería mejor si la estructura interna del objeto digital fuera ignorada y tratada como si estuviera encapsulada por su punto de acceso. Cada punto de acceso es identificado por un URI que se ajusta al "Fedora "info" URI Scheme". Estas URIs pueden ser convertidas a la sintaxis URL para los servicios de acceso REST-based de Fedora (API-A-LITE). Notará que Fedora provee muchos APIs basadas en protocolos para acceder a sus objetos digitales. Estos protocolos pueden ser usados ya sea para acceder a la representación como para la metadata asociada a través del mismo punto de acceso.

Por defecto, Fedora crea un punto de acceso para cada Datastream para usarlo en la diseminación directa de su contenido. El diagrama muestra cómo esos puntos de acceso mepean los Datastreams. El objeto del ejemplo agregó tres Datastreams: un registro de metadata Dublin Core, y una imagen thumbnail y una imagen de alta resolución. Como se muestra a cada Datastream se accede por una URI separada.

Puntos de acceso optimizados son creados usando la arquitectura de modelos de contenido (Content Model Architecture), definiendo objetos de control como se describe a continuación. Detrás de la escena, los puntos de acceso optimizados conectan a los servicios que son llamados por el repositorio para producir representaciones del objeto. Los puntos de acceso optimizados son capaces de producir tanto representaciones virtuales como directas (aunque probablemente con un rendimiento más bajo). Los contenidos en el Datastream pueden ser usados como input de igual forma que los parámetros provistos por quien llama el servicio. Una "representación virtual" es producida en tiempo de ejecución usando cualquier recurso al que el servicio pueda acceder en conjunto con el contenido generado en su código. En este ejemplo, hay un servicio que contiene dos operaciones, una para producir imágenes ampliables y otra para producir imágenes en escala de grises. Estas operaciones requieren una imagen jpeg como input. Por lo tanto el Datastream etiquetado "HIGH" es usado por este servicio. Fedora genera un punto de acceso por cada operación definida por el servicio. El objeto de control contiene suficiente información para que el repositorio Fedora pueda mediar automáticamente todas las operaciones con el servicio asociado. El repositorio Fedora usa esta información para hacer llamadas apropiadas al servicio en tiempo de ejecución para producir la representación virtual. Desde la perspectiva del cliente esto es transparente; el cliente sólo solicita la diseminación del punto de acceso deseado.

Cuatro tipos de Objetos Digitales Fedora

Aunque todos los objetos digitales Fedora conforman el modelo de objetos Fedora, como se describió anteriormente, hay cuatro distintos tipos de objetos digitales Fedora que pueden ser almacenados en un repositorio. La distinción entre esos cuatro tipos es fundamental para saber como el sistema de repositorios de Fedora funciona. En Fedora, hay: objetos que almacenan entidades de contenido digital, objetos que almacenan descripciones de servicios, objetos usados para desplegar servicios, y objetos usados para organizar otros objetos.

Data Object

Objeto de datos

En Fedora un Data Object es el tipo de objeto utilizado para representar una entidad de contenido digital, Los Data Objects son lo que nosotros normalmente imaginamos cuando pensamos en un repositorio almacenando colecciones digitales. Los Data Objects pueden representar una variedad de entidades como imágenes, libros, textos electrónicos, objetos de aprendizaje, publicaciones, conjuntos de datos y otras entidades. Uno o más Datastreams son usados para representar las partes del contenido digital. Un Datastream es un elemento XML que describe el contenido puro (un bitstream o contenido externo). En el CMA, los diseminadores, una construcción de matadata usada para representar servicios, son eliminados en la medida que su funcionalidad es obtenida de otra forma.

Los Data Objects, de hecho todos los objetos digitales Fedora, ahora usan la encapsulación de objetos digitales FOXML (foxml:digitalobject) y dos elementos fundamentales XML: Propiedades del objeto (Object Properties) (foxml:objectProperties) y Datastream (foxml:datastream)

Los Data Objects son el más simple, el más común de todos los tipos de objetos especializados y son idénticos a los objetos digitales descritos en el modelo de objetos digitales Fedora anteriormente. Los Data Objects pueden ser ahora libremente compartidos entre repositorios Fedora. Si un sistema federado para resolver identificadores, como el "Handle System", o cualquier otro registro de nombres de autor, es usado, los Data objects tendrán el mismo identificador para cada copia de si mismo en cada repositorio participante. Compartir Data Objects que obtienen el mismo identificador en cada copia simplifica verdaderamente la replicación, y habilita muchos procesos de negocios y servicios que son necesarios para la instalación de repositorios de gran escala dentro del framework Fedora. Los Data Objects pueden ser aun compartidos entre repositorios incluyendo ambos identificadores, el original y el alternativo como parte de la metadata del objeto.

Service Definition Object

Objeto de definición de servicio

En Fedora un Service Definition Object o SDef es un tipo especial de objeto de control usado para almacenar un modelo de servicio. Un servicio contiene un conjunto integrado de operaciones que un Data Object soporta. En términos de programación orientada al objeto, el SDef define una "interface" la cual lista las operaciones que están soportadas pero no define exactamente cómo cada operación es realizada. Esto es similar a las aproximaciones usadas en la programación web (REST) y en los servicios SOAP Web. Para ejecutar una operación usted necesita identificar el Data Object, el SDef, y el nombre de la operación. Algunas operaciones usan contenido del Datastream (proporcionado por el Data Object) y, posiblemente, parámetros adicionales entregados por el programa cliente o por un browser que solicita la ejecución.

Conceptualmente una operación es llamada usando la siguiente forma (aunque varía con la actual interface Fedora, pero todas contendrán alguna forma de esta información):

Repository : Get : Data object PID : SDef PID : Operation Name : Optional Parameters

Un SDef es un componente básico en el CMA que nos permite agregar funcionalidad personalizada para Data Objects. Usar un SDef es como decir "este Data Object soporta estas operaciones". Escencialmente, un SDef define un "contrato de comportamiento" el cual puede ser suscrito por uno o más Data Object. Es repositorios, usualmente creamos un gran número de Data Objects similares y deseamos que todos ellos tengan la misma funcionalidad. Para hacer esta aproximación flexible y fácil de usar, la CMA usa el objeto modelo de contenidos (Content Model) (CModel) (descrito a continuación) para contener el modelo para Data Objects similares. En vez de asociar el SDef directamente con cada Data Object, la relación hasService es agregada al objeto CModel. Siguiendo la relación ente el Data Object y el CModel, y luego desde el objecto CModel al objeto SDef, podemos determinar que operación puede realizar el Data Object. Note también que un Data Object (a través de su objeto CModel) puede soportar más de un servicio (al tener una relaciones SDef multiples)

Los SDef pueden ahora ser compartidos libremente entre repositorios Fedora, si un sistema federado para resolver identificadores, como el "Handle System", o cualquier sistema de registro de nombre de autor es usado el objeto SDef tendra el mismo identificador para cada copia de si mismo en cada repositorio participante. Compartir objetos SDef mientras se tiene el mismo identificador para cada copia de si mismo en cada copia realmente simplifica la replicación, y habilita muchos procesos de negocios y servicios que son necesrioas para la instalación de repositorios de gran escala integrados dentro del framework Fedora. Los objetos SDef pueden incluso ser compartidos entre repositorios incluyendo los identificadores original y el alternativo como parte de la metadata del objeto. El mejor resultado se obtendrá al compartir los objetos Data, SDef y Model Content como un grupo manteniendo los mismos identificadores originales. Al usar el CMA de esta forma, usted trasfiere una unidad significante de los datos y metadatos que documentan los patrones de expresión de su trabajo intelectual. Mientras esto sea así, por si mismo, no necesitará nada más, este es un enorme paso para crear un repositorio con contenido durable.

Estamos notando el valor que los objetos de definición de servicios tienen para el modelo básico de objetos de Fedora. También ellos son almacenados en un repositorio Fedora tal como otros objetos Fedora. Y así, una colección de objetos SDef en un repositorio constituye un "registro" de la definición de servicios.

Service Deployment Object

Objeto de Despliegue de Servicios

Los objetos de despliegue de servicios son un tipo especial de objetos de control que describen cómo un repositorio específico entregará la operación de servicio descrita en un SDef para una clase de Data Objects descritos en un CModel. El SDep no tiene código ejecutable pero a cambio contiene información que le cuenta al repositorio Fedora cómo y cuando ejecutar la función que el SDef representa. En el CMA, los SDep actúan como un objeto de despliegue sólo para el repositorio específico en el cual fueron ingeridos; cada repositorio es libre de proveer funcionalidad en distintas formas. Por ejemplo, un repositorio Fedora puede elegir usar un Servlet y otro puede usar un servicio SOAP Web para realizar la misma función. Como en otro ejemplo, implementaciones de repositorios individuales pueden necesitar proveer la funcionalidad a diferentes puntos finales. O tal vez, una instalación específica puede utilizar un mecanismo de resolución dinámica de errores para permitir utilizar distintos proveedores de servicios.

ya que el SDep sólo opera dentro del alcance del un repositorio individual, los operadores de este repositorio son libres de realizar cambios al SDep o a la funcionalidad que representa en cualquier momento (con excepción de cuando no está disponible temporalmente por la realización de un cambio). Esta aproximación le permite al operador del sistema controlar el acceso a servicios llamados desde el repositorio Fedora para instruir seguridad o las políticas que su organización determine. Esto permite que los servicios llamados por Fedora puedan ser manejados usando los mismos principios y herramientas para el desarrollo de cualquier sistema distribuido. Esto también permite al operador del sistema reconfigurar sus sistemas rápidamente sin tener que cambiar partes de su contenido excepto el objeto SDep.

Los SDep almacenan servicios concretos ligando (bind) metadatos. Cuando un SDep usa la relación isDeploymentOf, es como decir "estoy habilitado para ejecutar el método de servicio descrito por ese SDef". Un objeto SDep se relaciona con un SDef en el sentido que define una implementación concreta particular de la operación abstracta definida en el objeto SDef. El SDef también usa la relación isContractorOf con un CModel que es como decir "úseme para hacer la operación de servicio para cualquier Data Objects relacionado con este CModel".

Un objeto SDep almacena muchas formas de metadata que describen los binding en tiempo de proceso para invocar los métodos de servicios. El más significativo de esos formatos de metadata es la información de binding de servicios codificada en el lenguaje de descripción de servicios web (WSDL). El sistema de repositorios de Fedora usa el WSDL en tiempo de proceso para despachar requerimientos de métodos de servicios en un ambiente repleto de requerimientos de "representaciones virtuales" de un Data Object (por ejemplo, vía sus operaciones). Esto permite que Fedora hable a una variedad de distintos servicios de una manera predictible y estándar. Un SDep también contiene metadatos que definen un "data contract" (contrato de datos) entre los servicios y una clase de objetos Fedora como está definida en el CModel. Para el despliegue inicial del CMA un contrato de datos simple será elegido.Ya que los IDs de los Datastream están especificados en el CModel y el SDep es ahora un objeto de control de despliegue sólo para un repositorio específico, el SDep es habilitado para uniformemente bindear directamente esos IDs. En el futuro una mecanismo de binding más abstracto puede ser usado pero est aproximación es simple y clara, aunque puede requerir la creación de un pequeño número de objetos SDep adicionales.

Un aspecto importante del rediseño de la CMA es que no se requiere la conformidad a un modelo de de contenido o que la integridad referencial entre objetos sea chequeada en tiempo ingesta. Esto puede resultar en un error de tiempo de proceso si el repositorio no puede encontrar los objetos referenciados, interpretar el modelo de contenido o si encuentra algún problema de conformidad.

Es importante notar que los objetos SDep están en el modelo básico de objetos de Fedora. Ellos también son almacenados en un repositorio Fedora como cualquier objeto Fedora. Es así como una colección de objetos SDep en un repositorio contituyen un "registro" de los servicios de despliegue que pueden ser usados con objetos Fedora. En la CMA, los objetos SDep no se pueden compartir libremente entre repositorios. Ellos representan el cómo un repositorio específico implementa un servicio. Sin embargo, los objetos SDep pueden ser compartidos si el operador del sistema los modifica para despliegue local. La razón de esto, los objetos SDep no pueden ser automáticamente replicados entre repositorios sin considerar como lo afectarán.

Content Model Object

Objeto Modelo de Contenido

El objeto de Modelo de Contenido o CModel es un control nuevo especializado incorporado como parte de la CMA. Este actúa como contenedor para el documento "Modelo de Contenido" el cual es un modelo formal que caracteriza la clase de objeto digital. Este provee también un modelo de las relaciones que están permitidas, excluidas, o requeridas entre grupos de objetos digitales. Todos los objetos digitales en Fedora incluyendo objetos Data, SDef, SDep y CModel están organizados en clases por el objeto CModel. En esta sección, discutiremos primeramente las relaciones entre los objetos Data y CModel.

Para crear una clase de objetos Data, se debe crear un objeto CModel. Cada objeto Data que pertenezca a la clase debe cumplir la relación hasModel usando los identificadores del CModel y del objeto. El actual objeto CModel contiene un modelo estructural del objeto Data. En el tiempo tendremos elementos adicionales para el documento de modelo de contenido pero esta implementación inicial es suficiente describir el Datastream que debe estar presente en cada objeto Data de la clase. La otra relación clave es con los objetos SDef. Usted puede afirmar cero o más relaciones hasService en el CModel para objetos SDef.

Un objeto Data puede afirmar una relación hasModel con múltiples objetos CModel. Un Objeto Data de este tipo de estar conforme a todos sus modelos de contenido, conteniendo la suma de todos los Datastream definidos por sus modelos de contenido. Si dos o más modelos de contenido definen Datastreams con el mismo nombre pero con diferentes características, se construirá un objeto Data mal formado y como tal el repositorio no podrá despachar sus contenidos o servicios. Fedora asume automáticamente que todos los objetos están conformes a un "Modelo de Contenido Básico" definido por el sistema. No es necesario afirmar una relación con este modelo de contenido explicitamente pero, si el objeto Data afirma otras relaciones es una buena práctica hacer explícita la afirmación al Modelo de Contenidos Básico. Sin perjuicio de que el repositorio se comportará igual si la relación ha sido aseverada o no. A lo largo del Modelo de Contenido Básico, el repositorio define una "Definición de Servicios Básicos" la cual provee operaciones comunes a todos los objetos. Uno de estos servicios proporciona acceso directo a los Datastream.

Gracias al Modelo de Contenido Básico y a la Definición de Servicios Básica, nada necesita ser agregado al objeto Data si el usuario sólo necesita almacenar y diseminar Datastreams por nombre. Sin embargo, sin un modelo de contenido explicito usted no podrá validar cuando el objeto Data está correctamente formado. En la CMA, si el repositorio no puede encontrar e interpretar todos los objetos de control del objeto Data, o no puede interpretar el modelo de contenido, emitirá un error de tiempo de proceso cuando el objeto Data sea accesado. Note que el repositorios siempre estará habilitado para ejecutar operaciones básicas de Datastream porque ellas son parte del Modelo de Contenido Básico y de la Definición de Servicios Básica. No hay errores o advertencias emitidos en la ingesta o modificación de un objeto en la CMA aparte de las debida a la conformidad con las reglas de los objetos digitales bien formados.

Los objetos CModel pueden ser ahora libremente compartidos entre repositorios Fedora. Si un sistema federado para resolver identificadores, como el Handle System, o cualquier sistema de registros de nombres de autor es usado el CModel puede tener el mismo identificador para cada copia de si mismo en cada repositorio participante. Compartir objetos CModel mientras se tiene el mismo identificador en cada copia simplifica enormemente la replicación, y habilita muchos procesos y servicios de negocios que son necesarios para la instalación de repositorios a gran escala integrados dentro del framework de Fedora. Los objetos CModel pueden ser compartidos aun entre repositorios incluyendo los identificadores original y alternativo como parte del metadato del objeto. El mejor resultado se obtendrá al compartir los objetos Data, Sdef y CModel como grupo manteniendo los mismos identificadores originales. Al utilizar la CMA de esta forma, usted transfiere una unidad significativa de los datos y metadatos que documentan el pattern de expresión de su trabajo intelectual. Mientras esto sea así, no necesitará nada más, este es un gran paso adelante para crear un repositorio de contenido durable. En el tiempo lenguajes de modelo de contenido podrán ser desarrollados ue permitan describir una porción aún mayor de características esenciales de los contenidos y sus comportamientos.

Es importante notar que los objetos de modelo de contenido conforman el modelo de objetos básico de Fedora. Ellos también son almacenados en un repositorio Fedora tal como otros objetos Fedora. De esta forma, una colección de objetos de modelo de contenido en un repositorio constituye un "registro" de modelos de contenido.