FACULTAD DE TELEMÁTICAdigeset.ucol.mx/tesis_posgrado/Pdf/LUIS_ENRIQUE_ROSAS_GONZAL… ·...
87
UNIVERSIDAD DE COLIMA FACULTAD DE TELEMÁTICA “Administración de Repositorios Institucionales Híbridos de Acceso Abierto” TESIS QUE PARA OBTENER EL GRADO DE MAESTRO EN COMPUTACIÓN Presenta: Luis Enrique Rosas González ASESORES: D. en C. María Andrade Aréchiga D. en C. Nicandro Farías Mendoza Colima, Col. Febrero de 2012
Transcript of FACULTAD DE TELEMÁTICAdigeset.ucol.mx/tesis_posgrado/Pdf/LUIS_ENRIQUE_ROSAS_GONZAL… ·...
UNIVERSIDAD DE COLIMA
FACULTAD DE TELEMÁTICA
“Administración de Repositorios Institucionales
Híbridos de Acceso Abierto”
TESIS
QUE PARA OBTENER EL GRADO DE
MAESTRO EN COMPUTACIÓN
Presenta:
Luis Enrique Rosas González
ASESORES:
D. en C. María Andrade Aréchiga
D. en C. Nicandro Farías Mendoza
Colima, Col. Febrero de 2012
ii
Dedicatoria y agradecimientos
Quiero dedicar este trabajo a todas las personas que me han apoyado a lo largo de mi
trayectoria académica y que han hecho posible que yo haya llegado hoy aquí.
Agradezco en primer lugar a Dios por darme el entendimiento, la fuerza y entereza necesarios
para lograr una meta más en mi vida.
A mis padres y hermanos que siempre confiaron en mí e incondicionalmente me han brindado
toda la ayuda que he necesitado.
Quiero agradecer especial y sinceramente a mis asesores, la doctora María Andrade Aréchiga
y el doctor Nicandro Farías Mendoza por darme el honor de ser protagonista de este trabajo,
por su ayuda puntual y por supervisar con profesionalismo el progreso del mismo.
A mis maestros por transmitirme algo de su vasto conocimiento que estoy seguro me será de
mucha utilidad en mi desempeño profesional y personal.
A mis compañeros con quienes intercambié conocimientos y experiencias que nunca olvidaré.
A mis auténticos amigos con los que he pasado ratos maravillosos y que se han mantenido
interesados en cada proyecto de mi vida.
Por todos ustedes vale la pena seguir adelante.
Enrique
iii
ÍNDICE
Dedicatoria y agradecimientos ......................................................................................... ii
Índice ............................................................................................................................... iii
Índice de figuras ...............................................................................................................vi
Índice de tablas .............................................................................................................. viii
Resumen ...........................................................................................................................ix
Abstract .............................................................................................................................. x
I.- CAPÍTULO 1. Introducción ..................................................................................... 1
1.1.- Contexto del problema ..................................................................................... 1
1.2.- Antecedentes del problema .............................................................................. 2
1.3.- Síntesis de trabajos relacionados ..................................................................... 3
1.4.- Planteamiento del problema ........................................................................... 5
1.5.- Objetivos .......................................................................................................... 6
1.6.- Métodos empleados ......................................................................................... 6
1.7.- Organización del documento ......................................................................... 11
II.- CAPÍTULO 2. Estado del Arte ............................................................................ 13
2.1.- Marco histórico .............................................................................................. 13
2.2.- Marco contextual ........................................................................................... 16
2.3.- Marco teórico ................................................................................................. 17
iv
2.3.1.- Repositorios Institucionales .............................................................. 17
2.3.2.- Metadatos .......................................................................................... 18
2.3.3.- Dublín Core ....................................................................................... 19
2.3.4.- Protocolo OAI-PMH ......................................................................... 21
2.3.5.- XML .................................................................................................. 32
2.3.6.- PHP .................................................................................................... 33
2.3.7.- MySQL .............................................................................................. 34
2.3.8.- Servidor Apache ................................................................................ 36
2.3.9.- HTML ................................................................................................ 36
III.- CAPÍTULO 3. Análisis del Sistema .................................................................... 38
3.1.- Descripción de la metodología ...................................................................... 38
3.2.- Requerimientos de usuario............................................................................. 43
3.2.1.- Servicios que brinda el sistema al usuario......................................... 43
3.3.- Requerimientos de sistema ............................................................................ 44
3.3.1.- Servicios requeridos por el sistema ................................................... 45
IV.- CAPÍTULO 4. Diseño de Sistema ........................................................................ 48
4.1 Diseño del Interfaces ........................................................................................ 48
4.2 Diseño de la base de datos ............................................................................... 51
V.- CAPÍTULO 5. Implementación y Pruebas ........................................................... 56
5.1 Implementación de interfaces .......................................................................... 56
v
5.2 Pruebas del sistema .......................................................................................... 61
5.3 Discusión .......................................................................................................... 66
VI.- CAPÍTULO 6. Conclusiones ................................................................................. 68
Trabajo futuro......................................................................................................... 69
ANEXO ........................................................................................................................ 70
Referencias ................................................................................................. 76
vi
ÍNDICE DE FIGURAS
Figura 1. Incremento de Repositorios Institucionales. ...................................................... 4
Figura 2. Diagrama conceptual del esquema propuesto .................................................... 7
Figura 3. Ejemplo de un metadato estructurado en XML. .............................................. 10
Figura 4. Comparativa entre las tres diferentes versiones del protocolo OAI-PMH ....... 25
Figura 5. Implementación más común del protocolo OAI-PMH. ................................... 27
Figura 6. Implementación con un agregador de servicios intermedio. ............................ 28
Figura 7. Combinación de diferentes protocolos. ............................................................ 28
Figura 8. Interacción entre un proveedor de datos y un proveedor de servicios. ............ 29
Figura 9. Modelo de peticiones y respuestas utilizando OAI-PMH. ............................... 30
Figura 10. Control de flujo entre proveedores de datos y servicios. ............................... 31
Figura 11. Diagrama de la metodología empleada. ......................................................... 38
Figura 12. Ontología del esquema propuesto .................................................................. 41
Figura 13. Interacción entre el sistema y el usuario final. ............................................... 44
Figura 14. Interacción entre el usuario y el sistema. ....................................................... 46
Figura 15. Proceso de diseño de interfaces de usuario. ................................................... 48
Figura 16. Esquema de la interfaz principal. ................................................................... 49
Figura 17. Estructura en MySQL de la tabla de metadatos ............................................. 52
Figura 18. Interfaz principal del sistema. ........................................................................ 53
Figura 19. Interfaz del centro de investigación de ingenierías. ....................................... 54
vii
Figura 20. Opción de acceso al sistema. .......................................................................... 56
Figura 21. Formulario de registro de material bibliográfico 1/2. .................................... 57
Figura 22. Formulario de registro de material bibliográfico 2/2. .................................... 58
Figura 23. Notificación de registro exitoso. .................................................................... 59
Figura 24. Notificación de registro erróneo..................................................................... 60
Figura 25. El proceso de pruebas..................................................................................... 61
Figura 26. El proceso de pruebas de defectos ................................................................. 63
Figura 27. Estructura en MySQL de la tabla de investigadores. ..................................... 70
Figura 28. Estructura en MySQL de la tabla de noticias y boletines informativos. ....... 71
Figura 29. Interfaz de captura de investigadores 1/2 ....................................................... 72
Figura 30. Interfaz de captura de investigadores 2/2 ....................................................... 73
Figura 31. Interfaz de captura de noticias o boletines informativos ................................ 74
viii
ÍNDICE DE TABLAS
Tabla 1. Campos del estándar de generación de metadatos Dublín Core........................ 19
Tabla 2. Servicios que brinda el sistema al usuario. ........................................................ 43
Tabla 3. Requerimientos del sistema. .............................................................................. 46
Tabla 4. Tabla de pruebas realizadas al sistema .............................................................. 64
ix
Resumen
Hoy en día, cada institución educativa y científica se debe mantener en comunicación, con la
finalidad de compartir, generar o renovar conocimientos. En este trabajo se describe el
desarrollo de un esquema para la administración de Repositorios Institucionales en ambientes
operativos y de ejecución abiertos, a través de la aplicación del protocolo OAI-PMH. Para
lograr los objetivos de este trabajo, se utilizaron métodos de cosecha y recolección de
metadatos para la difusión y transferencia de información, siempre bajo contextos abiertos.
Las aportaciones buscadas con este trabajo son principalmente la colaboración constante entre
diferentes instituciones educativas para compartir, generar o renovar conocimientos; así como
también ofrecer al usuario que lo deseé, información variada, confiable y actualizada. Algo del
sistema. También se describe el desarrollo de una plataforma Web para implementar la
metodología propuesta en el proyecto así como las pruebas realizadas al mismo y sus
respectivos resultados.
x
Abstract
Today every educational and scientific institution should be kept communicated in order to
share, generate or renovate knowledge. This paper describes the development of a
management scheme for Institutional Repositories in operating environments and open design,
through the implementation of the OAI-PMH protocol. To achieve the objectives of this paper,
were used methods of harvesting and collection of metadata for information dissemination and
transfer, always under open contexts. Contributions sought with this paper are primarily the
ongoing collaboration between different educational institutions to share, build or renovate
knowledge; as well as offering the user who wants to, reliable and updated information. It also
describes the development of a Web platform to implement the methodology proposed
in the project and the same tests and their results.
1
CAPÍTULO 1. Introducción
En este capítulo se exponen brevemente el contexto del problema, la justificación, los
objetivos y algunos conceptos que sirven de fundamento científico a la investigación y
muestran la importancia de la misma.
1.1 Contexto del problema
En los siguientes párrafos se explica la problemática que se aborda con la investigación
mostrando las deficiencias que existen en el sistema científico actual respecto al
procedimiento de consulta e intercambio de material científico entre distintas instituciones y
dependencias.
Para las instituciones educativas y científicas, es importante mantener una buena
comunicación con otras instituciones o sistemas, con la finalidad de compartir, generar o
renovar conocimientos.
Por lo general, las investigaciones producen tesis, memorias, artículos de investigación,
reportes técnicos, entre otros productos de investigación generados en diferentes Instituciones
educativas. Estos productos se conservan en las mismas sin difundirse y sólo consultadas -en
el mejor de los casos- por académicos, investigadores y estudiantes de la misma Institución.
Esto impacta directamente en el desarrollo y generación de conocimiento nuevo, en casos en
los que en una Institución se desarrollan proyectos o investigaciones idénticos a los ya
existentes en otra, que lejos de tratarse de plagio, se debe en gran medida al desconocimiento
de la existencia de dicho proyecto por la falta de difusión brindada al mismo. Esto a su vez
implica pérdida de tiempo y recursos al desarrollar una investigación que ya existe en alguna
otra Institución, mismos que bien, pueden emplearse para continuar con dicha investigación o
en su caso para realizar una investigación nueva, generando de esta forma conocimiento
nuevo.
2
1.2 Antecedentes del problema
En esta sección se explican los procedimientos de consulta e intercambio de información
científica que surgieron con la aparición de Internet, así como algunas iniciativas previas al
movimiento Open Access que dieron como resultado el surgimiento del mismo.
Con el surgimiento de Internet se abrieron nuevas posibilidades de comunicación, situación
que aprovecharon los investigadores para acelerar el intercambio de datos e ideas con pares
incluso de otros países, utilizando tecnologías como el correo electrónico o los protocolos de
transferencia de archivos (FTP).
El intercambio de material así como el de resultados o avances de investigaciones, se realizaba
ajeno a la visión de las editoriales, quienes se habían mantenido en esta tarea desde su
aparición. Las visiones eran divididas, pues había quienes veían esto con ilusión y otros con
inquietud. Las mismas universidades e instituciones de investigación comenzaron a debatir
sobre el existente sistema que según Keefer (2007) consistía en:
La inversión económica de sus investigaciones mediante los sueldos de sus científicos
y docentes.
La entrega de sus resultados científicos a los editoriales de manera totalmente gratuita.
La inversión que efectuaban las instituciones científicas mediante las suscripciones a
las revistas donde se publicaban los resultados de sus propias investigaciones.
Algunas de las iniciativas previas al movimiento Open Access y a la implantación de los
primeros repositorios institucionales fueron:
El archivo de preprints arXiv es un archivo creado en 1991 donde los físicos
depositan sus trabajos preliminares para luego ser leídos y comentados por los
miembros que así lo deseen (CUL, 2010).
3
La SPARC (Scholary Publishing and Academic Resources Coalition) es una
asociación creada en 1997 con el propósito de concientizar a la comunidad científica
sobre la necesidad de impulsar la aparición de nuevos modelos de comunicación
académica para difundir la investigación científica y reducir las presiones financieras
provocadas por las revistas donde eran publicados sus trabajos (SPARC, 2010).
La PLoS (Public Library of Science) es una organización sin fines de lucro conformada
por científicos de diversas áreas de conocimiento buscando hacer de la literatura
científica mundial un recurso público (PLoS, 2010).
1.3 Síntesis de trabajos relacionados
En esta sección se presentan algunos trabajos de investigación relacionados con Repositorios
Institucionales así como sus principales resultados o aportaciones.
En su trabajo, Santillan (2009) demuestra la importancia y utilidad de los Repositorios
Institucionales en el proceso de divulgación de información, especialmente a través de
bibliotecas digitales, basándose como caso de estudio en el proyecto E-LIS (E-prints in
librarianship and information science).
El autor afirma que las universidades, por su carácter de productoras y consumidoras de
información, son las más interesadas en el desarrollo y florecimiento del acceso abierto y
prueba de ello es el reciente aumento en el desarrollo de Repositorios Institucionales por parte
de las mismas, como se refleja en el ROAR (Registry of Open Acces Repositories) y cuyo
comportamiento se muestra en la figura 1.
4
Figura 1. Incremento de Repositorios Institucionales (ROAR, 2011).
Santillan menciona también que estos repositorios son la prueba fehaciente del impacto
positivo del Open Access como alternativa al sistema tradicional de comunicación científica y
como vía para la integración de los países en desarrollo al circuito mundial de la información y
el conocimiento.
Por otro lado, Chawner (2005) menciona y utiliza un modelo para la clasificación del tipo de
software utilizado en la implementación de repositorios institucionales y bibliotecas digitales,
obteniendo como resultado que la mayoría del software libre enfocado a la operación de este
tipo de servicios está siendo desarrollado a muy pequeña escala en comparación con otros
proyectos de desarrollo de software llevados a cabo por bibliotecas privadas más grandes que
a menudo reciben apoyos de organismos de investigación.
Las estadísticas obtenidas por la autora evidencian la necesidad de desarrollar aplicaciones
para repositorios institucionales, sin embargo, no propone ningún método o proyecto para
llevarlo a cabo.
A su vez, Nikolov y Stoehr (2008) exponen algunas estadísticas que evidencian la “muerte” de
millones de artículos científicos en internet, debido a que muchos autores no almacenan sus
trabajos en repositorios institucionales, sino que lo hacen en páginas personales o servidores
públicos donde corren el riesgo de perderse debido a la constante inestabilidad de las
5
tecnologías utilizadas. Una de sus estadísticas más relevante expone que cerca del 11% de las
URL’s de los documentos PDF que contienen referencias a las publicaciones de ciencias de la
vida, no eran accesibles dentro de los 5 meses después de haber sido cosechados. Al mismo
tiempo proponen la cosecha de metadatos como una forma de abordar este problema y como
factor crucial para preservar la literatura científica en línea.
Sin embargo, los autores sólo se enfocan en la problemática y las estadísticas y no mencionan
algún método o esquema para implementar las cosechas que proponen.
1.4 Planteamiento del problema
En esta sección se plantea de manera específica la problemática que se aborda y se pretende
resolver con esta investigación en particular.
Hoy en día cada institución educativa y científica se debe mantener en comunicación, con la
finalidad de compartir, generar o renovar conocimientos. Los investigadores, por ejemplo, al
momento de desarrollar proyectos se ven obligados a consultar información de diferentes
fuentes (libros, revistas, tesis, memorias, etc.); este proceso de consulta resulta con frecuencia
frustrante ya que el acervo inverosímil que transita en Internet expone, en su mayoría,
suposiciones no comprobadas como datos importantes.
En contraste con lo mencionado anteriormente, el hecho de apoyarse en material científico
respaldado por investigadores reconocidos garantiza que las ideas ahí expuestas han sido
probadas y sus resultados y conclusiones son reales.
Por lo expuesto en los párrafos previos, resulta de gran importancia una colaboración
constante entre instituciones y dependencias para compartir fuentes de información que
incrementen el acervo bibliográfico y así dar un soporte significativo a los investigadores que
buscan referencias bibliográficas para dar fundamento a sus proyectos. Sin embargo, al menos
en la Universidad de Colima, se carece de un sistema o esquema de administración de
6
repositorios eficiente que permita el intercambio y difusión de material bibliográfico de
calidad científica en Internet.
1.5 Objetivos
Desarrollar un esquema de administración de repositorios institucionales híbridos capaz de
ofrecer, intercambiar y difundir material bibliográfico en Internet con la participación de
diferentes instituciones educativas y de investigación de forma libre y abierta.
Los objetivos específicos son:
Implementar un módulo para la conectividad entre repositorios institucionales y
bibliotecas digitales en la Web.
Representar la información del material bibliográfico a transmitir en forma de
metadatos Dublín Core a través de XML.
Desarrollar un módulo para cosechar y exportar metadatos entre los Repositorios
Institucionales y Bibliotecas Digitales implicadas.
Diseñar un buscador para localizar de manera rápida y eficiente documentos
bibliográficos en la Web.
1.6 Métodos empleados
En esta sección se explican los métodos empleados para lograr los objetivos de esta
investigación.
Para lograr los objetivos buscados se utilizan métodos de intercambio de información a través
de internet enfocándonos específicamente en cosecha y recolección de metadatos
estructurados en XML bajo el estándar de generación de metadatos Dublín Core apegándose
7
en todo momento a la aplicación del protocolo OAI-PMH (Open Access Initiative Protocol for
Metadata Harvesting).
En la figura 2 se muestra el diagrama conceptual del esquema propuesto en este proyecto y su
descripción se hace en los párrafos siguientes.
Figura 2. Diagrama conceptual del esquema propuesto
Interfaz: Uno de los factores más importantes a tomar en cuenta en el desarrollo de un
sistema de información son las interfaces, las cuales deben ser amigables y atractivas hacia el
usuario para que este se interese en el sistema y realice sus actividades con interés y de forma
intuitiva. Si una interfaz es relativamente compleja, el usuario puede rehusarse a usarla por
temor a equivocarse o simplemente provocará errores debido a la confusión que la interfaz le
cause.
A lo largo de la historia de la informática han ido apareciendo diferentes tipos y estilos de
interfaz de usuario dependiendo, sobre todo, de la capacidad gráfica de los ordenadores
(Alonso et al., 2005).
8
La interfaz de usuario es en la mayoría de los casos el componente más crítico del sistema.
Los usuarios generalmente no entienden sobre el mundo interno de los ordenadores, que se
compone de bits, bytes, ficheros, circuitos, entre otros. Es más, conocen el sistema por medio
de su interfaz, el texto, las imágenes o los sonidos que aparecen en los dispositivos de salida
del sistema en cuestión (pantallas, altavoces, etc.). Los usuarios sólo son capaces de explotar
las posibilidades que la tecnología ofrece si sus interfaces transmiten dichas posibilidades
(Saltivery et al., 2005).
En esta propuesta, la interfaz de usuario pretende ser relativamente simple pero sin descuidar
con ello el potencial que el sistema puede tener. El usuario se encontrará ante una interfaz
amigable capaz de ofrecerle el material bibliográfico que busca de manera intuitiva y simple.
Así mismo, la interfaz también le ofrece al usuario la posibilidad de realizar búsquedas
avanzadas con la finalidad de obtener resultados más específicos en cuanto al tipo, enfoque,
área de conocimiento, etc. del material buscado.
Almacenamiento: La cuestión del almacenamiento es crucial para el éxito del proyecto. Es en
este bloque donde se almacenan los metadatos de todo el material bibliográfico disponible en
sus respectivos repositorios.
Un repositorio no es más que el lugar donde reside una determinada información utilizada para
fines operativos. Dicha información puede ser de cualquier tipo, por ejemplo de clientes,
productos o como en este caso, de material bibliográfico (Croxatto, 2005).
La función de los repositorios en el presente proyecto reside en almacenar los metadatos de
todo el material disponible para consulta manteniéndolos siempre ordenados y clasificados.
Los repositorios de metadatos se mantendrán actualizados haciendo cosechas de metadatos en
repositorios externos en la Web con determinada frecuencia, usando los bloques de
Interoperabilidad y Comunicación descritos en los párrafos siguientes.
9
Interoperabilidad: La interoperabilidad semántica o interoperabilidad de los metadatos está
destinada a la descripción de los recursos de información para facilitar el intercambio de
información y la recuperación óptima por parte de los usuarios. En este ámbito se suelen
utilizar un conjunto de herramientas para la representación del conocimiento contenido en los
recursos, generalmente provenientes del ámbito de la documentación y la gestión del
conocimiento, como son: los vocabularios controlados, los metadatos, las ontologías y los
topic maps.
Los metadatos son un conjunto de elementos que poseen una semántica comúnmente
aceptada, ya que surgieron por la necesidad de recuperar la información electrónica dispersa
(Martínez y Navarra, 2007).
XML (Extensible Markup Language o lenguaje de anotación extensible, por sus siglas en
inglés) ofrece un formato para la descripción de datos estructurados, Es decir, XML es un
metalenguaje, dado que con él podemos definir nuestro propio lenguaje de presentación y, a
diferencia del HTML, que se centra en la representación de la información, XML se centra en
la información en sí misma. La particularidad más importante del XML es que no posee
etiquetas prefijadas con anterioridad, ya que es el propio diseñador el que las crea a su antojo,
dependiendo del contenido del documento (Arellano et al., 2009).
En la figura 3 se muestra un ejemplo de un metadato con etiquetas Dublín Core estructurado
en XML.
Los principales objetivos que se buscan con la implementación de XML como lenguaje de
marcado son (Ayllón Bonet, 2006):
Representar y distribuir tanto documentos como información textual.
Intercambio de datos e información estructurada a través de Internet y WWW.
Integración de datos procedentes de fuentes heterogéneas.
Eliminar la barrera entre información estructurada e información textual.
10
Figura 3. Ejemplo de un metadato estructurado en XML.
Comunicación: La comunicación implica la recíproca relación con mensajes, es decir, con
contenidos de comunicación que representan precisamente a la información; en otras palabras,
la información es el contenido de la comunicación.
A través del bloque de Comunicación el sistema se mantendrá en contacto constante con otras
instituciones educativas a través de la Web para compartir e intercambiar información
bibliográfica confiable de manera abierta y libre.
Al sistematizar cada uno de los bloques mencionados queda conformado el esquema propuesto
para administrar Repositorios Institucionales híbridos en Internet bajo contextos abiertos,
logrando nuestro propósito de ofrecer, intercambia y difundir material bibliográfico en internet
a través de diferentes Repositorios de Instituciones o dependencias educativas y científicas
<?xml versión=”1.0”?>
<!DOCTYPE MENSAJE SYSTEM “metadato.dtd”>
<metadato>
<contenido>
<título> Administración de Repositorios Institucionales Híbridos de Acceso Abierto
</título>
<descripción> Propone un esquema para la administración de Repositorios
Institucionales Híbridos de Acceso Abierto a través de la aplicación del protocolo OAI-
PMH </descripción>
</contenido>
<propiedad intelectual>
<creador> Rosas G., Andrade A., Farías M.</creador>
<colaborador>Universidad de Colima</colaborador>
</propiedad intelectual>
<aplicación>
<fecha> Enero 24, 2011 </fecha>
<lenguaje> Es </lenguaje>
</aplicación>
</metadato>
11
Actualmente existen varios estándares para la generación de metadatos, sin embargo, se optó
por el uso del Dublín Core por ser éste uno de los más flexibles y relativamente fáciles de
implementar.
Se contactó al CGIC (Centro General de Investigación Científica) con el propósito de contar
con su apoyo e idear algún método para facilitar el proceso de recopilación de material
científico de investigadores de la U de C y ponerlo a disposición del usuario en general.
Para el correcto funcionamiento y optimización del sistema se requiere firmar convenios con
otras dependencias o centros de investigación que estén interesados en participar en la
iniciativa de archivos abiertos con el propósito de compartir e intercambiar material científico
de forma libre y abierta logrando una mayor disponibilidad de información.
1.7 Organización del documento
El documento está organizado de la siguiente manera, en el capítulo II se presenta la situación
actual y tendencias en cuanto a repositorios institucionales y el movimiento Open Access, se
exponen también sucesos históricos importantes como la declaración de Budapest y su
influencia vital para el florecimiento y desarrollo de nuevos repositorios institucionales; se
describen también términos inherentes al tema, tales como metadatos, el estándar Dublín Core
y el protocolo OAI-PMH.
En el capítulo III se describe en profundidad el análisis y la metodología empleada en el
desarrollo del sistema utilizando métodos de ingeniería de software tales como diagramas de
requerimientos de usuario y modelos de desarrollo de sistemas.
En el capítulo IV se describe el procedimiento de diseño del sistema luego del análisis
realizado previamente y se incluyen algunas interfaces gráficas diseñadas tomando en cuenta
los requerimientos y el perfil del usuario final.
12
En el capítulo V se describe el procedimiento de implementación del esquema a través de un
sistema o plataforma de software, así como las pruebas hechas al mismo y sus respectivos
resultados.
En el capítulo VI se describen las conclusiones y resultados generales de la investigación,
también se verifica si se alcanzaron los objetivos planteados desde el principio y se propone el
trabajo a futuro.
13
CAPÍTULO 2. Estado del Arte
En este capítulo se presenta la situación actual y las tendencias en cuanto a Repositorios
Institucionales y el movimiento Open Acces, se exponen sucesos históricos importantes como
la declaración de Budapest por ejemplo, también se describe brevemente lo que son los
metadatos, el estándar de metadatos Dublín Core y el protocolo OAI-PMH.
2.1 Marco histórico.
En esta sección se exponen acontecimientos históricos importantes que precedieron a la
aparición del movimiento Open Access que tiene como filosofía el acceso gratuito y sin
restricciones al conocimiento científico.
La declaración de Budapest llevada a cabo en 2001 fue considerada como el inicio oficial del
movimiento Open Access. Esta declaración expone diferentes puntos de vista, tanto de
científicos como académicos de diferentes instituciones académicas y científicas,
compartiendo similares posturas sobre la crisis de las revistas científicas y buscando
colectivamente el acceso gratuito y sin restricciones al conocimiento científico.
Los resultados de la convención de Budapest propusieron dos métodos para asegurar la acción
del movimiento Open Access (Hagemann, 2002):
1) La ruta dorada, que consiste en la publicación de artículos en revistas de acceso
abierto.
2) La ruta verde, que consiste en depositar los artículos en repositorios por parte del
mismo autor, lo que se conoce como autoarchivo.
Es evidente que la ruta verde es la mejor opción para lograr implementar al máximo la
filosofía del Open Access, debido a que los autores pueden seguir publicando sus trabajos en
14
cualquier tipo de revistas incluyendo las de paga, y al mismo tiempo es posible el acceso libre
a estos trabajos mediante la versión depositada en un repositorio.
En un principio, los investigadores que pretendían colaborar con el movimiento Open Access
no tenían dónde depositar sus trabajos para compartirlos con los demás y la única alternativa
para muchos de ellos era depositar sus trabajos en servidores personales o públicos, donde
podían ser accedidos libremente desde internet. Sin embargo, este método no garantizaba la
permanencia ni la interoperabilidad entre diferentes sistemas y plataformas.
La declaración de Budapest creó un gran impacto en la comunidad científica y motivó el
desarrollo de repositorios institucionales. Según el estudio de Swan y Brown (2005), en los
años posteriores a la declaración de Budapest entre 2003 y 2004, se detectó un aumento
internacional hasta del 100% en el número de repositorios institucionales existentes.
Aún cuando uno de los objetivos más trascendentales del movimiento Open Access es el
acceso público y libre a los repositorios institucionales, no todos estos lo ofrecen, incluso
varios de ellos pertenecientes a importantes instituciones, generalmente universidades, lo que
pretenden es disponer de un lugar seguro para depositar sus recursos digitales, sean científicos
o no, dejando como factor secundario el tema del acceso libre. Debido a esto, los repositorios
institucionales existentes varían unos de otros en algunos factores como:
Su finalidad
El tipo de material admitido
Los formatos mantenidos
Los procesos aplicados
El control de acceso
La permanencia de los recursos
Aún cuando el movimiento Open Access ha tenido una notable relevancia y su filosofía ha
sido respaldada por miles de científicos y académicos alrededor del mundo, la mayoría de los
15
repositorios institucionales existentes actualmente están todavía en fase de desarrollo y
muchos de ellos, incluso algunos de los más antiguos, tienen relativamente pocos documentos
en relación a la producción digital mundial de las instituciones. Por ejemplo, según un estudio
realizado por la ARL (Association of Research Libraries) aplicado en 37 instituciones con un
repositorio funcional, revela que sus contenidos varían entre 20 y 19,000 recursos digitales
(Keefer, 2007).
Un factor fundamental para poder alcanzar los objetivos del movimiento Open Access es sin
duda la colaboración de los autores. Los beneficios para éstos son varios, entre los más
relevantes destacan:
Mayor acceso a documentos científicos sin restricciones.
Mayor visibilidad de sus documentos.
Mayor estabilidad para la permanencia o manejo de sus documentos.
Mayor número de citas en publicaciones.
A pesar de los evidentes beneficios que el Open Access ofrece a los autores, resulta
sorprendente y a la vez alarmante, tanto para los simpatizantes del movimiento como para las
instituciones de investigación, la falta de participación por parte de este grupo. En opinión de
Keefer (2007), algunos de los factores que contribuyen a la resistencia de algunos autores para
involucrarse a participar en el movimiento Open Access y negarse a depositar sus trabajos en
repositorios institucionales son:
Desconocimiento del movimiento Open Access.
Desconocimiento de los procedimientos del autoarchivo.
Falta de tiempo para hacerlo.
Falta de medios para hacerlo.
Indiferencia a los posibles beneficios.
Resistencia a los cambios de procedimientos.
16
Resistencia a los cambios tecnológicos.
Resistencia a un nuevo sistema.
Resistencia a la obligación de archivar su trabajo (en instituciones que exigen el
autoarchivo a sus investigadores).
Miedo a la pérdida del control de su obra y al posible plagio.
Miedo a entrar en conflicto con el editor.
Desacuerdo con la filosofía Open Access.
Desacuerdo con la idea de compartir abiertamente su trabajo.
Las instituciones deben combatir los problemas existentes para que los repositorios puedan
seguir creciendo. El uso e inversión de un repositorio debe ser siempre justificado, un
repositorio sin signos de éxito dejará de ser mantenido por la institución y perderá el apoyo
para garantizar su mantenimiento a mediano o largo plazo.
2.2 Marco contextual.
La revolución tecnológica que se ha dado recientemente ha motivado la creación y difusión de
todo tipo de información. El desarrollo de Internet en los años 70 y su libre acceso a principios
de los 90, aunado al fuerte impulso que le dio a éste el WWW (World Wide Web), provocó un
fuerte impacto en todos los ámbitos mundiales y marcó un antes y un después en cuanto a los
métodos de intercambio de información, especialmente entre la comunidad científica (Keefer,
2007).
Hoy en día, gracias a las tecnologías de información, es posible facilitar actividades que en un
principio (antes de Internet) parecían utópicas. Ahora la comunidad científica es capaz de
mantenerse al día en cuanto a conocimientos e ideas con relativa sencillez y los estudiantes e
investigadores de todos los niveles tienen acceso a una cantidad de información que hasta hace
años era inimaginable.
17
En esta nueva era, las distancias han dejado de representar un problema. Ahora es posible
acceder a todo tipo de información desde prácticamente cualquier parte del mundo venciendo
las barreras geográficas. En ese sentido, un punto importante es la educación a distancia -con
investigadores, profesores y alumnos distribuidos geográficamente- que demanda la creación y
preservación de espacios electrónicos informativos comunes y compartidos (López, 2000).
López (2000) considera que las bibliotecas que han sido automatizadas están siendo
transformadas o complementadas implementando bibliotecas digitales, bajo el concepto
general de recopilar, almacenar y organizar información de manera digital. Esto con el
propósito de realizar búsquedas, recuperaciones y procesamientos vía las redes de cómputo;
todo bajo un ambiente sencillo para el usuario y tomando en cuenta factores fundamentales
como la presentación y la representación de la información, los mecanismos de
almacenamiento y recuperación, la interacción humano-computadora, la plataforma
tecnológica y el ancho de banda de la red.
2.3 Marco teórico.
En esta sección se describen los conceptos y tecnologías existentes relacionadas con esta
investigación.
2.3.1 Repositorios Institucionales
El desarrollo de repositorios digitales en el seno de las instituciones académicas es una
necesidad que gana cada vez mayor importancia no sólo para difundir la producción
corporativa, es decir, los contenidos culturales, científicos técnicos y divulgativos de los
miembros de una institución, sino también para poder disponer de sistemas que permitan su
reaprovechamiento en la propia institución, así como de un mecanismo eficaz para facilitar su
gestión. Todo ello tiene lugar en un contexto en el que la producción académica ya se expresa
18
en medios digitales que requieren de nuevos mecanismos y prácticas para facilitar su gestión y
administración.
Como se ha mencionado antes, los repositorios institucionales es una de las dos vías, la
llamada ruta verde, vías que se están desarrollando para llevar a cabo el movimiento Open
Access al conocimiento, es decir, hacer disponibles en Internet la literatura científica para que
cualquier usuario pueda reutilizarla (leerla, descargarla, copiarla, distribuirla, imprimirla). La
segunda vía, la dorada, se basa en publicar los artículos en revistas de acceso abierto. Por lo
que se refiere a la publicación en repositorios como complemento a la publicación en las
revistas tradicionales, cabe destacar que el número de nuevos repositorios va en creciente
evolución.
Aún cuando el acceso abierto a la información científica es actualmente el principal motivo
para el desarrollo y florecimiento de repositorios institucionales, en realidad, éstos ya van más
allá del propio movimiento para consolidarse como plataformas útiles para las instituciones
que los promueven y convirtiéndose un completo entorno de gestión para la producción
científica de las mismas. Los principales objetivos de los repositorios son: aumentar la
visibilidad de la propia organización y de sus autores, incrementar el impacto de los resultados
de la institución –especialmente los que emanan de las actividades de investigación-, acelerar
la eficiencia del progreso de la ciencia y mejorar la evaluación y la administración de la
actividad científica. Quizás uno de los aspectos que más ha influido en la creación de
repositorios institucionales ha sido el incremento de precios de las revistas científicas así como
la creciente importancia de la investigación y de su difusión en la sociedad (Vives et al.,
2009).
2.3.2 Metadatos
Según Voutssás (2005), Un metadato es un elemento que describe el contenido, condiciones,
características, etcétera, de un documento, con el fin de definir, identificar, organizar, indizar,
filtrar, colocar, preservar, recuperar y administrar ese documento como una parte de un
19
conjunto ordenado de recursos de información, ya sean electrónicos o no. Por otro lado,
Martínez y Navarra (2007) consideran que los metadatos son un conjunto de elementos que
poseen una semántica comúnmente aceptada, que surgieron de la necesidad de recuperar la
información electrónica dispersa.
Para Voutssás (2005) los metadatos pueden crearse para describir los atributos inherentes de
un recurso documental cualquiera que este sea: objeto bibliográfico (libro revista, tesis,
etcétera), registros e inventarios archivísticos, entre los más comunes.
2.3.3 Dublín Core
Para generar metadatos es necesario apegarse a algún estándar de metadatos bien definido para
lograr una homogeneidad y estructura organizada en la información que se transmite (IEEE,
2010). Dublín Core es uno de los estándares de metadatos de mayor aplicación y que ha dado
lugar incluso a otros formatos. El modelo de metadatos Dublín Core es un esfuerzo
internacional e interdisciplinar abocado a definir el conjunto de elementos básicos para
describir los recursos electrónicos y facilitar su recuperación (DCMI, 2010).
El estándar Dublín Core consta de quince campos subdivididos en tres grupos: Contenido,
Propiedad intelectual y Aplicación, los cuales se encuentran resumidos en la tabla 1.
Tabla 1. Campos del estándar de generación de metadatos Dublín Core
CONTENIDO PROPIEDAD INTELECTUAL APLICACIÓN
Título (Title). Creador (Creator). Fecha (Date).
Materia (Subject). Editor (Publisher). Formato (Format).
Descripción (Description). Colaborador (Contributor). Identificador (Identifier).
Fuente (Source). Derechos (Rights). Tipo (Type).
Relación (Relation). Lenguaje (Language).
Cobertura (Coverage).
20
Enseguida se describen brevemente cada una de las etiquetas que conforman el estándar de
generación de metadatos Dublín Core.
- Contenido. En este grupo se encuentran siete campos que describen el contenido de los
datos, éstos son:
Título (Title). Se refiere al título que lleva por nombre el documento.
Materia (Subject). En este campo se hace referencia a los diversos temas que puede
contener el material.
Descripción (Description). Se hace un breve resumen sobre el contenido del objeto
digital.
Fuente (Source). Es como una pequeña ficha bibliográfica que se elabora para asentar
los datos sobre la procedencia del documento original.
Relación (Relation). Este campo tiene que ver con el material principal u objetos de su
misma referencia, ya sea una colección, una serie, un documento, etcétera.
Cobertura (Coverage). Este campo se refiere al proyecto o sitio donde estará
resguardada la información. Aquí pueden anotarse fechas o zonas geográficas por
ejemplo.
- Propiedad Intelectual. En este grupo se encuentran cuatro campos que se encargan de
describir los datos referentes al creador del objeto o recurso en cuestión, éstos son:
Creador (Creator). Aquí se anota el autor intelectual de la obra o documento original.
Editor (Publisher). Este campo se refiere al sitio o colección responsable, a la que está
adscrito el material.
Colaborador (Contributor). En este campo se anotan, si es que se da el caso, el nombre
u organización que contribuyó a la creación del material, que no se especificó en la
parte de Creador.
Derechos (Rights). Se anota en este campo el nombre o la institución a la cual
pertenece el material y lo facilitó.
21
- Aplicación. En este grupo se encuentran cinco campos que describen datos referentes la
creación y origen del objeto o recurso en cuestión, éstos son:
Fecha (Date). Se anota la fecha de elaboración del registro.
Formato (Format). En este campo se registra el tipo de extensión con que se presenta
el objeto digital, ya sea HTML, JPG, GIFF o PDF.
Identificador (Identifier). Se refiere a la dirección electrónica de origen a la que está
adscrito el material. Para ello se utilizan las siglas URL.
Tipo (Type). Aquí se menciona la presentación que tiene el objeto digital, ya sea como
texto, audio, video, etcétera.
Lenguaje (Language). En este campo se establecen las siglas correspondientes al
idioma en que se presenta la publicación.
2.3.4 Protocolo OAI-PMH
El protocolo para la transmisión de contenidos en internet OAI-PMH (Open Access Initiative
– Protocol for Metadata Harvesting) consiste en una interfaz sencilla que se utiliza para
acceder a la información bibliográfica disponible en un archivo o repositorio. Se creó con la
misión de desarrollar y promover estándares de interoperabilidad para facilitar la difusión
eficiente de contenidos en Internet (OAI, 2008). Utiliza transacciones HTTP para emitir
preguntas y obtener respuestas entre un servidor o archivo y un cliente o servicio recolector de
metadatos donde el cliente puede pedir al servidor que le envíe metadatos según determinados
criterios, como por ejemplo la fecha de creación de los datos. En respuesta, el servidor
devuelve un conjunto de registros en formato XML, incluyendo identificadores (URL’s por
ejemplo) de los objetos descritos en cada registro.
Búsquedas simultáneas y recolección de metadatos
22
Las ideas previas al surgimiento del protocolo OAI-PMH demandaban alternativas viables que
proporcionaran al investigador y al usuario final la mejor opción para depositar y consultar
trabajos científicos. Finalmente, después de mucho debatir, se propusieron dos alternativas:
Búsquedas simultáneas.
Recolección de metadatos.
Las búsquedas simultáneas planteaban la posibilidad de explorar paralelamente diferentes
servidores de datos utilizando un procedimiento determinado o algún tipo de protocolo para
obtener resultados, sin embargo la experiencia de los expertos sobre las búsquedas simultáneas
revelaba que éstas no eran del todo viables dado que la velocidad del proceso de búsquedas de
este tipo se ve reducida en relación a la velocidad misma de cada uno de los servidores
implicados en ella, entonces, cuanto mayor fuese el número de servidores implicados en las
búsquedas simultáneas mayor sería la probabilidad de encontrar servidores con un pobre
rendimiento y esto a su vez implicaría que la búsqueda simultánea no fuese eficiente.
A su vez, la diferencia de tecnologías utilizadas entre distintos servidores y la falta de
interoperabilidad entre los mismos, generaría resultados inconsistentes e inesperados en
algunos casos; eso sin mencionar que sería difícil desarrollar una interfaz de navegación
eficiente dado que los objetos de búsqueda por los que sería necesario navegar estarían
distribuidos en diferentes servidores.
Al analizar las desventajas que implicaban las búsquedas simultáneas, los expertos
consideraron que la mejor solución sería reunir todos los registros de material científico en un
solo lugar y optaron por implementar la recolección de metadatos.
La recolección de metadatos consiste en crear una colección de recursos conformada a partir
de una recopilación de metadatos obtenidos desde diferentes servidores, de esta manera el
número de servidores a consultar se reduciría a uno, mejorando significativamente el
rendimiento de las búsquedas. Así mismo, al enfocarse en un solo servidor, es mucho más
23
sencillo crear una interfaz de navegación venciendo la barrera de la interoperabilidad, así
también el proceso de ordenación de recursos se realiza de una manera más eficiente.
Proveedores de datos y proveedores de servicios
En todo este entorno de intercambio de contenidos en Internet existen dos actores
fundamentales:
Los proveedores de datos.
Los proveedores de servicios.
Los proveedores de datos son aquellos que contienen y resguardan los contenidos
estandarizados. Estos proveedores de datos son los encargados de organizar los metadatos de
sus repositorios para ser puestos a disposición de los proveedores de servicios. Los
proveedores de datos son los encargados de garantizar la permanencia y conservación de los
metadatos y mantenerlos siempre disponibles para su recolección en Internet.
A su vez, los proveedores de servicios son aquellos que acceden a los proveedores de datos
para recolectar sus metadatos y a su vez, utilizan los metadatos recolectados para ofrecer
servicios. Estos servicios pueden ser variados, sin embargo, uno de los servicios más comunes
que ofrecen los proveedores de datos es el de búsquedas a través de una interfaz de usuario.
Cabe mencionar que un proveedor puede jugar los dos papeles, es decir, puede funcionar
como proveedor de datos y como proveedor de servicios a la vez. Dicho en otras palabras, un
proveedor funciona de ambas maneras cuando es capaz de ofrecer metadatos para ser
recolectados (proveedor de datos) y cuando ofrece servicios al usuario final utilizando
metadatos (proveedor de servicios).
24
El factor clave y desafiante en este entorno fue el hecho de idear una nueva arquitectura que
no sólo ofreciera interfaces para actores humanos, sino que además las ofreciera también para
máquinas recolectoras de metadatos, de esta manera se han podido crear interfaces para
usuario humanos y a la vez, interfaces para máquinas que pueden recolectar metadatos de
otros proveedores utilizando sus propias interfaces.
Versiones de OAI-PMH
Para definir una versión inicial del protocolo OAI-PMH los expertos de la OAI (Open Access
Initiative) debatieron y expusieron diferentes alternativas y puntos de vista con el objetivo de
encontrar la manera más eficiente de facilitar la recolección de metadatos entre diferentes
proveedores en Internet. Al final del debate, todos coincidieron en que debía existir un acuerdo
claro en cuanto a (Carpenter, 2003):
Un protocolo de transporte (HTTP o FTP, por ejemplo).
Un formato de metadatos (MARC o Dublín Core, por ejemplo).
Una base para el control de calidad de los metadatos (conjunto de elementos
obligatorios, convenciones sobre nombres y materias, etc.).
Propiedad intelectual y derechos de uso (¿quién puede hacer qué con qué?).
El acuerdo conjunto de los expertos respecto a los cuatro puntos fundamentales mencionados
arriba, permitió desarrollar una primera versión del protocolo para la recolección de metadatos
en Internet, esta primera versión fue llamada “Convenio de Santa Fe”, haciendo referencia al
lugar de encuentro de los expertos donde se consolidó este acuerdo.
En la figura 4 se muestra una comparativa entre los diferentes versiones del protocolo OAI-
PMH desde su primera versión llamada “Convenio de Santa Fe” hasta la versión 2.0 vigente
hasta ahora. Las marcas rojas indican las diferencias significativas entre cada una de las
versiones del protocolo.
25
Figura 4. Comparativa entre las tres diferentes versiones del protocolo OAI-PMH (Carpenter, 2003)
Como se mencionó antes, la “Convención de Santa Fe” fue la primera versión implementada
del protocolo OAI-PMH y tenía como objetivo primordial mejorar las búsquedas de material
científico autoarchivado por los mismos autores.
El siguiente paso en el desarrollo del protocolo OAI-PMH fue la versión 1.0 que incluyó, entre
sus principales mejoras, la implementación de Dublín Core no cualificado como el estándar de
metadatos mínimo para garantizar la interoperabilidad entre metadatos a transmitir utilizando
este protocolo. Otro diferencia sustancial respecto a la primera versión del mismo, fue un
cambio en el enfoque para facilitar ya no sólo la búsqueda de material autoarchivado por los
autores, sino también de todos aquellos “objetos tipo documento” (Carpenter, 2003). Se
trataba de una especificación de interoperabilidad sencilla que pretendía únicamente ofrecer
una alternativa para la recolección de metadatos, por lo cual, no proporcionaba soporte para
búsquedas; es decir, se enfocaba solamente al aspecto de recolección de metadatos entre los
repositorios de los proveedores de datos en Internet. A partir de esta versión se usó ya el
nombre oficial del protocolo: “el protocolo OAI-PMH”.
26
La versión OAI-PMH 1.1 no fue más que una corrección de la versión 1.0 donde se incluyeron
los cambios de XML schema que los proveedores de datos utilizaban para enviar sus
respuestas a los proveedores de servicios. Cabe mencionar que tanto la versión 1.0 y la 1.1
fueron solamente de propósito experimental.
La versión más reciente del protocolo OAI-PMH es la 2.0 que implicó una revisión más
intensa y minuciosa de las versiones anteriores, tal fue la intensidad y corrección respecto a las
versiones anteriores, que la 2.0 no es compatible con ellas. Una vez más se amplió el enfoque
del protocolo y ahora se dice que se trata “el intercambio recurrente de metadatos de recursos
entre distintos sistemas” (Carpenter, 2003). La versión 2.0 del protocolo sigue siendo una
especificación de interoperabilidad de bajo nivel basado en la recolección de metadatos en
Internet.
A partir de la versión 2.0 el protocolo OAI-PMH deja de ser una versión experimental y se
convierte en una versión estable, así mismo la OAI se ha comprometido a que las versiones
posteriores del protocolo sean compatibles hacia atrás (Carpenter, 2003).
Flexibilidad de implementación
OAI-PMH permite ser implementado de distintas maneras dependiendo de los objetivos y
necesidades de cada caso. Permite ser implementado de manera relativamente sencilla y
flexible dado que es un protocolo basado en HTTP y XML, tecnologías totalmente
compatibles con la Web.
Aún cuando los metadatos y el texto completo de los recursos que éstos describen son por lo
general puestos a disposición de manera libre, esto no es necesariamente un requisito. Existen
escenarios en los que el protocolo OAI-PMH puede utilizarse entre grupos cerrados como por
ejemplo en la distribución de metadatos de aplicaciones comerciales (Carpenter, 2003).
27
Enseguida se muestran algunos diagramas que muestran diferentes formas en que sistemas
basados en el protocolo OAI-PMH pueden configurarse.
Entre los diferentes tipos de implementación del protocolo, podemos encontrar tres de los más
usuales, el primero y más común de ellos es aquel en el que varios proveedores de servicios
pueden recolectar metadatos de varios proveedores de datos. Un ejemplo de este tipo de
implementación se muestra en la figura 5.
Figura 5. Implementación más común del protocolo OAI-PMH (Carpenter, 2003).
Otra tipo de implementación existente es aquella en la que un agregador de servicios se sitúa
de manera intermedia entre proveedores de servicios y proveedores de datos actuando de
ambas maneras. En la figura 6 se muestra un ejemplo de este tipo de implementación.
Una tercera implementación y la más rara de encontrar en un sistema funcional real es aquella
donde se combinan diferentes protocolos de transmisión de contenidos. Es raro encontrarse
con una implementación real de este tipo ya que por lo general se utiliza sólo un protocolo de
transmisión para evitar problemas de incompatibilidades entre los mismos. En la figura 7 se
muestra un ejemplo de este tipo de implementación.
28
Figura 6. Implementación con un agregador de servicios intermedio (Carpenter, 2003).
Figura 7. Combinación de diferentes protocolos (Carpenter, 2003).
Como podemos darnos cuenta, la flexibilidad del protocolo OAI-PMH ofrece varias
posibilidades de implementación y es quizá esta característica la que lo posiciona como uno de
los protocolos de transmisión de contenidos que han ganado mayor popularidad en los últimos
años.
Funcionamiento de OAI-PMH
En la figura 8 se muestra un diagrama básico del funcionamiento del protocolo OAI-PMH
donde se puede observar la interacción y el flujo de información entre un proveedor de datos y
un proveedor de servicios.
29
Figura 8. Interacción entre un proveedor de datos y un proveedor de servicios (Carpenter, 2003).
En el diagrama se observa cómo el proveedor de servicios llama al proveedor de datos usando
peticiones HTTP, en estas peticiones el proveedor de servicios le pide al proveedor de datos
que le envíe los metadatos que cumplan con ciertos parámetros enviados junto con las
peticiones HTTP, en caso de que no existan dichos parámetros, el proveedor de datos
entenderá que debe enviar toda la colección de metadatos existente en sus repositorios.
Evidentemente este procedimiento de envío total de metadatos se puede complicar en casos en
los que la colección de metadatos de un determinado proveedor de datos sea demasiado grande,
sin embargo el protocolo también ofrece una alternativa a este posible problema de control de
flujo utilizando señales de reanudación entre proveedores de datos y proveedores de servicios.
El tema de control de flujo se detalla más adelante.
Modelo estructural
El proceso de peticiones y respuestas entre proveedores de servicios y proveedores de datos
utilizando el protocolo OAI-PMH es relativamente sencillo. En la figura 9 se muestra un
modelo estructural que denota cómo se lleva a cabo dicho proceso en el que un proveedor de
servicios realiza peticiones a varios proveedores de datos de diferentes áreas de interés y
recibe respuestas a sus peticiones tomando en cuenta los parámetros especificados
inicialmente.
Como se ha mencionado antes, el protocolo OAI-PMH está basado en HTTP, por lo tanto los
parámetros de las peticiones que realiza el proveedor de servicios a los proveedores de datos
se proporcionan como parámetros GET o POST.
30
Figura 9. Modelo de peticiones y respuestas utilizando OAI-PMH (Carpenter, 2003).
En la figura se muestran también los seis tipos de peticiones (también llamadas verbos) que
soporta el protocolo OAI-PMH. Estas peticiones son (Carpenter, 2003):
Identify (Solicita le descripción de un archivo).
ListMetadataFormats (Recupera los formatos de metadatos disponibles de un
proveedor de datos).
ListSets (Recupera la estructura de organización de un proveedor de datos).
ListIdentifiers (Recupera sólo las cabeceras de los registros de un proveedor de
datos).
ListRecords (Recolecta registros de un proveedor de datos).
GetRecord (Recupera los metadatos de un registro individual de un proveedor de
datos).
31
Las respuestas a todas las peticiones están estructuradas con XML. El formato de metadatos
Dublín Core es el estándar mínimo para garantizar la interoperabilidad entre sistemas que
utilicen OAI-PMH, sin embargo este protocolo admite cualquier tipo de formato de metadatos
siempre y cuando éstos estén estructurados con XML.
Control de flujo
Cuando un proveedor de datos cuenta con una amplia colección de metadatos y todos éstos
son recolectados por algún proveedor de servicios, el tráfico en la red puede ser crítico y
garantizar la transferencia de todos ellos no sería posible sin una buena gestión del control de
flujo.
En la figura 10 se muestra un ejemplo del control de flujo de metadatos existente entre un
proveedor de servicios y un proveedor de datos al momento de una petición que devuelve una
cantidad considerable de metadatos.
Figura 10. Control de flujo entre proveedores de datos y servicios (Carpenter, 2003).
32
Como se muestra en la figura, la gestión del control de flujo es útil en listados largos donde se
utilizan señales de reanudación para llevar un orden y un control adecuados minimizando de
esta manera la generación de errores durante el proceso de recolección de metadatos.
2.3.5 XML
XML (Extensible Markup Language o lenguaje de anotación extensible) es un lenguaje de marcas que
ofrece un formato para la descripción de datos estructurados. Es decir, XML es un metalenguaje, dado
que con él podemos definir nuestro propio lenguaje de presentación y, a diferencia del HTML, que se
centra en la representación de la información, XML se centra en la información en sí misma. La
particularidad más importante del XML es que no posee etiquetas prefijadas con anterioridad, ya que
es el propio diseñador el que las crea a su antojo, dependiendo del contenido del documento. XML es
un formato basado en texto, específicamente diseñado para almacenar y transmitir datos. Un
documento XML se compone de elementos XML, cada uno de los cuales consta de una etiqueta de
inicio, de una etiqueta de fin y de los datos comprendidos entre ambas etiquetas. Al igual que los
documentos HTML, un documento XML contiene texto anotado por etiquetas. Sin embargo, a
diferencia de HTML, XML admite un conjunto ilimitado de etiquetas, no para indicar el aspecto que
debe tener algo, sino lo que significa (Arellano, et al., 2009).
Objetivos y orígenes de XML
XML fue desarrollado por un grupo de trabajo bajo los auspicios del consorcio World Wide
Web (W3C) a partir de 1996. Este fue constituido en 1994 con el objetivo de desarrollar
protocolos comunes para la evolución de Internet. Se trata de un consorcio de la industria
internacional con sedes conjuntas en el Instituto Tecnológico de Massachussets, de Estados
Unidos, el Instituto Nacional de Investigación en Informática y Automática europeo y la Keio
University Shonan Fujisawa Campus de Japón. El W3C tiene como misión la publicación para
uso público de protocolos o estándares globales de uso libre. Al comenzar el proyecto, los
33
objetivos planteados por el grupo de desarrollo del XML fueron diez puntos (Arellano, et al.,
2009).
1. XML debe ser directamente utilizable sobre Internet.
2. XML debe soportar una amplia variedad de aplicaciones.
3. XML debe ser compatible con SGML.
4. Debe ser fácil la escritura de programas que procesen documentos XML.
5. El número de características opcionales en XML debe ser absolutamente mínimo,
idealmente cero.
6. Los documentos XML deben ser legibles por los usuarios de este lenguaje y
razonablemente claros.
7. El diseño de XML debe ser formal, conciso y preparado rápidamente.
8. XML debería ser simple pero perfectamente formalizado.
9. Los documentos XML deben ser fáciles de crear.
10. La brevedad en las marcas XML es de mínima importancia.
2.3.6 PHP
PHP (Hipertext Preprocessor o Preprocesador de hipertexto) es un lenguaje de scripting
embebido en HTML. Mucha de su sintaxis es tomada de C, Java y Perl con un par de
características adicionales únicas y específicas de PHP. El propósito del lenguaje es permitir
que los desarrolladores web escriban páginas generadas dinámicamente con rapidez. El fácil
uso y la similitud con los más comunes lenguajes de programación estructurada, como el C y
el Perl, permiten a la mayoría de los programadores experimentados crear aplicaciones
complejas con una curva aprendizaje muy suave. También les permite envolverse con
aplicaciones de contenido dinámico sin tener que aprender todo un nuevo grupo de funciones
y prácticas. Su interpretación y ejecución se da en el servidor en el cual se encuentra
almacenada la página y el cliente sólo recibe el resultado de la ejecución. Cuando el cliente
hace una petición al servidor para que le envíe una página web, enriquecida con código PHP,
34
el servidor interpretará las instrucciones mezcladas en el cuerpo de la página y las sustituirá
con el resultado de la ejecución antes de enviar el resultado a la computadora del cliente (Cobo
et al., 2005).
Una característica importante de PHP es su independencia de plataforma, es decir, se puede
ejecutar en cualquier sistema operativo actual, tales como Windows, UNIX, Linux y Mac OS
X. PHP también puede acoplarse a los servidores Web más comúnmente usados.
2.3.7 MySQL
MySQL es uno de los Sistemas Gestores de bases de Datos (SQL) más populares desarrolladas
bajo la filosofía de código abierto. Se puede decir también que MySQL es un gestor de base de
datos sencillo de usar e increíblemente rápido. También es uno de los motores de base de
datos más usados en Internet, la principal razón de ésto es que es gratis para aplicaciones no
comerciales. La desarrolla y mantiene la empresa MySql AB pero puede utilizarse
gratuitamente y su código fuente está disponible (Ullman, 2006).
Características de MySQL
Inicialmente, MySQL carecía de elementos considerados esenciales en las bases de datos
relacionales, tales como integridad referencial y transacciones. A pesar de ello, atrajo a los
desarrolladores de páginas web con contenido dinámico, justamente por su simplicidad;
aquellos elementos faltantes fueron llenados por la vía de las aplicaciones que la utilizan. Poco
a poco los elementos faltantes en MySQL están siendo incorporados tanto por desarrollos
internos, como por desarrolladores de software libre. Entre las características disponibles en
las últimas versiones se destacan (Converse et al., 2004):
35
Amplio subconjunto del lenguaje SQL. Algunas extensiones son incluidas
igualmente.
Disponibilidad en gran cantidad de plataformas y sistemas.
Diferentes opciones de almacenamiento según si se desea velocidad en las
operaciones o el mayor número de operaciones disponibles.
Transacciones y claves foráneas.
Conectividad segura.
Replicación.
Pero principalmente:
Es un gestor de base de datos. Una base de datos es un conjunto de datos y un gestor de
base de datos es una aplicación capaz de manejar este conjunto de datos de manera
eficiente y cómoda.
Es una base de datos relacional. Una base de datos relacional es un conjunto de datos
que están almacenados en tablas entre las cuales se establecen unas relaciones para
manejar los datos de una forma eficiente y segura. Para usar y gestionar una base de
datos relacional se usa el lenguaje estándar de programación SQL.
Es Open Source. El código fuente de MySQL se puede descargar y está accesible a
cualquiera, por otra parte, usa la licencia GPL para aplicaciones no comerciales.
Es una base de datos muy rápida, segura y fácil de usar. Gracias a la colaboración de
muchos usuarios, la base de datos se ha ido mejorando optimizándose en velocidad.
Por eso es una de las bases de datos más usadas en Internet.
Existe una gran cantidad de software que la usa.
36
2.3.8 Servidor Apache
El servidor HTTP Apache es un servidor HTTP de código abierto para plataformas Unix (BSD,
GNU/Linux, etcétera), Windows y otras, que implementa el protocolo HTTP/1.1 (RFC 2616)
y la noción de sitio virtual. Cuando comenzó su desarrollo en 1995 se basó inicialmente en
código del popular NCSA HTTPd 1.3, pero más tarde fue reescrito por completo. Su nombre
se debe a que originalmente Apache consistía solamente en un conjunto de parches a aplicar al
servidor de NCSA. Era, en inglés, a patchy server (un servidor parcheado). Apache presenta
entre otras características mensajes de error altamente configurables, bases de datos de
autenticación y negociado de contenido, pero fue criticado por la falta de una interfaz gráfica
que ayude en su configuración. Apache es el servidor Web hecho por excelencia, su
configurabilidad, robustez y estabilidad hacen que cada vez millones de servidores reiteren su
confianza en este programa (Gilmore, 2008).
2.3.9 HTML
HTML son las siglas de "HyperText Mark-up Language". "Mark-up" es un término de
imprenta que significa el conjunto de instrucciones estilísticas detalladas escritas en un
manuscrito que debe ser tipografiado. Así, HTML podría ser traducido como "Lenguaje de
Formato de Documentos para Hipertexto". HTML es una aplicación de SGML, un lenguaje
muy general para definir lenguajes de formato de documentos. A principios de 1993 había
alrededor de 50 servidores. Existían básicamente dos tipos de browsers: el original, gráfico,
pero sólo para plataformas NeXT, y el browser en modo de línea, preparado para cualquier
plataforma pero muy limitado y muy poco atractivo. En Febrero del 93 se lanzó la primera
versión alfa del navegador "Mosaic for X", desarrollado en el NCSA (National Center for
Supercomputing Applications, Centro Nacional para Aplicaciones de Supercómputo).
Funcionaba en X Windows, que era una plataforma popular entre la comunidad científica. En
Abril del 93 el tráfico de la WWW era el 0.1% del total de Internet. El CERN declaraba la
WWW como tecnología de acceso gratuito. En septiembre ya había versiones de Mosaic para
37
PC y Macintosh. El tráfico alcanzaba el 1% de todo el tráfico de Internet y había más de 500
servidores (Castro, 2003).
En este capítulo se exhibió una visión general de la situación actual y las tendencias en cuanto
a Repositorios Institucionales y el movimiento Open Access, se explicó la declaración de
Budapest como el suceso detonante del movimiento Open Access, también se describió
concisamente lo que son los metadatos, el estándar de generación de metadatos Dublín Core y
el protocolo OAI-PMH.
En el siguiente capítulo se describe en profundidad el análisis y la metodología empleada en el
desarrollo del sistema utilizando métodos de ingeniería de software tales como diagramas de
requerimientos de usuario y modelos de desarrollo de sistemas.
38
CAPÍTULO 3. Análisis del Sistema
En este capítulo se describe la metodología empleada para el desarrollo del sistema utilizando
métodos de Ingeniería de Software tales como diagramas de requerimientos de usuario y
modelos de desarrollo de sistemas, así como también las variables adecuadas para el diseño
del sistema.
3.1 Descripción de la metodología
A continuación se describe la metodología seguida para lograr nuestro principal objetivo de
implementar una confiable cosecha y recolección de metadatos a través de diferentes
repositorios institucionales en internet.
En la figura 11 se muestra un diagrama de la metodología seguida para lograr los objetivos
planteados al principio, y enseguida se hace su respectiva descripción.
Figura 11. Diagrama de la metodología empleada.
Representar
metadatos a
través de XML
Garantizar la
conectividad
entre diferentes
RI
Cosechar y
exportar
metadatos entre
diferentes RI
Implementar un
buscador de
material
bibliográfico
39
Representar metadatos a través de XML.- Como lo establece el protocolo OAI-PMH y
dado que XML es actualmente el lenguaje líder para la transferencia de datos en Internet, para
compartir los metadatos propios del sistema es necesario estructurarlos y estandarizarlos
implementando XML.
Para lograrlo, en el caso de esta investigación, se desarrolló un módulo capaz de generar un
metadato Dublín Core por cada registro de material científico almacenado en la base de datos.
Dicha conversión se llevó a cabo siguiendo las especificaciones marcadas por el estándar de
generación de metadatos Dublín Core. Una vez estructurados los metadatos, estos son
almacenados en un repositorio del servidor donde se encuentran disponibles para ser
recolectados por otros cosechadores y recolectores de metadatos, también llamados
proveedores de servicios.
Garantizar la conectividad entre diferentes RI.- Evidentemente en una red pueden surgir
diferentes tipos de errores, uno de los más comunes es la desconexión o la pérdida de enlace
entre dos o más nodos. Sin embargo este tipo de problemas están fuera de nuestro control y en
estos casos, lo mejor que podemos hacer es implementar procedimientos a seguir en caso de
que ocurra una eventualidad de este tipo para recuperarse con el menor daño o pérdida posible
en casos en los que se está haciendo una cosecha remota, por ejemplo.
En estos casos resulta útil emplear especificaciones de control de flujo como las mencionadas
en la descripción del protocolo OAI-PMH en el capítulo 2.
Cosechar y exportar metadatos entre diferentes RI.- Es en este punto donde realmente
entra en acción el protocolo OAI-PMH. Es aquí donde los proveedores de datos y los
proveedores de servicios interactúan entre sí conforme al protocolo OAI-PMH para brindar
sus servicios respectivos. El proveedor de datos, quien es responsable de resguardar y
garantizar la permanencia vigente de una determinada colección de metadatos, debe ser capaz
de poner dicha colección de metadatos a disposición de los proveedores de servicios quienes
se dedican a recolectar metadatos y usarlos para brindar servicios al usuario final.
40
Con base en lo antes mencionado, el sistema desarrollado en esta investigación tiene las
siguientes funcionalidades:
Proveedor de datos que ofrece a otros proveedores de servicios, material científico
creado por investigadores de la Universidad de Colima.
Proveedor de servicios capaz de acceder a los proveedores de datos de otras
organizaciones e instituciones científicas.
Implementar un buscador de material bibliográfico.- Como se ha mencionado antes y dado
que el sistema desarrollado es también un proveedor de servicios, éste es capaz de brindar
funcionalidades al usuario final empleando los metadatos propios y los cosechados de otros
proveedores de datos.
Uno de los servicios fundamentales con los que cuentan la mayoría de los proveedores de
servicios es la posibilidad de brindarle al usuario final la oportunidad de buscar metadatos en
base a determinados parámetros definidos por las necesidades particulares de cada uno de
ellos. Es un hecho que sin la implementación de un buen buscador, un proveedor de servicios
es incapaz de explotar todas sus posibilidades.
Dada la importancia que tiene en un proveedor de servicios, el sistema desarrollado fue
provisto de un buscador donde el usuario final puede acceder y consultar los metadatos tanto
de la Universidad de Colima como de otras organizaciones e instituciones científicas
obteniendo información científica confiable de libre acceso y respaldada por investigadores
reconocidos.
En la Figura 12 se muestra la ontología de material científico usada en este proyecto y su
descripción se hace en los párrafos siguientes.
La ontología muestra como nodo jerárquico un repositorio institucional Green Access que
ofrece un conjunto de servicios que una o varias instituciones ofrecen a los miembros de su
41
comunidad para la gestión y la difusión de los materiales digitales creados por la misma
institución y su comunidad de miembros, el cual se divide a su vez en dos tipos de trabajos de
investigación: científica y académica.
Figura 12. Ontología del esquema propuesto
Según Velez (2001) la investigación científica es el proceso sistemáticamente ordenado, cuyo
objetivo es la demostración de hipótesis o la confirmación y desarrollo de teorías. Ésta
comprende trabajos como:
Artículos científicos: Robert Day (2005) define el artículo científico como un
informe escrito y publicado que describe resultados originales de investigación que
debe ser escrito y publicado de cierta forma, definida por tres siglos de tradiciones
cambiantes: práctica editorial, ética científica e influencia recíproca de los
procedimientos de impresión y publicación.
Informes de investigación: Es un documento que tiene como propósito primordial
comunicar de forma concreta y breve los resultados de una determinada investigación
independientemente del área a la que pertenezca.
Repositorio
Institucional Green
Access
Investigación
Científica
Investigación
Académica
Artículos
científicos
Informes de
investigación
Tesis
Reportes
técnicos
Apuntes
Libros
Experimentos
42
Experimentos: Hernández y sus colegas (Hernández et al., 2003) afirman que es una
“situación de control en la cual se manipulan, de manera intencional, una o más
variables independientes (causas) para analizar las consecuencias de tal manipulación
sobre una o más variables dependientes (efectos)”.
Por otro lado la investigación académica, es mayoritariamente investigación básica con el
objetivo de elaborar teorías y modelos que expliquen y permitan predecir la realidad. La
investigación académica se lleva a cabo en instituciones de enseñanza superior dirigidas por
investigadores. Este tipo de investigación es formal y muy sistemática debido a que los
resultados que se obtienen son serios, ciertos y verdaderos. Comprende trabajos como:
Tesis: Es un trabajo de investigación de libre elección presentado por escrito y dirigido
por uno o varios profesores investigadores, que presenta un estudiante de nivel
superior como culminación de sus estudios para obtener el título o grado
correspondiente, ya sea licenciatura, maestría o doctorado.
Reportes técnicos: Es un documento que se presenta para informar de los
procedimientos y resultados de una determinada investigación de forma clara y
estructura lógica. Una característica fundamental del reporte técnico es que busca
presentar la investigación y no la personalidad del autor, es por eso que el tono es
impersonal y no se utiliza la primera persona.
Apuntes: Son documentos por lo general informales guardados por el autor durante
algún tiempo luego de la finalización de su trabajo que pueden ser consultados
posteriormente con el fin de esclarecer dudas o debates sobre algún punto de la
investigación.
Libros: Es una obra científica o literaria de cierta extensión configurada en un
volumen. Es un conjunto de cuantiosas hojas de papel impresas, con tapas de cartón o
cartulina, que forman un volumen.
43
3.2 Requerimientos de usuario
En esta sección se muestran de manera general los servicios que provee el sistema al usuario
final mediante diagramas de casos de uso para mostrar la interacción entre el usuario y el
sistema.
Los requerimientos de usuario son declaraciones, en lenguaje natural y en diagramas, de los
servicios que se espera que el sistema brinde y las restricciones bajo las cuales el sistema debe
operar (Pressman et al., 2002).
3.2.1 Servicios que brinda el sistema al usuario.
En la tabla 2 se ordenan los servicios que el sistema brinda al usuario humano final, seguido
de una breve descripción.
Tabla 2. Servicios que brinda el sistema al usuario.
No. de servicio Acción
1 Buscar en el sitio
2 Listar resultados de búsquedas en el sitio
3 Buscar material bibliográfico
4 Listar resultados de búsquedas bibliográficas
5 Consultar bibliografía
1. El sistema permite al usuario realizar búsquedas generales referentes a cualquier
contenido del sitio.
2. El sistema lista los resultados de búsquedas generales referentes a cualquier contenido
del sitio con su respectivo enlace cada uno.
3. El sistema permite al usuario realizar búsquedas del material bibliográfico almacenado
en los repositorios del mismo.
44
4. El sistema lista los resultados de búsquedas del material bibliográfico almacenado en
los repositorios del mismo con su respectivo enlace cada uno.
5. El sistema permite al usuario consultar el material bibliográfico listado resultante de la
búsqueda y visualizarlo en su monitor.
En la figura 13 se muestra de manera general la interacción entre el sistema y el usuario final
mediante un diagrama de casos de uso.
Figura 13. Interacción entre el sistema y el usuario final.
3.3 Requerimientos de sistema
En esta sección se describen los requerimientos que el sistema necesita para brindar sus
servicios óptimamente. Haciendo uso de diagramas de secuencia se muestra el flujo de
mensajes interactivos a lo largo del tiempo.
Buscar en el sitio
Buscar material
bibliográfico Usuario Final
Listar resultados de
búsquedas en el sitio
Listar resultados de
búsquedas bibl.
Consultar bibliografía
45
Los requerimientos del sistema establecen los detalles, los servicios y restricciones del sistema.
El documento de requerimientos del sistema, algunas veces nombrado especificación
funcional, debe ser formal. Éste sirve como un contrato entre el comprador del sistema y el
desarrollador del software (Pressman, et al., 2002).
3.3.1 Servicios requeridos por el sistema.
Así como el usuario expresa sus requerimientos al momento de desarrollar cualquier sistema
con el fin de satisfacer sus necesidades y solventar sus problemas, los sistemas también
demandan requerimientos de parte del usuario para funcionar y ser implementados de la
manera más óptima. Es así como el sistema desarrollado en esta investigación demanda
también requerimientos de parte del usuario.
En la tabla 3 se resumen los requisitos del sistema al momento que el usuario realiza una
búsqueda y/o consulta de material bibliográfico.
En la figura 14 se observa el diagrama de secuencias que muestra la interacción y el flujo de
mensajes entre el usuario y el sistema.
Primeramente el usuario accede al sistema y por medio del buscador incorporado en el mismo
procede a hacer una búsqueda determinada ingresando los parámetros o palabras clave del
tema de su interés en el buscador.
Enseguida el sistema hace la consulta en la base de datos de los metadatos almacenados en la
misma y regresa los resultados coincidentes con los parámetros de búsqueda que el usuario
ingresó al momento de realizar la acción. Mencionemos que, en caso de que el usuario no
ingrese ninguna palabra o parámetro de búsqueda en la interfaz del buscador, el sistema
regresará como resultado todos los registros de metadatos que contenga en su base de datos al
momento de hacer la búsqueda.
46
Tabla 3. Requerimientos del sistema.
Figura 14. Interacción entre el usuario y el sistema.
Función.- Buscar y/o consultar.
Descripción.- El sistema permite al usuario buscar y/o consultar el material
bibliográfico registrado en el mismo.
Entradas.- Alfanuméricas.
Fuente.- Usuario.
Salidas.- Interfaz gráfica en HTML que despliega los resultados de la búsqueda y/o
consulta realizada.
Destino.- Monitor.
Requerimientos.- Al introducir la cadena de texto, el sistema realiza la búsqueda en
todo el material bibliográfico registrado.
Precondición.- Ingresar en el navegador la URL del sistema.
Postcondición.- Ninguna.
Efectos colaterales.- Ninguno.
Usuario Sistema
Búsqueda de material bibliográfico
Selección del material deseado
Resultado de búsqueda
Material seleccionado
47
Una vez desplegados los resultados de la búsqueda en la pantalla del usuario, éste los
analiza y determina en un momento dado cuáles de esos resultados le son de utilidad y
procede a consultarlos requiriéndole al sistema la versión en texto completo dado que los
resultados mostrados al usuario en su pantalla inicialmente, muestran solamente
características relevantes del recurso en sí; características de un metadato tales como: título
de la obra, nombre(s) de autor(es), descripción, etc.
En caso de que el documento solicitado se encuentre en los repositorios del sistema
localmente, éste es desplegado en versión completa al usuario en su monitor en caso de
que se cuente con la versión en formato de archivo .pdf o se podrá descargar si se
encuentra en otro formato. En caso de que el documento completo haga referencia a un
archivo remoto, es decir, que se encuentre alojado en otro repositorio en Internet, el
usuario será redireccionado a la ubicación exacta del archivo utilizando el identificador
único de dicho archivo incluido en la información de su respectivo metadato; el cual,
obviamente se encuentra la base de datos del sistema local.
Es así como el usuario final realiza el proceso de consulta de material científico de libre
acceso en el sistema.
En este capítulo se describió en profundidad el análisis y la metodología empleada en el
desarrollo del sistema utilizando métodos de ingeniería de software tales como diagramas
de requerimientos de usuario y modelos de desarrollo de sistemas.
En el siguiente capítulo se describe el procedimiento de diseño del sistema luego del
análisis realizado en este capítulo y se incluyen las interfaces gráficas de mayor relevancia,
tomando en cuenta los requerimientos y el perfil del usuario final.
48
CAPÍTULO 4. Diseño del Sistema
En este capítulo se explica el proceso de diseño del sistema incluyendo algunas interfaces
gráficas tomando en cuenta los requerimientos y los diferentes perfiles de usuario a los que
el sistema está enfocado.
4.1 Diseño de interfaces
Uno de los factores más importantes a tomar en cuenta en el desarrollo del sistema son las
interfaces, estas deben ser amigables y atractivas hacia el usuario para que esté se interese
en el sistema y realice sus actividades con interés y de forma intuitiva. Si una interfaz es
relativamente compleja, el usuario puede rehusarse a usarla por temor a equivocarse o
simplemente provocará errores debido a la confusión que la interfaz le cause.
En la figura 15 se muestra un diagrama del proceso de diseño de interfaces de usuario.
Este proceso es iterativo y por lo tanto es común repetirlo más de una vez hasta lograr el
diseño deseado.
Figura 15. Proceso de diseño de interfaces de usuario.
49
Se debe mencionar que el sistema estará implementado dentro de la página Web de la
Secretaría de Investigación de la Universidad de Colima y se podrá acceder al mismo
mediante el menú de navegación de ésta. Dicha página también está siendo desarrollada a
la par del sistema en cuestión y aunque el desarrollo de la misma no es parte medular de
esta investigación, en adelante se muestran algunos elementos de su desarrollo con el
propósito de contextualizar la investigación.
Después de analizar los servicios que brinda el sistema y tomando en cuenta el perfil del
usuario promedio del mismo y de la página web en sí, se ha definido una plantilla general
para utilizarse en el proyecto.
En la figura 16 se muestra el esquema de bloques o módulos establecido durante la fase de
análisis de la interfaz principal de la página web, seguida de una descripción breve de cada
uno de sus módulos.
Figura 16. Esquema de la interfaz principal.
50
Encabezado. El encabezado se encuentra ubicado, como en la mayoría de sitios web, en la
parte superior de la interfaz. Dado que por lo general es lo primero que el usuario observa
a primera vista, dicho encabezado debe contener información acerca del contenido general
del sitio y de la Institución al que éste pertenece. Por lo tanto, el encabezado de este sitio
en particular estará conformado por un banner con el logotipo de la Universidad de Colima
seguido del texto “Coordinación General de Investigación Científica”.
Menú. El menú que contendrá las opciones de navegación dentro del sitio estará ubicado
justo a la izquierda de la interfaz y contendrá, además del enlace al sistema en cuestión,
enlaces a subpáginas del mismo sitio, tales como Misión, Visión, Proyectos, etc.
Centros de Investigación. Justo en la parte central de la interfaz estará ubicada una
sección que contendrá enlaces directos a cada uno de los centros de investigación de la
Universidad de Colima, ya sea a sus páginas particulares en caso de que las tengan o en
caso contrario a una página con información de contacto referente a cada uno de ellos.
Noticias. En la parte derecha de la interfaz se encontrará ubicada una sección de noticias y
boletines informativos con enlaces directos a páginas externas o internas donde se detallen
más a fondo.
Proyectos Internacionales. Justo debajo de la sección de noticias, en la parte derecha de
la interfaz, se encontrará ubicada una sección llamada “Proyectos Internacionales” donde
se pueda tener acceso a información, convocatorias, noticias, etc. De carácter internacional
donde los investigadores y el público en general puedan postularse o simplemente tener un
acceso más sencillo a todo tipo de gestiones e información científica de carácter
internacional relacionado a la Universidad de Colima.
Buscador. En la parte izquierda de la interfaz, justo debajo de la sección de menú se
encontrará ubicado un buscador donde el usuario puede ingresar y encontrar la
información del sitio que le interese en específico.
51
4.2 Diseño de la base de datos
Dado a que el sitio en sí mostrará información relevante del cuerpo académico de la
Universidad de Colima, así como de sus instalaciones y recursos científicos, es necesario
diseñar también, además de las interfaces, la base de datos que contendrá la información
antes mencionada.
En este proyecto en particular se utilizó MySQL como gestor de bases de datos debido a
que se adapta perfectamente a las tecnologías utilizadas y se adecúa a nuestras necesidades
para conseguir los objetivos buscados.
Después de analizar detenidamente los requerimientos de usuario y de sistema, se ha
decidido crear una base de datos con tres tablas, la primera es la que contiene el registro
del material científico almacenado en los repositorios del sistema y su estructura en
MySQL se muestra en la figura 17, la información almacenada en esta tabla es utilizada
para generar los metadatos relativos al material científico resguardado en el repositorio del
sistema. La segunda tabla es la relativa a la información del cuerpo académico de los
investigadores de la Universidad de Colima dado que la página cuenta con un catálogo de
investigadores con información relativa a cada uno de ellos. La tercera tabla contiene la
información de noticias y boletines informativos mostrados en la parte derecha de la
interfaz principal del sistema. Las estructuras en MySQL de las tablas de cuerpo
académico y de noticias se muestran en las figuras 27 y 28 respectivamente en la sección
de anexos al final de este documento.
En la estructura de la tabla podemos identificar las etiquetas que especifica el estándar de
generación de metadatos Dublín Core para describir el material bibliográfico de acuerdo al
dicho estándar (título, autor, descripción, editor, entre otros). Además de las etiquetas
especificadas por el estándar, se han agregado tres campos más en la misma tabla, estos
campos son:
52
Figura 17. Estructura en MySQL de la tabla de metadatos.
id (identificador). Utilizado para llevar un índice y mejor control de cada registro
almacenado en la tabla.
invest (investigación). Utilizado definir el tipo de investigación o de material del
que se trata. Este campo puede incluir valores como “Artículo científico”, “Tesis”,
“Libro”, “Reporte técnico”, “Experimento”, “Reporte de investigación” y
“Apuntes”.
Archivo. Dado no es útil almacenar archivos como tales en una base de datos, este
campo contiene la ruta del documento respectivo almacenado en el repositorio de
material bibliográfico en el servidor.
53
Interfaz principal
En la figura 18 se muestra la imagen de la interfaz principal, la interfaz con la que el
usuario se encontrará en primera instancia cuando ingrese en su navegador la URL del
sistema.
Figura 18. Interfaz principal del sistema.
La interfaz principal está pensada en un diseño minimalista tratando de contribuir en buena
medida a la usabilidad. Está estructurada con un menú de opciones a la izquierda donde el
usuario puede acceder a información relativa al CGIC (Centro General de Investigación
Científica), debajo de este menú se encuentra el buscador que se encuentra siempre visible
y accesible brindándole al usuario la posibilidad de buscar en cualquier momento sin
importar en qué sección del sitio se encuentre. En la parte central se puede acceder a los
54
diferentes centros de investigación dependientes del CGIC, mientras que en la parte
derecha se ubica una sección con noticias o boletines relevantes.
Interfaz de Centros de Investigación
En la figura 19 se muestra la interfaz de un centro de investigación en particular
(ingenierías) dependiente del CGIC.
Figura 19. Interfaz del centro de investigación de ingenierías.
La interfaz de los centros de investigación es aún más sencilla y minimalista que la interfaz
principal, ésta cuenta solamente con un menú situado justo a la izquierda con opciones
referentes a dicho centro y a la derecha muestra información básica sobre el mismo,
información tal como el director de dicho centro, su correo electrónico, etc. En cualquier
momento el usuario puede regresar a la interfaz inicial.
55
En este capítulo se describió el procedimiento de diseño del sistema, derivado del análisis
realizado en el capítulo anterior. Se mostraron algunas interfaces gráficas diseñadas tomando
en cuenta los requerimientos y el perfil del usuario final.
En el siguiente capítulo se describe el procedimiento de implementación del esquema a través
de un sistema o plataforma de software, así como las pruebas hechas al mismo y sus
respectivos resultados.
56
CAPÍTULO 5. Implementación y Pruebas
En este capítulo se detalla el procedimiento de implementación y la puesta en marcha del
sistema. También se discuten las pruebas realizadas al mismo y los resultados obtenidos en
cada una de éstas.
5.1 Implementación de interfaces
Como se mencionó anteriormente, el sistema fue implementado dentro de la página Web
de la Secretaría de Investigación de la Universidad de Colima donde puede ser accesado
desde el menú principal de opciones de dicha página, en la opción “Búsquedas
bibliográficas”. En la Figura 20 se resalta la opción del menú donde es posible tener
acceso al sistema.
Figura 20. Opción de acceso al sistema.
57
Una vez en el sistema, el usuario administrador del sitio, por medio de un usuario y una
contraseña únicos, podrá tener acceso a diversas opciones de gestión del sitio y de su
contenido, entre esas opciones se encuentra la de registrar material científico en el sistema
con el objetivo de resguardarlo de manera segura y de compartirlo con otros proveedores
de servicios en internet poniéndolo a disposición de los mismos por medio de su metadato
respectivo. Proporcionándole de ésta manera una mayor difusión a dicho material y
contribuyendo con la filosofía del movimiento de acceso abierto a la información científica
surgida con la convención de Budapest en el 2001.
En las figuras 21 y 22 se muestran imágenes del formulario usado por el administrador del
sistema para registrar material científico.
Figura 21. Formulario de registro de material bibliográfico 1/2.
58
Figura 22. Formulario de registro de material bibliográfico 2/2.
.
En el formulario de registro de material bibliográfico del sistema podemos identificar a las
quince etiquetas que especifica el estándar de generación de metadatos Dublín Core,
además de algunos otros campos añadidos como por ejemplo el tipo de investigación, que
especifica exactamente el tipo de material que se registra, por ejemplo libro, tesis, artículo
científico, experimento, etc.
Una vez que el administrador del sistema llena el formulario con los datos del registro que
el sistema espera recibir (requerimientos de sistema) y envía el formulario, se llevan a cabo
procesos como la validación de los datos en el formulario por ejemplo.
En caso de que todo esté correcto, es decir, si el formulario fue llenado con los datos
esperados por el sistema y si no existe ningún error de validación del formulario mismo,
entonces la información es procesada por el servidor. Si no surge ningún problema o error
durante el proceso de información por parte del servidor, el administrador del sistema es
59
retroalimentado con un mensaje de éxito indicando que el proceso se realizó exitosamente,
esto implica que la información fue registrada en la base de datos, que la versión completa
del documento fue almacenado correctamente en el repositorio de material bibliográfico
del sistema y que su metadato respectivo fue creado y almacenado en el repositorio de
metadatos locales del sistema.
En la figura 23 se muestra la notificación de éxito en caso de que todo el proceso de
registro haya sido correcto.
Figura 23. Notificación de registro exitoso.
Por otro lado, si ocurre algún error o surge algún problema durante el proceso de registro
del material bibliográfico en el sistema, éste devuelve un mensaje de error al administrador
notificándole que surgió algún problema durante el proceso, sugiriéndole volverlo a
intentar.
60
En la figura 24 se muestra la notificación de error en caso de que surja algún problema
durante el proceso de registro.
Figura 24. Notificación de registro erróneo.
Las pruebas se realizaron con base a una simulación en una red local donde se instaló el
sistema en dos computadoras diferentes simulando que cada una de ellas se trataba de una
institución educativa o científica y donde cada una de ellas cosechaba metadatos de la otra
Además de las interfaces generales de la página web mostradas anteriormente, enseguida
se muestran los diagramas representativos de la fase de implementación del sistema ya
puesto en marcha sobre una red local para fines demostrativos únicamente, obviamente el
sistema responde de igual manera a nivel Web.
61
5.2 Pruebas del sistema
A excepción de los programas pequeños, los sistemas no se prueban, como una simple
unidad monolítica. Los sistemas grandes se construyen a partir de subsistemas que a su vez
se construyen a partir de módulos que están compuestos de procedimientos y funciones.
Por lo tanto, el proceso de prueba se lleva a cabo en etapas en las que las pruebas se
aplican de forma incremental en conjunto con la implementación del sistema (Sommerville
y Domínguez Torres, 2002).
La figura 25 muestra un proceso de pruebas de cinco etapas en las cuales se prueban los
componentes del sistema, la integración del sistema y, finalmente, el sistema con los datos
del usuario. El proceso es iterativo y se retroalimenta tanto de las últimas etapas como de
la primera parte del proceso.
Figura 25. El proceso de pruebas (Sommerville y Domínguez Torres, 2002).
62
Las etapas en el proceso de pruebas son:
1. Prueba de unidades. Se prueban los componentes individuales para asegurarse de que
operan correctamente. Cada uno se prueba de forma independiente, sin los otros componentes
del sistema.
2. Prueba de módulos. Un módulo es una colección de componentes dependientes, como una
clase de objetos, un tipo de datos abstracto o alguna colección de procedimientos y funciones.
Un módulo encapsula componentes relacionados, de tal forma que se pueden probar sin los
otros módulos del sistema.
3. Prueba de subsistemas. Esta fase comprende la colección de pruebas de los módulos que
integran el subsistema. Los problemas más comunes que surgen en los sistemas grandes de
software son el desacoplamiento de las interfaces. Por tanto, el proceso de prueba del
subsistema se concentra en detectar errores en los módulos de la interfaz por medio de
ejercicios rigurosos sobre estas interfaces.
4. Prueba del sistema. Los subsistemas se integran para constituir el sistema. Este proceso
comprende encontrar errores que son el resultado de interacciones no previstas entre los
subsistemas y su interfaz. También comprende validar que el sistema cumpla sus
requerimientos funcionales y no funcionales y probar las propiedades emergentes del sistema.
5. Pruebas de aceptación. Ésta es la etapa final en el proceso de pruebas antes de que se
acepte que el sistema se ponga en operación. Éste se prueba con los datos proporcionados por
el cliente más que con datos de prueba simulados. Debido a la diferencia existente entre los
datos reales y los de prueba, la prueba de aceptación revela errores y omisiones en la
definición de requerimientos del sistema. También revela donde los problemas de
requerimientos en los recursos del sistema no cumplen las necesidades del usuario o donde el
desempeño del sistema es inaceptable (Sommerville y Domínguez Torres, 2002).
63
Pruebas de defectos.
La meta de las pruebas de defectos es exponer los defectos latentes en un sistema de software
antes de entregar el sistema. Una prueba de defectos exitosa es una prueba que provoca que el
sistema se desempeñe incorrectamente y así exponer un defecto (Sommerville y Domínguez
Torres, 2002).
En la figura 26 se muestra un modelo general del proceso de prueba de defectos. Los casos de
prueba son especificaciones de las entradas a la prueba y de la salida esperada del sistema más
una declaración de lo que se prueba. Los datos de prueba son las entradas seleccionadas para
probar el sistema.
Figura 26. El proceso de pruebas de defectos (Sommerville y Domínguez Torres, 2002).
Pruebas realizadas al sistema y resultados
Se efectuaron diferentes casos de prueba a los diferentes subsistemas que conforman al
sistema completo, en cada uno de estos casos de prueba se introdujeron los datos
correspondientes para cada subsistema, y se procedió a comparar los resultados esperados con
los resultados arrojados, en base a estos resultados se verificó la funcionalidad del sistema.
64
En la tabla 4 se listan algunos de los casos de pruebas que se realizaron a los diferentes
subsistemas así como los resultados obtenidos.
Tabla 4. Tabla de pruebas realizadas al sistema.
Subsistema Descripción del caso
de prueba
Datos de
prueba
Resultados de
prueba Subsistema de
autentificación
Se realizaron pruebas de
seguridad, estas
consistieron en tratar de
burlar la autentificación
para las secciones
restringidas del sistema,
secciones a las que sólo el
administrador tiene acceso
mediante un usuario y una
contraseña. Además se
realizaron todas las
combinaciones posibles
con los datos de prueba
para validar el proceso de
autentificación.
Nombres de
usuario y
contraseñas
(correctas e
incorrectas)
Los resultados
de las pruebas
no mostraron
ningún defecto
Subsistema de
gestión de
material
bibliográfico
científico
Se ingresaron datos de
prueba hipotéticos
referentes a documentos
científicos y se procedió a
realizar todas las acciones
posibles tales como altas,
bajas, modificaciones y
consultas tratando de
verificar la estabilidad y
correcto funcionamiento
del sistema.
Información
referente a
documentos
científicos usando
el formulario de
captura de
material
bibliográfico
(figuras 24 y 25)
tratando de usar
la mayoría de las
etiquetas que
especifica el
estándar Dublín
Core para lograr
una óptima
descripción del
material
bibliográfico.
Los resultados
mostraron
algunos
problemas al
momento de
tratar de subir al
servidor
archivos que
excedían los
2MB de tamaño,
sin embargo,
este problema ha
sido ya resuelto
pudiendo subir
archivos de hasta
5MB, rango
bastante
accesible para un
documento
científico
promedio.
65
Subsistema de
generación de
metadatos
Una vez registrados en la
base de datos y
almacenados los
documentos en el
repositorio de material
bibliográfico del servidor,,
se procedió a generar
automáticamente los
metadatos (estandarizados
a Dublín Core)
descriptivos de cada
material científico
registrado utilizando
XML y a almacenarlos en
el repositorio de
metadatos locales para
ponerlos a disposición de
sistemas cosechadores
externos; tratando de
verificar su correcta
generación y
almacenamiento
Información
obtenida de la
base de datos
referente a
información
relevante de cada
documento
científico
registrado y
almacenado en el
servidor.
Los resultados
de las pruebas
no mostraron
ningún defecto
Subsistema de
cosecha de
metadatos
Utilizando protocolos de
servicios Web como el
SOAP se realizaron
pruebas simulando
cosechas de metadatos
desde nuestro sistema
hacia otros sistemas
proveedores de metadatos
y viceversa, tratando de
verificar la correcta acción
de las cosechas poniendo
especial atención en este
punto, dado que se trata
del objetivo primordial de
este proyecto.
Para realizar
cosechas de
metadatos en un
proveedor externo
de metadatos es
necesario hacer la
consulta con
dicho proveedor
utilizando un
nombre de
usuario conocido
por el consultor y
el proveedor para
que éste último
tenga la certeza
de que quien
solicita sus
metadatos es
precisamente un
ente conocido,
seguro y
autorizado.
Los resultados
mostraron
algunos defectos
al momento de
especificar la
dirección del
proveedor de
metadatos, sin
embargo se trató
de errores
mínimos de
codificación que
fueron resueltos
de manera
inmediata.
66
Subsistema de
búsquedas y
consultas de
material científico
Se realizaron pruebas
exhaustivas tratando de
verificar el correcto
funcionamiento de las
consultas de material
científico y tratando de
encontrar posibles errores
al realizarlas. Para ello se
utilizó la interfaz
búsquedas del sistema.
Se introdujo todo
tipo de
información en
los formularios de
búsqueda de la
interfaz de
consultas
buscando
cualquier posible
error al momento
de llevarlas a
cabo. Se ingresó
todo tipo de
criterios de
búsqueda.
Los resultados
mostraron
algunos defectos
originados a la
hora de hacer las
consultas SQL
en la base de
datos, los cuales
ya han sido
corregidos.
Discusión
Los resultados de esta investigación ponen de manifiesto el potencial y el fuerte impacto
positivo que tiene el Open Access en la comunidad científica al poner a disposición totalmente
libre, material científico de calidad reafirmando su filosofía de un acceso libre y sin
restricciones al conocimiento científico.
A su vez se evidencia también la importante influencia del protocolo OAI-PMH para lograr
los objetivos del Open Access.
Siguiendo la ruta verde que especifica la OAI (aparte de la ruta dorada) conjuntamente con la
utilización del protocolo OAI-PMH, hemos logrado contribuir con esta filosofía al desarrollar
un Repositorio Institucional capaz de albergar y garantizar la “vida” y permanencia de
material bibliográfico científico de calidad respaldado por investigadores reconocidos. Así
también, se ha logrado intercambiar exitosamente dicho material con otras instituciones
interesadas en cooperar con el Open Access; logrando de esta manera brindar una mayor
difusión al libre conocimiento.
67
En este capítulo se describió el procedimiento de implementación del esquema a través de un
sistema de entorno Web, también se especificaron las pruebas a las que éste fue sometido y
sus respectivos resultados.
Para cerrar esta investigación, enseguida se describen las conclusiones y resultados generales
del estudio, haciendo énfasis en el alcance de los objetivos planteados en el proyecto y la
propuesta del trabajo futuro.
68
CAPÍTULO 6. Conclusiones
El tema de los Repositorios Institucionales, aunque es un concepto relativamente reciente,
está marcando nuevas tendencias y adquiere cada vez mayor fuerza conforme al continuo
avance y desarrollo de Internet. Día a día, nuestras actividades cotidianas se involucran
cada vez más con la tecnología y el intercambio de información y recursos a través de
Internet se ha vuelto un factor clave, fundamental y crucial en numerosos sectores sociales.
En este trabajo se desarrolló e implementó un esquema de administración de Repositorios
Institucionales capaz de ofrecer, intercambiar y difundir material bibliográfico entre
diferentes repositorios en Internet utilizando la filosofía de contextos abiertos del protocolo
OAI-PMH.
El sistema desarrollado en este trabajo cumplió con los objetivos planteados inicialmente.
Se creó una interfaz amigable, intuitiva y relativamente fácil de usar para automatizar los
procedimientos de registro y almacenamiento de material bibliográfico de calidad en
formato digital. Así mismo, se desarrolló un módulo capaz de recolectar, intercambiar,
difundir y compartir material y recursos científicos con otras instituciones educativas y
científicas a través de Internet. Se diseñó también una interfaz de búsqueda para localizar y
consultar documentos bibliográficos de manera rápida y eficiente.
Los resultados manifiestan la importancia de la colaboración entre instituciones y
dependencias para compartir fuentes de información que incrementen el acervo
bibliográfico y así dar un soporte significativo a los investigadores que buscan referencias
bibliográficas de calidad para dar fundamento a sus proyectos.
69
Trabajo futuro
Con el propósito de continuar con la investigación en el futuro se hacen las siguientes
recomendaciones:
Sugerimos trasladar la operatividad de nuestro repositorio Green Access hacia un
repositorio Golden Acces, que incluya referencias de editoriales y bibliotecas digitales de
reconocido prestigio.
Se recomienda también mantener una convocatoria permanente para lograr acuerdos y
realizar convenios con otras organizaciones educativas y/o científicas interesadas en
participar con el movimiento de acceso abierto y enriquecer de esta manera el acervo
bibliográfico libre constantemente.
70
ANEXO
Información complementaria del sistema
En esta sección se incluye contenido complementario a la investigación realizada con el
objetivo de sustentar y enriquecer el trabajo realizado.
En la figura 27 se muestra la estructura en MySQL de la tabla de investigadores.
Figura 27. Estructura en MySQL de la tabla de investigadores.
La tabla de investigadores almacena información relativa a cada uno de los investigadores
de la Universidad de Colima, dicha información es empleada para conformar el catálogo
de investigadores que está disponible en la página Web de la Secretaría de Investigación
de la Universidad de Colima, misma que fue desarrollada en conjunto con el sistema
expuesto en esta investigación.
En la figura 28 se muestra la estructura en MySQL de la tabla de noticias y boletines
informativos.
71
Figura 28. Estructura en MySQL de la tabla de noticias y boletines informativos.
La tabla de noticias y boletines informativos contiene la información de noticias ubicada
en la parte derecha de la interfaz principal del sistema, dicha interfaz se puede apreciar en
la figura 18.
Interfaz de captura de investigadores.
En las figuras 29 y 30 se muestra la interfaz de captura de información relativa a
investigadores de la Universidad de Colima, en ella es posible capturar información tanto
personal como institucional. Es posible capturar información relevante de cada
investigador como por ejemplo sus trabajos, publicaciones, material de experimentación,
etc.
72
Figura 29. Interfaz de captura de investigadores 1/2.
73
Figura 30. Interfaz de captura de investigadores 2/2.
La interfaz de captura de información es un formulario donde se ingresa la información
relativa a investigadores de la Universidad de Colima, esta información se guardada en la
74
base de datos del sistema en la tabla de investigadores y es utilizada para conformar el
catálogo de investigadores en el sistema.
Interfaz de captura de noticias
En la figura 31 se muestra la interfaz de captura de noticias donde se ingresa la
información que será visualizada y accesible en la sección de noticias o boletines
informativos en la interfaz principal del sistema.
Figura 31. Interfaz de captura de noticias o boletines informativos.
La interfaz es simple, se trata de un formulario con tres campos para ser llenados, estos son:
Texto Introductorio: En este campo se escribe una breve introducción (100
caracteres) para la noticia descrita.
Enlace directo: En este campo se escribe la ruta o el enlace URL donde la noticia
completa puede ser consultada.
75
Fecha actual: Este campo no puede ser modificado por el administrador, se
actualiza automáticamente con la fecha actual del servidor y tiene como objetivo
registrar la fecha en que la noticia fue dada de alta.
76
Referencias
Alonso, F., Martínez, L., y Segovia, F. J. (2005). Introducción a la Ingeniería del Software - Modelos de desarrollo de programas. España: Delta publicaciones.
Arellano, M. C., Nogales, J., y Martín, B. (2009). La organización hipertextual del ordenamiento jurídico - Posibilidades de XML y estándares relacionados. Revista General de Información y Documentación, 182-189.
Ayllón Bonet, J. C. (2006). Metadatos y documentos XML/RDF para recuperación y organización de la información. Recuperado el 22 de abril de 2010, de http://metadatos-xml-rdf.awardspace.com/xml.html
Carpenter, L. (2003). OAI para principiantes - tutorial en línea del Open Archives Forum. Recuperado el 29 de noviembre de 2011, de http://travesia.mcu.es/portalnb/jspui/html/10421/1823/intro.htm
Castro, E. (2003). HTML for the World Wide Web (Fifth ed.). Estados Unidos: Peachpit Press. Cobo, A., Gómez, P., Pérez, D., y Rocha, R. (2005). PHP y MySQL- tecnologías para el desarrollo de
aplicaciones Web. España: Díaz de santos. Converse, T., Park, J., y Morgan, C. (2004). PHP5 and MySQL Bible. Estados Unidos: Wiley Publishing. Croxatto, H. L. (2005). Creando valor en la relación con sus clientes - cómo desarrollar todo el
potencial de una solución CRM y transformarlo en ventajas de negocio. Argentina: Editorial dunken.
CUL. (2010). Cornell Universtity Library. Recuperado el 20 de mayo del 2010, de http://arxiv.org/ Chawner, B. (2005). F/OSS in the Library World: An Exploration. Artículo presentado en el
International Conference on Software Engineering. Day, R. A. (2005). Cómo escribir y publicar trabajos científicos. (3 ed.). Washington, D.C.: OPS. DCMI. (2010). The Dublin Core Metadata Initiative. Recuperado el 7 de octubre del 2010
de http://dublincore.org/ Gilmore, W. J. (2008). Beginning PHP and MySQL: From Novice to Professional (Third ed.). Estados
Unidos: Apress. Hagemann, E. (2002). Budapest Open Access Initiative. Recuperado el 20 de mayo del 2010, de
http://www.soros.org/openaccess/index.shtml/ Hernández, S., Fernandez, C., y Baptista, L. (2003). Metodología de la investigación. México: McGraw-
Hill. IEEE. (2010). IEEE draft standard for learning object metadata. Learning Technology Standards
Committee. Recuperado el 8 de octubre del 2010, de http://ieeeltsc.org/ Keefer, A. (2007). Los Repositorios Digitales Universitarios y los Autores. Anales de documentación, 10,
205-214. López, C. (2000). Modelo para el Desarrollo de Bibliotecas Digitales Especializadas. Tesis de maestría,
Instituto Tecnológico Autónomo de México. Recuperado de http://www.bibliodgsca.unam.mx/tesis/tes7cllg/tes7cllg.htm
Martínez, J. Á., y Navarra, P. L. (2007). La interoperabilidad de la información. Barcelona: Editorial UOC.
Nikolov, N., y Stoehr, P. (2008). Harvesting Needed To Maintain Scientific Literature Online. Artículo presentado en el International Conference on Digital Libraries.
OAI. (2008). Archives Initiative, Standards for Web Content Interoperability. Recuperado el 22 de mayo del 2009, de http://www.openarchives.org
77
PLoS. (2010). Public Library of Science. Recuperado el 20 de mayo del 2010, de http://www.plos.org/about/letter.php/
Pressman, R. S., Ojeda Martín, R., Morales Jareño, I., y Virgilio Yagüe, G. (2002). Ingeniería del software: un enfoque práctico. (5 ed.). Madrid, España: Mc Graw-Hill
ROAR. (2011). Registy of Open Acces Repositories. Recuperado el 9 de Agosto de 2011, de
http://roar.eprints.org Saltivery, T. G., Vidal, J. L., y Cañas, J. J. (2005). Diseño de sistemas interactivos centrados en el usuario.
Barcelona: Editorial UOC. Santillan Aldana, J. (2009). El movimiento del acceso abierto y el mundo bibliotecario desde la
experiencia del proyecto E-LIS. AIBDA, XXX. Sommerville, I., y Domínguez Torres, J. (2002). Ingeniería de Software. (6 ed.). México: Pearson
Educación de México. SPARC. (2010). Scholarly Publishing & Academic Resources Coalition. Recuperado el 20 de mayo de
2010, de http://www.arl.org/sparc/ Swan, A., y Brown, S. (2005). Access self archiving: an author study. Recuperado el 30 marzo 2007,
de://eprints.ecs.soton.ac.uk/10999/ Ullman, L. (2006). MySQL (2° ed.). Estados Unidos: Peachpit Press. Velez, S. (2001). Apuntes de metodología de la investigación. Medellín. Vives, J., Alberch, R., Alvárez, J., Cuevas, A., Labastida, I., Munilla, G., . . . Solanilla, L. (2009).
Digitalización del patrimonio: archivos, bibliotecas y museos en la red. Barcelona: editorial UOC.
Voutssás Márquez, J. (2005). Bibliotecas y publicaciones digitales. México: UNAM, Centro Universitario de Investigaciones Bibliotecológicas.
