RE: Mi perfil y explicaciones sobre "Un nuevo impulso al proyectoAyuda"
On Sun, 16 Sep 2001, Ibon Urretavizcaya wrote:
>
> [...]
> Bueno, tampoco hay que tenerlo todo atado para empezar el proceso. Este
> [...]
> Si esperamos a tener un interfaz intuitivo con todo tipo de opcion y
> [...]
> documentalistas empiecen su trabajo, pues me parece que no empezaremos
> nunca.
Nunca se ha dicho eso, pero por no tener no tenemos ni siquiera un diseño
claro de lo que será todo esto.
> [...]
> 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...#
No me parece buena idea guardar datos así. Hay que montar un sistema que
favorezca la homogenización en el uso de claves y que impida el uso de
sinónimos o distintas formas gramaticales de una palabra. Para eso los
datos deberían estar en BD. Ya le estoy dando vuelas al tema y no me
parece una cosa complicada de conseguir.
>
> >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...
Eso también lo he dicho yo varias veces. Una cosas es hacer pruebas y otra
ponerse a documentar invirtiendo mucho trabajo en algo, para luego condicionar
todo el diseño postertior para aprovechar esa gran cantidad de trabajo
que se hizo.
> [...]
> 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.
Simplemente afirmo que trabajar en local es una opción válida.
No descarto que se pueda hacer de otra forma. Para mi los aspectos
internacionales no tienen nada que ver con este tema. Existe el
correo electrónico y los grupos de trabajo en distintos idiomas
no creo que tengan que coordinarse entre si. Solo intercambiar
información ocasionalmente.
>
> 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.
Para eso no hace falta trabajar online.
Se asignan tareas y cuando alguien termine la suya coje lo
que esté disponible. Si alguien se duerme se le pregunta si
hay algún problema y en caso de que no de señales de vida se
reasigna ese trabajo a otra persona. La cuestión es que los
que pueden trabajar no paren de hacerlo y si una cosa se termina
antes que otra que mas da.
> [...]
> >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.
El único recurso que estamos usando es una lista de correos que ni siquiera
es del proyecto. La existencia de determinados servidores no es suficiente.
tenemos que tenerlo a nuestra disposición y a alguien dispuesto a programar
ese interfaz de entrada de datos que no tenemos siquiera espozado.
> > [...]
> 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.
Claro que se puede hacer así pero son cosas independientes. No me parece
necesario trabajar on-line para eso. No me parece no mejor ni pero
trabajar on-line para esto.
> [...]
> 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.
Una BD relacional permitirá una flexibilidad de busqueda que dificilmente
se puede conseguir con Scripts. Estamos hablando de relaciones de
sinonimia, de homogenización de claves, de jerarquías entre claves, etc..
Si los datos los guardas en un fichero y el día de mañana tienes que
modificar, eliminar o añadir un campo para mejorar el diseño tendrás
que reprogramar todos los scripts. Las BD ofrecen una independencia de
la estructura de los datos muy necesaria. Me parece bien usar scripts
tipo perl o awk cuando solo hay dos o tres tablas y las relaciones entre
ellas son triviales. Yo tengo claro que eso no va a ser así.
> [...]
> 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?
Cada idioma tendrá un grupo de trabajo distinto. No necesitamos hacer
suposiciones tan arriesgadas. Si nosotros usamos "impresora" no
podemos estar seguros de que se va a elegir "printer" o "printing"
o "print" lo mismo que ellos no pueden saber si vamos a elegir
"impresora", "imprimir", o "impresión". Esto por hablar de las
variaciones gramaticales en las claves. Para "sonido" tenemos tambien
"audio". Las palabras no tiene una correspondencia de una a una entre
distintos idiomas y lo que para nosotros representa un único concepto
en otro idioma tiene sus matices y se usarán palabras distintas para
cada matiz. Cada documento en un idioma distinto serán documentos
distintos y los equipos que lo clasifiquen serán distintos. No hay
necesidad de poner de acuerdo a todo el planeta.
> [...]
> 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
> [...]
> debe aparecer al final, o por lo menos si selecciono la casilla de "buscar
> en todos los idiomas".
Imagina que estas buscando CPU. Ese termino puede aparecer en documentos
equivalentes de varios idiomas pero quizás en algunos documentos españoles
se use CPU, mientras que en otros se usará procesador, y en otro UCP.
> [...]
> 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.
No. Seguramente el documentalista podrá basarse en ese trabajo previo
pero continuará siendo necesaria la labor del documentalista.
> [...]
> >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.
Tienes toda la razón. Ha sido un patinazo mío. Sería una única tabla con
un campo para cada idioma. Pero esto se puede hacer para títulos de
documentos porque existirá una correspondencia 1 a 1 muy clara. Con claves
no se puede hacer.
> [...]
> 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
Eso es redundante. Como ya dije los campos alfabéticos se pueden indexar
de forma eficaz.
Equivocado o no, yo tengo muy claro los siguientes puntos:
1) Empezar a documentar. Si pero solo unos pocos documentos
en español y en plan de prueba.
2) Interfaz para entrada de datos de documentalistas:
Muy necesario pero puede hacerse on-line, o en local.
3) La traducción de un documento debe tratarse como un documento
distinto. (distintas claves, distinto equipo de documentalistas,
etc). Sería bueno establecer una relación entre los documentos
traducidos.
4) Script. No garantiza la independencia de la estructura de datos
que es algo que puede sufrir importantes variaciones. No es adecuado
para hacer tratamiento de gran cantidad entidades o tablas con
relaciones complejas.
5) Variable autonumérica para la tabla de claves es una redundancia
innecesaria y resultaría bastante molesta.
Un saludo
Antonio Castro
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/\ /\ Ciberdroide Informática (Tienda de Linux)
\\W// <<< http://www.ciberdroide.com >>>
_|0 0|_
+-oOOO--(___o___)--OOOo----------------------------------------------------+
| . . . . U U . . . . Antonio Castro Snurmacher acastro@ciberdroide.com |
| . . . . . . . . . . |
+()()()----------()()()----------------------------------------------------+
| *** 1.700 sitios clasificados por temas sobre Linux en ***Donde_Linux*** |
| <<< http://www.ciberdroide.com/misc/donde/dondelinux.html >>> |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
Reply to: