RE: Mi perfil y explicaciones sobre "Un nuevo impulso al proyectoAyuda"
>On Sat, 15 Sep 2001, Ibon Urretavizcaya wrote:
>
>> -Los documentalistas pueden empezar a trabajar no nos necesitan para
>> nada. Su funcion es "sacar" palabras de un texto. (y no quiero que lleve
a
>> malentendido no quiero dar a entender que sea un trabajo ni sencillo ni
>> rapido... todo lo contrario es el alma del proyecto)
>
>Yo he cuestionado eso varias veces. Creo que lo que ocurre es que hay
>cierta impaciencia por obtener los primeros resultados tangibles.
Bueno, tampoco hay que tenerlo todo atado para empezar el proceso. Este
proyecto es muy complicado porque es un proyecto que nunca se ha hecho antes
y no tenemos referencias en las que basarnos.
Si esperamos a tener un interfaz intuitivo con todo tipo de opcion y
subopciones con todas las palabras que a cualquier documentalista se le
puedan ocurrir perfectamente clasificada y explicadas, antes de que los
documentalistas empiecen su trabajo, pues me parece que no empezaremos
nunca.
El proceso de documentacion y sobre todo el de enseñanza a los nuevos
documentalistas va a ser un proceso muy largo y lento. Y me quedaría
asombrado si en los proximos 3 meses alcanzamos una media de 3 documentos
con su abstract correspondiente por semana.
Estamos hablando de 36 documentos en 3 meses que ojala sean más, a
unas 4 palabras por documento son 144 palabras que nos van a dar la guia de
como montar la relacion entre ellas como organizarlas y objetivarlas.
Incluso habra un proceso de discusion de palabras buscando sinonimos y
demás. Tendremos que discutir la idoineidad de ciertas palabras y habrá una
tira y afloja entre los documentalistas y los desarrolladores.
>Los documenlistas quizás no necesiten a los desarrolladores para hacer
>su trabajo pero entonces que se supone que vamos a hacer los
>desarrolladores. Vamos a improvisar sobre la marcha toda una aplicación
>en función de los datos que nos lleguen a nuestras manos ?
Yo haria algo muy sencillo del plan un php que guarde en un archivo de texto
en un formato tipo:
Nombre_Documento#palabra1#palabra2#palabra3#etc...#
De tal manera que con un script sencillo se puede meter en diferentes tablas
o bases de datos sin tener que teclear cada vez que queramos hacer una
prueba. Con esto conseguimos libertad de movimiento y cuando sepamos de
verdad que es lo que queremos hacer entonces hacemos una base de datos
perfecta, con un interfaz muy comoda y con un sistema de busqueda
alucinante...
Pero creeme necesitamos saber con que tipos de datos vamos a trabajar antes
de empezar a desarrollar la aplicacion en si.
Luego tendremos en cuenta donde esta y con que formato, porque lo vital es:
yo tengo duda (palabra) ---> el programa me aconseja que documento mirar (el
titulo del documento)
Luego decirle donde lo puede encontrar y demas son accesorios muy
interesantes, pero lo primero es lo primero ¿que estoy buscando?
>Los errores de diseño de una aplicación son nefastos cuando ocurren en
>las fases iniciales del diseño. Pretender supeditar el diseño a lo que
>se nos vaya ocurriendo sobre la marcha me parece un error. Los
>documentalistas al igual que los desarrolladores tendrán una una visión
>parcial del tema.
Por eso mismo habría que hacer algo temporal hasta que nos hagamos una idea
de lo que tenemos entre manos. Lo cual nos da carta blanca para experimentar
y comparar diferentes opciones... y cuando tengamos algo decente lo
pondremos en marcha.. y seguiremos haciendo mas pruebas... etc...
>> 5º) En mi opinion creo que el mejor metodo de colaboración libre sin
>> control por alguien (cuello de botella) es la colaboración-web (php o
>> similares). Y ese debe ser nuetro objetivo final para la colaboracion de
los
>
>No lo tengo muy claro. Yo he trabajado en algún proyecto en el que todos
>trabajabamos en local y los cueyos de botella no estaban en los
>coordinadores sino en los restrasos de entrega de trabajos.
Pero yo creo que este proyecto tiene un caracter internacional y basarnos en
un sistema local no lo veo... por lo menos en el tema de colaboración, en la
consulta puede ser una opcion, pero la colaboración debería estar
centralizada.
Un ejemplo yo me apunto al cursillo de documentalista y marco que voy a
encargarme de analizar el documento X, queda anotado en la web la fecha en
la que me hago cargo, si en un plazo de "y" tiempo no doy señales de vida y
hay alguien interesado en el mismo documento se pueden poner en contacto
para compartir el trabajo... o para sustituirme, cuando el trabajo esta
hecho se sube al servidor rellenando un formualrio... despues habra que
corregirlo o darle el visto bueno, pero ya tenemos una version alfa del
documento. Sin que haya un administrador dandome permiso ni reprimendas
porque no he terminado el trabajo, ni nada de nada.
Y recalco que en un "bonito" futuro yo podre ser un coreano que no sepa ni
castellano, ni ingles y pueda colaborar en el proyecto documentando la
version coreana del documento "X" y de manera automatica todas las versiones
conocidas de ese documento.
>De todas formas tendríamos que usar un servidor y como no tengo constancia
>de que podamos usar ninguno para eso, prefiero no contar demasiado con
ello.
La espiral no cuenta con servidor propio ¿?, sino se podria trabajar con
sourceforge ¿no? necesitamos php y base de datos y creo que en sourceforge
tenemos eso.
>> Lo que quiero decir es que la eleccion de la base de datos es
>> importante, pero no es necesario obligar a todo usuario linux a
instalarse
>> una base datos para ver la ayuda, con un script se puede sacar la
>> informacion a archivos de texto (como creo que se hace para los listados
de
>> paquetes que utiliza el apt ¿no?)
>
>La potencian de un script no es comparable a la de una BD. Hay gente
>que ni siquiera instalará los paquetes de documentación porque consumen
>espacio. Todo consume espacio y una BD no representa algo prohibitivo.
>Yo lo veo muy asumible. El proyecto ayuda debe dar servicio en local
>para tender a las necesidades de los que empiezan y no han conseguido
>nada más que una triste consola y desean poder configurar cosas muy
>básicas como ratón, teclado, Xwindows, moden, rdsi, etc... Para los que
>tengan problemas de espacio y no tengan problemas de configuración básica
>ni de conexión a internet se puede ofrecer en algún servidor una versión
>de 'Ayuda on line'.
Pero el concepto es que se diversifique, cada uno utilizara la version
cliente que mejor se le adapte. Y el servidor que se encarga de las
colaboraciones, deberia ser el punto de actualización para que los clientes
tengan la información más al día posible.
En cuanto que el script no es tan potente como la base de datos, estamos
deacuerdo, pero para hacer una busqueda en mi casita una vez a la semana no
veo problemas, ahora la version online con 100 busquedas en una hora si que
necesita sin excusas la base de datos.
>> Aprovecho estas lineas para comentaros algo que creo se nos esta pasando
por
>> alto. La documentacion sobre la que vamos a trabajar esta en en el 99% de
>> los casos traducida desde el ingles asi que utilizar el titulo en ingles
o
>> similar como clave no es ninguna tonteria y más si tenemos en cuenta que
una
>> vez catalogado el documento en español esta catalogado en todos los
idiomas
>> en los que el documento este disponible, solo haria falta traducir las
>> claves-estructuras al resto de idiomas. Por eso la primera clave
importante
>> es ese unico documento que esta en diferentes idiomas, en diferentes urls
y
>> en diferentes formatos.
>
>Las claves de busqueda son distintas (distinto idioma)
>La descripción y la ficha entera es distinta. De todas formas hemos
>estado hablando siempre de un documento <---> un ficchero pero hay
>documentos como por ejemplo algunos html que están repartidos en varios
>ficheros.
>
>Para mi un documento en ingles y su traducción son simplemente documentos
>distintos.
No estoy deacuerdo. Si en la version española de "Imprimir-COMO" aparece
"impresora" como clave, es una tonteria dudar por un momento que en la
version inglesa del documento no aparezca "printer". ¿de acuerdo?
Yo lo veo asi, existe un "ente" que es el contenido del documento que es lo
que "resumimos" en sus palabras claves (en sus "significados" que plasmamos
en sus respectivas traducciones a los diferentes idiomas). Ese documento
puede estar escrito en chino y no tener traducción al español, pero si la
palabra que yo busco (su respectiva en chino) aparece en ese documento: ese
es un buen resultado para mi busqueda igual no debe aparecer el primero
porque no hay version española que se supone es la que más me interesa, pero
debe aparecer al final, o por lo menos si selecciono la casilla de "buscar
en todos los idiomas".
El documento es un unico elemento (DOC), al que se le asocian el
"significado" de unas palabras clave (ABST).
DOC0001 ABST034 ABST124 ABST067 ABST912 ABST024
Printing-Howto printer driver ....
.... ....
Imprimir-Como impresora driver .... ....
....
etc...
De tal manera que extraido los abstract de un documento en un idioma
concreto lo tenemos clasificado en todos los idiomas, porque al fin y al
cabo es el mismo documento.
Solo hace falta mantener al dia las traducciones de los abstracts a los
diferentes idiomas, para que todo funcione perfectamente.
Luego ya nos encargaremos de decir donde encontrar el DOC0001 en el idioma
que digamos, en el formato que nos interese, etc... pero esta es otra
historia, lo principal es lo anterior.
>Como mucho se puede establecer una relación especial entre ellos. Las
>relaciones de este tipo se puede implementar con tablas que contendrían
>claves de documentos en un idioma y claves correspondientes en otro idioma.
>
>Se puede elegir el idioma ingles como pivote. Es decir para localizar
>la versión francesa de un documento español habría que acudir a una tabla
>esp2ingl y luego a una tabla ingl2franc.
Pero la tabla esp2ingl y la ingl2esp no es la misma, por lo menos el
contenido si debería ser el mismo.
Yo creo que ir creando una variable autonumerica que se asocie a cada nueva
palabra clave (por supuesto solo realizable por el grupo reducido de
coordinadores) es la mejor opcion de esta manera habria como una tabla para
cada idioma y no es obligatorio al crear la variable definir su traduccion
inglesa (que podemos no conocer) ademas, ese numero se puede clasificar como
queramos para despues asignar relaciones entre ellas o reclasificarla sin
problemas.
>Lo más normal es que un usuario trabaje sobre un solo idioma o como
>mucho ingles mas otro idioma porque la documentación inglesa es más
>completa.
Estoy deacuerdo, pero eso que lo elija el usuario al hacer la busqueda. En
la busqueda normal se restringe al idioma que este usando en ese momento,
puede que con un pequeño contador enumerando el numero de coincidencias de
esa misma busqueda en otros idiomas. Pero en la busqueda avanzada que el
usuario elija lo que le interese. El diseño tiene que estar preparado para
todos los idiomas, incluidos los caracteres y charsets del japonés, chino,
coreano, etc...
Saludos.
Ibon.
Reply to: