Por: James Richvalsky y David Watkins
Traduccion: Andrea Botero
Se ha preguntado usted alguna vez, lo que es una biblioteca digital o cómo haría para crear su propia biblioteca digital? Al Describir el plan y el proceso de aplicación que nosotros seguimos al crear nuestra propia biblioteca digital, queremos ofrecerle al lector una definición simple de lo esto significa, y presentar algunos problemas claves involucrados en su creación.
El presente artículo esta enfocado hacia una aplicación basada en UNIX, sinembargo hemos incluido algunos aspectos importantes para bibliotecas basadas en sistemas PC.
El proposito de estas bibliotecas es mantener una locación central para el acceso a información sobre un tema en particular. La última cosa que un usuario quiere que pase, cuando busca información sobre gráficos, es encontrar información sobre sistemas operativos. Una biblioteca digital debe guardar los temas separados, de otra manera sería totalmente inútil. también es de gran importancia el hecho de tener una interface al usuario que sea fácil de usar.
En este sitio (http://springfield.tcnj.edu:8000/~compsci/index2.html) actualmente se recaudan -en línea- los abstracts del material laboratorio, a la vez que se proporciona un sistema de busqueda por medio de palabras claves para consultar los respectivos materiales.
Actualmente hay dos secciones separadas en nuestra biblioteca digital: Las reseñas de compañeros (peers) y las reseñas de editor. La primera sección consiste en material de laboratorio en línea referido por un grupo de iguales, por otro lado la sección de reseñas editoriales, también contiene laboratorios en línea, pero estos han sido reseñados por el editor del sitio en cuestión.
En el grupo de trabajo SIGCSE en Laboratorios Cerrados, se discutio inicialmente la necesidad de construir esta colección en el verano de 1995 [1]. Desde entonces el trabajo en esta área ha continuado; problemas específicos que se han tratado, incluyen el desarrollo de pautas para las guias de sumisión [4] y el incremento en la accesibilidad de la libreria [5].
Uno de los primeros problemas de diseño que se presentan, es el de crear una lista de requerimientos de alto nivel. En esta lista se debe incluir: el tipo de información que contendrá la biblioteca, cómo se generará esta , a qué tipo de público se quiere acceder y cómo se manejaran los datos.
En el caso de nuestro proyecto, el objetivo era crear una colección para material de laboratorios de informática. En esta colección profesores e instructores, a lo largo del mundo, podrian visitar el sitio e incluir la información sobre los laboratorios que usan en sus aulas. De esta sola descripción se deducen varios puntos: la información debe recogerse a través de sumisiones en línea; el público intencional es educadores de informática a nivel mundial; y por último, los datos deben ser accesibles por medio de la red. Todos estos aspectos deben ser considerados en el momento del desarrollo. Por esto es importante contar con un plan claro, el cual debe definirse antes de empezar el diseño y la implementación de la biblioteca.
Otro aspecto importante que necesita ser evaluado antes de desarrollar el sitio, hace referencia al almacenamiento y locación de la biblioteca digital. El servidor de red elegido, debe contar con acceso a Internet, espacio suficiente en la unidad de disco duro, y la habilidad manejar la carga de acceso esperada.
Preferiblemente, el computador seleccionado debe tener una linea T1 o u otra mejor conexión a Internet. Esto le permitirá un rápido acceso a los usuarios. Si se usa un PC , este debe por lo menos contar con un procesador Pentium de 100MHz.. Velocidades similares tambien se recomiendan para las máquinas basadas en UNIX. Un amplio espacio en la unidad de disco para los materiales de la biblioteca es tambien un aspecto clave, nosotros recomendamos disponer de por lo menos100MB de espacio libre en el disco. Esto garantiza el espacio suficiente para la expansión de la biblioteca.
Una vez la arquitectura ha sido escogida, se debe seleccionar un servidor de red. Es común en usuarios que han optado por usar PC, correr Windows NT . Dos de los servidores de red más populares para este sistema operativo son: Internet Information Server de Microsoft, y Enterprise Server de Netscape. Si se ha escogido UNIX , uno de los numerosos servidores de red que pueden utilizarse es NCSA HTTPd Web Server [7], (nuestra eleccón) que puede obtenerse en la misma red.
La desición sobre que hardware y software se empleará, es de gran importancia. Muchas personas consideran que el sistema UNIX es más fiable que los basados en PC. Sobretodo porque el software para las máquinas de UNIX ha estado en uso durante muchos años (ha sido sometido a más pruebas), mientras que el software para PC es relativamente nuevo. Nosotros optamos por una máquina de UNIX conectada a una línea T1, debido a su fiabilidad y velocidad. Actualmente estamos usando una estación SUN Ultra que corre SunOS 5.6. También se ha experimentado con una estacián SUN Sparc y SunOS 5.5.1 corriente.
La segunda decisión ha realizar es la referente al almacenamiento de los archivos que comprenden la biblioteca digital. En este momento hay varios opciones disponibles. Dos posibles métodos son: usar un base datos o crear un directorio y estructura de archivo especial .
Hay muchas opciones bases de datos para escoger, algunos ejemplos incluyen Oracle, MSQL, y Microsoft Access. Si usted utiliza un PC, Access probablemente será la mejor elección, debido a su compatibilidad con NT. Oracle es una buena opción de base de datos para UNIX. ya que es muy fiable y bastante flexible.
Sin embargo al escoger una base de datos se presentan algunos inconvenientes, el problema principal involucra su falta de flexibilidad. Basicamente porque después de crear una base de datos, si se necesita agregar un nuevo campo, la base debe ser creada nuevamente en su totalidad. Incluso en varios sistemas, el traslado de datos de una base a otra puede resultar difícil y consumir gran cantidad de tiempo.
En lugar de usar una base datos, nosotros escogimos crear nuestro propio directorio y estructura de archivos. Para cada laboratorio creamos un archivo abstracto que incluyé información pertiente al laboratorio como: el nombre del autor, título del laboratorio, tema del laboratorio, y otra información relevante. Tambien creamos dinámicamente un directorio cuyo nombre está compuesto por el nombre del autor y el título del laboratorio respectivo. Esto permite la creación de un nombre único para cada directorio, este factor se asegura, empleando el siguiente fragmento escrito en PERL
# retrieve information
which was passed into the CGI script
$authors = $in{'authors'};
$title = $in{'title'};
# convert spaces to underscores
using string manipulation function
$authors =~ s/ /\_/g;
$title =~ s/ /\_/g;
# combine the author
and title fields, separated by a '-' to create a directory name
$dir = $authors.``-''.$title;
# create directory with
correct file permissions
mkdir(``$dir'', 777);
De esta manera todos los archivos asociados con cada laboratorio se guardan en el directorio apropiado. Este diseño es mucho más flexible que una base de datos, ya que, por ejemplo, nuevos campos pueden agregarse cambiando solamente el script de CGI.
En el siguiente ejemplo, se presentamos la estructura del directorio que creamos para este caso. Notese que el nombre del directorio que contiene el laboratorio consiste de 2 items: el nombre del autor y el título del laboratorio. Incluido en este directorio se encuentra un archivo que contiene el abstract del laboratorio y otros archivos asociados. En este ejemplo, un documento de Microsoft Word y una imagen estan incluidos.
./labs/official_labs/David_Watkins-Implementation_of_a_Digital_Library/lab./labs/official_labs/David_Watkins-Implementation_of_a_Digital_Library/paper.doc
./labs/official_labs/David_Watkins-Implementation_of_a_Digital_Library/image.jpg
Para manejar este problema, decidimos crear secciones separadas de baja y alta resolución en nuestro website. La sección de baja-resolución contiene paginas web HTML 2.0 sin gráficos ni Java, JavaScript, o marcos. Las páginas cargan bastante rápido, pueden utilizarse desde cualquier conexion, e incluso verse en navegadores de solo texto como Lince.Asi mismo las páginas de alta-resolución contienen marcos, gráficos, y JavaScript. Estas páginas son visualmente más interesantes (y discutiblemente más funcionales); aunque el volumen de información es igual que en la sección de baja resolución.
Para nuestro caso, nuestro servidor se definio para que corriera la cuenta sobre la cual se desarrolló el sitio, como la identificación del usuario. Esta accion se ejemplifica con este segmento de código de httpd.conf del NCSA el HTTPd del archivo Servidor [7].
#
User/Group: The name (or #number) of the user/group to run HTTPd as.
User
compsci
Group
dept
Otra opción disponible es la de asegurar ciertas áreas
del website. Tanto los revidores Apache como NCSA para UNIX
poseen esta caracteristíca. En un archivo de configuración
llamado `` el htaccess'', pueden definirse los usuarios a los que se
permite acceder a ciertas áreas de el website. Cuando un usuario
que esta navegando, intenta acceder en un webpage a un área restringida,
un dialogo pop-up pregunta por login del usuario y contraseña.
Sólo
un login y una contraseña validos, permiten al
usuario acceder a esa sección particular del website. En un
servidor NCSA , esto puede lograrse agregando un archivo (.htaccess) en
el directorio que se quiere asegurar. El archivo de .htaccess debe contener
las siguientes líneas.
AuthUserFile /home/login_name/.password/.htpasswd
AuthGroupFile /home/login_name/.password/.htgroup
AuthName SIGCSE Administration
Authorization
AuthType Basic
<Limit GET>
re group name_of_group
<Limit>
Un script CGI se usa para tomar la información de la red , manipularla, y obtener un resultado. Estos scripts pueden escribirse en varios lenguajes. Los dos lenguajes de mayor popularidad para está labor son C y PERL. Nosotros escogimos usar PERL por varias razones; PERL tiene una sintaxis que es muy similar a C y posee varias manipulaciones de cadena que funcionan de una manera muy conveniente. Adicionalmente ofrece la ventaja de no requerir compilación (desde que se interpreta) y es un lenguaje desarrollado "puramente" para scripts. Se encuentran librerias disponibles para manejar gran parte del sobrecargo de pasar datos de el navegador a el script. La libreria que nosotros usamos (cgi-lib.pl) para capturar la información transmitida a nuestra script CGI se encuentra disponible en sin ningún costo en la red. A continuación, un ejemplo de cómo usamos la libreria cgi-lib.pl
# tell PERL you will be using functions from cgi-lib.pl
require 'cgi-lib.pl';
#
call the function from the above library that parses and returns the data
that was
#
passed into the script, the function returns the data in an array with
the name of 'in'
&ReadParse(@in);
# retrieve the data from the author field and save it in a variable
$author = $in{'author'};
Para que un script sea ejecutado, el servidor de red tiene que saber que el script es un script de CGI.. Esto puede hacerse de dos maneras. Primero, puede decirle al navegador que todos los archivos que acaban con una extensión en particular son los scripts CGI. Por ejemplo, un servidor puede definirse para que todas los scripts CGI acaben con la extensión `` .cgi ''. Cuando el servidor intenta cargar un archivo con esta extensión, pensará que el archivo es un script e intentará ejecutarlo. Si un script se salvára con cualquier otra extensián, el servidor simplemente devolverá el contenido del script como texto puro y no lo ejecutará. La ventaja al usar este metodo radica en que los scripts pueden salvarse en cualquier locación.
El segundo método en cambio, no da esta libertad. En este caso todo el servidor de red debe conocer los directorios que contienen los scripts. Cuando el servidor intenta acceder cualquier archivo dentro de ese directorio, sabe que son script CGI, e intentará ejecutarlos. en este caso cualquier script que no este grabado en ese directorio se procesará como un archivo del texto normal. El nombre común que se le da a estos directorios de CGI es ``cgi-bin.''. Para el servido NCSA , un "cgi-bin" puede definirse agregando la siguiente linea en el srm.conf file:
ScriptAlias /~username/cgi-bin/ /home/.../username/www/cgi-bin/
Esta línea le dice el servidor de red que los scripts CGI se encuentran en el ``el www/cgi-bin'' en el directorio de la cuenta del ``username''. La ventaja al usar este método, es que mantiene los scripts siempre en una misma locación central. Lo que permite tambien una mayor flexibilidad para el administrador a la hora de determinar que usuarios tienen acceso a los scripts. Si el administrador no quiere que alguien tenga este privilegio, sencillamente no le adjudica un directorio cgi-bin.
El siguient segmento del código muestra cómo puede verificarse la versión del navegador usando JavaScript
>script language=``JavaScript''>
bname = navigator.appName;
bvers = parseInt(navigator.appVersion);
if (bname == ``Netscape''
&& bvers >=3)
# insert function
which you want to call when the client browser is Netscape
# version 3 or
greater
}
</script>
Otro aspecto importante, es el de asegurar la calidad de los datos que contiene la biblioteca digital. Si una biblioteca digital acepta todo las sumisiones que se le presentan, puede llegar a contener mucha información probablemente inútil. En nuestra biblioteca este problema se manejo contando con reseñas hechas por " iguales" o "editores", que dan una idea sobre la informacion recientemente publicada.
Finalmente, uno de los aspectos más relevantes es el continuo cambio tecnológico. La red es aun muy joven, los contínuos adelantos permiten implementar cada vez, desarrollos más sencillos. Por ello es importante mantener al ritmo de todas las normas y estandares que se estan desarrollando para la red. (estos adelantos son investigados, entre otros por consorcios como el World WideWeb [8]). Un ejemplo de recientes normas y estandare es el Dublin Core [2], un set de 15 elementos de metadata que facilitan el descubrimiento de recursos electronícos. Metadata simplemente es `` datos sobre los datos'' [3], en otras palabras una metodología e idioma utilizada para describir recursos de aprendizaje en línea, que facilitarán búsquedas más eficaces.
Los 15 elementos del Dublin Core incluyen: Título, Asunto, Descripción, Fuente, Idioma, Relación, Fondos, Creador, Publicador, Contribuyente, Derechos, Fecha, Tipo, Formato, e Identificador. Estas etiquetas son básicamente código HTML que se coloca dentro de la primera sección de un documento de HTML. Un ejemplo de dos de las etiquetas se muestra acontinuación:
<META name=``DC.creator''
content=``John Doe''>
<META name=``DC.subject''
content=``Digital
El `` DC'' indica que las meta-etiquetas son parte del set Dublin Core de elementos. La primera etiqueta indica el creador del documento, en este caso la John Doe. La segunda etiqueta se refiere asunto del documento que en nuestro ejemplo es `` las Bibliotecas Digitales''. Todos los otros elementos en el set siguen el mismo modelo. Por ejemplo, si se fuera a crear una etiqueta que indique el título del documento, su nombre sería `` DC.title ''. El título del documento se coloca entonces en el campo indicado como content
Tenga en cuenta que, siguiendo el ritmo a las últimas normas y estandares, se puede lograr una biblioteca digital de gran utilidad para muchos visitantes.
1 L. Cassel, H. Taylor, chairs. SIGCSE Working Group on Closed
Labs NECC, Baltimore, Maryland, June 1995. Unpublished manuscript.
2 Dublin Core, http://purl.oclc.org/metadata/dublin_core/,
visited April 15, 1998.
3 IMS Meta-data, http://www.imsproject.org/metadata/,
visited April 15, 1998.
4 D. Joyce, D. Knox (joint chairs), J. Gerhardt-Powals, E. Koffman,
W. Kreuzer, C. Laxer, K. Loose, E. Sutinen, A. Whitehurst ``DevelopingLaboratories
for the SIGCSE Computing Laboratory Repository: Guidelines, Recommendations,
and Sample Labs Report of the Working Group on Designing Laboratory Materials
for Computing Courses,'' ACM ITiCSE 97, Uppsala, Sweden, June 1997, SIGCSE
Special Issue 1997, pp. 1-12.
5 D. Knox, ``Enhancing Accessibility of Lab Materials,'' SIGCSE
Bulletin, Vol. 29, No. 4, December 1997, pp. 20-21.
6 D. Knox, ``SIGCSE Computing Laboratory Repository, http://springfield.tcnj.edu:8000/~compsci/index2.html,
visited April 15, 1998.
7 NCSA HTTPd Web Server, http://hoohoo.ncsa.uiuc.edu/docs/Overview.html,
visited April 15, 1998.
8 World Wide Web Consortium, http://www.w3.org/, visited April
15, 1998.
CopyRight 1998 James Richvalsky
James Richvalsky y David Watkins son estudiantes en la Universidad
de New Jersey
Contacto:
richvals@barney.tcnj.edu
y watkins@barney.tcnj.edu
Ultima Modificación:
Localización: www.acm.org/crossroads/espanol/xrds5-2/diglib.html