Re: [gnome-hispano] Redefiniendo el paradigma de bÃsqueda y gestiÃn de informaciÃn en Nautilus

[Domingo Gonzalez <gonav ono com>]

El Mon, 20 Jul 2009 18:35:04 +0200
Alvaro del Castillo <acs barrapunto com> escribiÃ:

> Hola!
>
> El lun, 20-07-2009 a las 17:53 +0200, Domingo Gonzalez escribiÃ:
> > Hola,
> >
> > Debajo de este nombre tan espectacular subyace una idea tonta que se me ha ocurrido a raÃz de intentar 
> > reorganizar y actualizar toda la informaciÃn del disco. Seguro que a estas alturas esto està ya planteado 
> > y/o resuelto, pero no he encontrado demasiadas referencias al respecto. Bien, la problemÃtica a resolver 
> > serÃa la siguiente:
> >
> > - Cada x tiempo, tenemos la costumbre de reorganizar nuestros ficheros, bien porque no nos gusta la 
> > estructura anterior, bien porque lo que antes era un cajÃn desastre con cien ficheros, ahora son varias 
> > categorÃas bien definidas y con muchÃsima mÃs informaciÃn. Reorganizar la estructura fÃsica de ficheros 
> > es un trabajo arduo.
> >
> > - Dentro de un directorio en particular tenemos numerosos ficheros, los cuales estÃn organizados como 
> > mejor hemos podido. Por ejemplo, supongamos un directorio /prgtk con manuales sobre programaciÃn en 
> > gtk2.0. Dentro hay pdf muy completos e interesantes, que tenemos como referencia obligada, y otros con 
> > algÃn aspecto puntual sin interÃs actual (quiÃn sabe en un futuro) y que guardamos en /otros. AdemÃs, 
> > puede que tengamos el mismo fichero en pdf y en html, lo cual implica otra carpeta adicional con su 
> > subestructura de ficheros, que complica la bÃsqueda del index.html por ejemplo. En el fondo estamos 
> > intentando clasificar las caracterÃsticas de cada fichero por la estructura fÃsica de directorios y no 
> > por metadatos, labor que considero infructuosa y temporal.
> >
> > - En una estructura de miles de directorios y subdirectorios, recordar en cada momento dÃnde està cada 
> > cosa es poco menos que imposible.
> >
> > - Los nombres de los ficheros no son lo suficientemente largos ni descriptivos como para poder saber 
> > muchas veces quà hay dentro del mismo. Se necesita informaciÃn adicional sobre el fichero/directorio para 
> > que la bÃsqueda sea mÃs prÃctica. Y no hace falta decir el trabajo necesario para renombrar todos los 
> > ficheros del tipo tut_pygtk_v1.0.pdf a nombres mÃs "sociables". El sistema de notas y emblemas que 
> > integra nautilus es un principio, pero me gustarÃa ir mÃs allÃ. 
> >
> > ÂQuà sistema propongo? Lo ideal serÃa una implementaciÃn con al menos las siguientes caracterÃsticas:   
> >
> > - SeparaciÃn entre la estructura organizativa de la informaciÃn y la estructura fÃsica de ficheros.
> >
> > - Manejo de la informaciÃn como objetos y no como ficheros (por ej. un manual en html multi-pÃgina serÃa 
> > un solo objeto)
> >
> > - Posibilidad de asignar y visualizar informaciÃn adicional fÃcilmente a un determinado fichero (objeto), 
> > como metadatos. 
> >
> > - FÃcil ediciÃn para organizar la estructura de la informaciÃn, pudiendo crear secciones, subsecciones y 
> > enlazar tanto con direcciones url de internet como con del tipo file:// de una manera cÃmoda.
> >
> > - Sistema de bÃsqueda por nombre real y por metadatos.
> >
> >
> > Todo esto se podrÃa integrar en Nautilus de alguna forma. Algunas implementaciones existentes que he 
> > estado mirando y que podrÃan aprovecharse en mayor o menor medida son las siguientes:
> >
> > - El sistema de metadatos (notas y emblemas) de Nautilus, mÃs ampliado. 
> >
> > - Una plataforma wiki como herramienta mÃs flexible y eficiente para editar la organizaciÃn de la 
> > informaciÃn. PermitirÃa de una forma muy sencilla crear secciones, subsecciones, textos, comentarios y 
> > enlaces a direcciones de internet y ficheros locales, mostrando toda la informaciÃn de los metadatos para 
> > conocer sus caracterÃsticas de un vistazo. TambiÃn que permita enlazar un directorio, dentro del cual 
> > navegarÃamos como ventana normal del Nautilus. No serÃa muy descabellado integrar un wiki en Nautilus 
> > como extensiÃn, estando moinmoin escrito en perl. Incluso hay una versiÃn Desktop Edition [1] que trabaja 
> > en un directorio local de home. Definiendo en moinmoin /home/Archivo como directorio de trabajo se podrÃa 
> > acceder a todos los ficheros como locales al wiki, por dar una idea.  
> >
> > - El sistema de gestiÃn de colecciones de GNOME Vazaar [2], aunque me parece mÃs flexible el wiki.
> >
> > - El enfoque del entorno de trabajo de GnomeShell [3] y su nuevo paradigma de gestiÃn de informaciÃn.  
> >
> >
> > Conste que soy poco amigo de las soluciones no tradicionales, pero reconozco que un sistema de gestiÃn 
> > como este es mucho mÃs eficiente para un escritorio que la navegaciÃn por directorios de toda la vida. En 
> > fin, no sà si algo parecido està ya en marcha (quizÃs GnomeShell), pero como mÃnimo vamos a generar un 
> > interesante debate.
>
> Yo dirÃa que todo esto lo soluciona Tracker/Beagle, y mÃs ahora que se
> integran cada vez mÃs informaciÃn semÃntica (metadatos++) dentro de las
> bases de datos de ambos. ÂHas leÃdo estos proyectos? ÂVan en la lÃnea de
> lo que buscas?

Algo conocÃa de ellos, pero no los habÃa estudiado demasiado.
Los he instalado, y mientras hacen el indexado los voy mirando y te cuento. Tienen buena pinta sin duda. 

> No dejes de mirar GNOME Zeigeist (http://live.gnome.org/GnomeZeitgeist)
> que tambiÃn ayuda en la localizaciÃn de la informaciÃn mostrando un
> diario de actividad.

Zeigeist va mÃs en la lÃnea de lo que yo digo, le darà un vistazo.

> Hasta luego
>
> > Un saludo.

Gracias ;)



> > [1] http://moinmo.in/DesktopEdition
> > [2] http://www.kaskaras.net/vazaar/index.php
> > [3] http://live.gnome.org/GnomeShell/Screenshots
> > _______________________________________________
> > Gnome-hispano-list mailing list
> > Gnome-hispano-list gnome org
> > http://mail.gnome.org/mailman/listinfo/gnome-hispano-list