Tracker en GNOME

Expositor: Iván Frade (frade)

Moderador: Sergio Infante (neosergio)

Sábado 05 de septiembre de 2009, 17:00 horas UTC

irc.gnome.org #gnome-hispano


Buenas tardes, siendo las 17 horas UTC, damos inicio a la charla IRC de setiembre de Gnome Hispano

El dia de hoy tendremos el honor de atender a la charla de Ivan Frade
que nos dara alcances sobre Tracker

Unos datos sobre el
Ivan Frade es desarrollador de tracker y trabaja en nokia integrándolo en la plataforma Maemo (distribución basada en linux usada en los Internet tablets). Es además contribuidor en otros proyectos de la plataforma gnome y ha participado en distintos eventos de la comunidad. Ultimamente se dedica a hacer promoción de tracker en todo foro a su alcance para integrar mas aplicaciones y atraer contribuidores a la (fantasiosa) idea de un desktop con metadatos centralizados.

bueno entonces con ustedes Frade :D

gracias neosergio 
muchas gracias a todos los que estais ahí leyendo
esta es mi primera charla en el IRC, espero que salga bien
como neosergio explicó antes, mandadle a el en privado la preguntas
para mantener el canal organizado
podeis mandarle las preguntas en cualquier momento, y mejor que interrumpais para hacer la charla mas amena
y mas en forma de dialogo

mi plan es explicar brevemente como empezó tracker y que era tracker hasta la version 0.6
la que la mayoria de vosotros, usando las distribuciones habituales, tendreis instalada
pero sobre todo lo interesante es el futuro tracker 0.7
donde proponemos una idea completamente distinta y mucho mas interesante para el escritorio en general

= Tracker hasta 0.6.6 =

Tracker empezó como una alternativa ligera y en C a Beagle
Beagle es un buscador en C# (disponible en muchas distribuciones)
que (al menos al principio) consumia mucha memoria,
asi que Jamie McCracken decidió empezar tracker
ambos proyectos tenian la misma idea:
escanear el disco duro (la parte del usuario)
leer la informacion y meterla en un indice
de tal manera que se pudiese buscar rapido

tambien se dieron cuenta de que "archivos" en general, es muy vago
y normalmente el usuario sabe que _tipo_ de archivos busca
asi que añadieron categorias, como Musica, Video....
para refinar la busqueda
e incluso empezaron a extraer informacion de los ficheros (como el ID3 de los mp3)
Tracker incluso empezó (no estoy seguro de Beagle) a soportar "tags"
etiquetas
es decir, el usuario puede asignar una palabra(s) a un determinado fichero para encontrarlo despues
hasta aqui no hay muchas sorpresas, y es la idea normal de un buscador

= Tracker 0.6 -> 0.6.96 =

Hace mas o menos 1 año y media, en nokia pensamos en añadir un sitio centralizado para datos y metadatos en maemo
(maemo es la distribucion de linux que nokia usa en sus "internet tablets", y ahora en un telefono)
tracker era la decision obvia: ligero, escrito en C...
usando los estandares de freedesktop...
y compilaba casi directamente en maemo

sin embargo resultada muy dificil de ampliar o mejorar
el codigo habia ido creciendo y creciendo y nadie habia puesto un poco de orden
asi que habia codigo duplicado, no habia modulos claramente separados...
asi que con la ayuda de algunos bravos hackers (incluido garnacho, presente en este canal)
empezamos a limpiar y reorganizar el codigo

fue un proceso largo, que nos llevó a la version 0.6.90 y siguientes
(que son las incluidas hoy en dia en las distribuciones)
esta version 0.6.9x es tambien la incluida en maemo5, el ultimo release de maemo
que es el software que corre en el N900, anunciado por nokia esta semana
la pregunta entonces es.... "esta tracker terminado?"
o quiza... "que le falta a tracker?"
despues de un año trabajando en el, nos dimos cuenta de muchas limitaciones
no solo en el codigo, sino en todo el concepto de "buscador"

soportamos etiquetas, pero no podemos guardar metadatos mas complejos
por ejemplo, una direccion que contiene varios campos
y tracker esta pensado para indexar el sistema de archivos
asi que no podemos guardar en tracker nada que no tenga forma de archivo
es decir, no podemos guardar contactos
e incluso, si haciendo "trampas" guardasemos contactos, 
no podemos enlazar un contacto con un archivo o hacer cosas mas interesantes

tracker 0.6 esta bien para ser un indexador, pero necesitamos algo mas
necesitamos decir más cosas sobre más recursos (paginas web o contactos, por poner un ejemplo)
y necesitamos unir esa informacion entre si, para poder ofrecerle algo más al usuario
Asi que después de darle muchas vueltas, llegamos a la idea de tracker 0.7

(alguna pregunta hasta ahora?)

me parece que todo claro

bien

no ha llegado preguntas aun

== tracker 0.7 ==

esta es la parte interesante
En tracker queremos guardar informacion sobre "cosas" (ficheros, paginas web, contactos, bookmarks)...
y enlazar esa informacion entre si
"mi amigo X me mandó el fichero Y"
"esta foto Z la publiqué en facebook y se la mande por correo a A,B y C"

y esto abre varias preguntas:
1) Para qué guardar esa informacion
2) Como representarla/almacenarla para consultarla de forma eficiente
3) Como reunir esos datos

El punto 1) es uno de los que mas nos cuesta explicar
la idea que tenemos en tracker, es olvidarnos de "la busqueda de texto"
olvidarnos de "el usuario teclea y nosotros *magicamente* le damos lo que busca"
el camino de "la busqueda libre de texto" esta muy explorado y los resultados no pueden ser buenos
pueden parecer mas o menos buenos, pero no se puede hacer nada interesante

sin embargo, al tener la informacion "relacionada" 
las aplicaciones pueden mostrar "contexto" al usuario
el navegador puede mostrar un bookmark, y la informacion del contacto que me lo mandó
en la aplicacion de mensajeria, puede ver al contacto y los bookmarks que me envió, o los ficheros, o los mp3...
lo importante es qeu no es el usuario el cliente de tracker
sino _las aplicaciones_

eso nos lleva al punto 2)
la aplicacion quiere usar esa informacion... como la vamos a guardar y consultar?
para eso vamos a usar un par de ingredientes de la "web semantica"
una cosa llamada "RDF" (tripletas) y un lenguaje de consulta llamado "SparQL"
para darle sentido a las tripletas, usaremos un tercer ingrediente, llamado "ontologia"

antes de descifrar esas palabras, voy a por el punto 3
para resolver el problema de reunir la informacion, vamos a cambiar la arquitectura de tracker y como las aplicaciones interactuan con el
en lugar de tener un indexador que recorre el disco duro interpretando los ficheros de los otros programas
tracker va a ser un almacen de informacion, pasivo, con un esquema bien definido
y las aplicaciones meteran la informacion directamente en tracker

algunas aplicaciones tendran UI (por ejemplo Tomboy guardando sus notas en tracker)
otras seran solo procesos (uno monitorizando twitter, bajando los ultimos mensajes y guardandolos de nuevo en tracker)

el ejemplo de Tomboy me gusta especialmente:
_antes_ tracker iba al directorio .tomboy, leia los ficheros, los parseaba para entender la informacion y la guardaba
el problema mas evidente: que pasa si tomboy cambia su formato
_ahora_ (0.7) tomboy tendra un plugin que escribira sus notas directamente en tracker, en un formato bien definido
es mas, al estar el formato bien definido
cualquier otro programa puede preguntar "dame todas las notas"
o "dame todas las notas entre esta fecha y esta otra"
o, incluso si tenemos informacion de GPS disponible
y al guardar la nota alguien añadio "salvada en Gran Canaria el 7 de Julio de 2009"
un programa podria mostrar un mapa con las notas en las localizaciones
(y ese programa seria independiente de Tomboy en si mismo)
las notas podrian venir de distintos programas.
en el momento que son traducidas a nuestro "esquema predefinido"
son pura informacion, independiente del programa

frade una pregunta

(y accesible para todos los demas programas)

neosergio, si

pregunta de eeejza : 
que differencia tiene estos metadatos con los posibles metaadatos de sistema como atributos extendidos (chattr) que te da un filesystem moderno. y Tracker es similar a lo de KDE con nepomuk?

los atributos extendidos estan metidos en el sistema de ficheros
y son mucho mas limitados de lo que podemos almacenar en tracker
son metadatos tambien (y de hecho es informacion que siempre leemos de los ficheros)
pero no es tan flexible como una base de datos "externa"
a su favor tienen que siempre serán mucho mas eficientes
la idea de tracker va por informacion mas de "alto nivel"
(al menos mi idea de esos atributos extendidos es que guardan informacion mucho mas tecnica, no en el nivel del usuario)
de todas formas, son soluciones complementarias
cierta informacion ira en los atributos extendidos, otra en tracker
(con esto espero haber aclarado la primera pregunta)

Nepomuk era un proyecto europeo, que produjo varias cosas
una de ellas son las ontologias, (el "esquema predefinido") que queremos usar en tracker
eso significa que KDE y GNOME hablaran el mismo vocabulario para almacenar la informacion
estamos en contacto con la gente de KDE, y tenemos planes para compartir mas y mas cosas
(la primera tarea es hacer un paquete de ontologias, un "shared-desktop-ontologies".... igual qeu compartimos la base de datos de mimetypes)
espero que esto aclare la segunda pregunta

frade, hay dos preguntas mas

genial!

la primera 
pregunta de _acs_ : pregunta: ¿no será complicado modificar todas las aplicaciones para que guarden su información según las ontologías de Tracker?

buena pregunta
es mucho trabajo, si
pero no hay que hacerlo de un solo golpe
las aplicaciones iran implementando plugins para meter informacion en tracker
para las mejor diseñadas sera trivial, otras tendran que modificar bastante el codigo
(yo lo veo hasta una forma positiva de probar/mejorar el diseño de las aplicaciones)
la complicacion no es el codigo de la aplicacion en si
sino que las ontologias (de nuevo, el esquema comun que proponemos) contenga todo lo que necesitan
en ese sentido en maemo hacemos de punta de lanza, y estamos recibiendo mejoras y comentarios de aplicaciones en varios dominios
en el mundo GNOME, sin demasiadas complicaciones, es facil "enchufar" telepathy (IM) a tracker, para evolution hay un plugin...
de momento es bastante "hackerish" pero en el futuro, cuando la cosa se asiente, y tengamos una buena documentacion, y proyectos haciendo masa critica
esas adaptaciones seran mucho mas sencillas

la siguiente pregunta, podria ayudar aun mas para tener mayor claridad del panorama
pregunta de _acs_ : ¿es escalable lo que propone Tracker de centralizar toda la información del escritorios?

Tenemos un modelo de base de datos que "escala" muy bien
y no se centraliza _TODA_ la informacion del escritorio
sino la informacion "de usuario"
es importante aclarar
que tracker ofrece un almacen para la informacion a) de usuario b) relevante para el desktop
tracker NO es el reemplazo de SQLite para las aplicaciones
es totalmente licito (y recomendable) que las aplicaciones tengan sus propias bases de datos para sus cosas
volviendo a la eficiencia, en tracker algunas pruebas con 5000 contactos, sus telefonos y direcciones postales
las respuestas a las consultas (nombre para este numero de telefono, etc...) llegan en unos pocos milisegundos
y eso sin haber entrado en optimizaciones "profundas"

neosergio, alguna pregunta mas?

una mas
pregunta de eeejza : si tracker guardaba la info en .tomboy quiere decir que tomboy era una dependencia de tracker? Sabes si tracker lee las dublin:core (metadatos) de OpenDocuments?

uhmmm no, la relacion tracker/tomboy es en la otra direccion
tracker _leia_ la informacion de tomboy (tomboy no sabia nada de tracker)
en el futuro, tomboy deberia escribir sus notas en tracker, y entonces la dependencia es: tomboy depende de tracker
(estamos proponiendo tracker como modulo en la plataforma GNOME para facilitar esta dependencia de las aplicaciones)
sobre los OpenDocuments, no estoy seguro
si no recuerdo mal
tracker indexaba los ficheros de openoffice y office usando programas externos (w3... o algo asi)
en un futuro, si las cosas van bien, usaremos libstreamanalyzer (del proyecto strigi) para leer ficheros
en cualquier caso: si no lo hacemos todavia, sin duda son metadatos qeu esperamos extraer de los ficheros

nos quedan 5 minutos... verdad?

mi plan era mas o menos: contar que son las tripletas/RDF/ontologias, un ejemplo del lenguaje de consulta y algunas ideas de como veo Tracker y GNOME3 

excelente

bien

nadie mando mensajes quejandose de la extension de la charla, entonces adelante

como antes cité, vamos a guardar la informacion usando algunos ingredientes de la web semantica
el mas importante de ellos posiblemente sea "RDF"
es un estandar del W3C, teneis una especificacion online
http://www.w3.org/TR/REC-rdf-syntax/
y este documento que acabo de poner el link
(RDF Primer) es una buena introduccion (en ingles, eso si)

lo que yo quiero contar es una version hiperresumida 
la idea de RDF, es que todo lo que necesitamos decir sobre algo, se puede expresar en tripletas
en un grupo de tres elementos:

<sujeto> <propiedad> <predicado>
algo asi como en el lenguaje natural: sujeto, verbo, predicado
así, si hablamos de "http://maemo.nokia.com", podemos decir
<http://maemo.nokia.com> autor "nokia"
<http://maemo.nokia.com> habla-de "maemo"
el sujeto es el elemento del que hablamos (en este caso una pagina web, podria ser un fichero, o incluso una URL sin significado real)
las propiedades en este caso son "autor", o "habla-de"

ops, perdon por la errata
donde antes dije
frade> <sujeto> <propiedad> <predicado>
queria decir
frade> <sujeto> <propiedad> <object>
frade> <sujeto> <propiedad> <objeto>

el objecto, en los ejemplos qeu acabo de poner, es solo una cadena de caracteres
puede ser un numero, como cuando digo
<file:///home/ivan/a.mp3> numero-reproducciones 15
y sobre todo.... el objeto puede ser otra URI, otra referencia a un objecto
<http://maemo.nokia.com> contiene-video <http://maemo.nokia.com/videos/introducing-maemo-5>
fijaros que si le damos una URL a nuestros contactos
otra a los ficheros (ya la tenemos, los famosos file://...)
otra a los recursos online (http://...)
con tripletas podemos relacionarlos
con tripletas tambien se pueden definir "clases" o "conceptos"

Contacto es-un Concepto
nombre es-un Propiedad
y asi puedo decir que
<urn:1> es-un Contacto
si pintamos las URL como "nodos"
y las propiedades como arcos que unen esos nodos -> tenemos un grafo
un grafo se puede convertir en tripletas y al reves (son equivalentes)

esta idea (creo qeu sencilla) es realmente RDF
el siguiente paso es entonces "que propiedades puedo usar?"
"que categorias existen?"
si una aplicacion usa la propiedad "nombre" y otra "contacto-nombre", no se entenderan
es entonces cuando aparecen las famosas "ontologias"
una ontologia nos dice qué clases/categorias podemos usar
que propiedades

una pregunta

y la relacion entre todas ellas

si

pregunta de cal :  que ontologias se estan usando con tracker / cuales se pretende empezar a utilizar?

tracker 0.6 usa una ontologia propia, muy sencilla y muy limitada
tracker 0.7 va a utilizar las ontologias Nepomuk, con muchas modificaciones qeu estamos intentando incluir en la especificacion
las ontologias nepomuk
al menos las oficiales esta aqui
http://www.semanticdesktop.org/ontologies/nie/
y las que tracker esta usando ahora mismo, tienes que leerlas de nuestro repositorio, aqui:
http://git.gnome.org/cgit/tracker/tree/data/ontologies
estamos discutiendo algunas mejoras en el proyecto XESAM con los mantenedores de las ontologias

continuo?

el lenguage de consultas que vamos a usar en tracker es SparQL
es el estandard ahora mismo en el mundo de la web semantica
recuerda lejanamente a SQL, pero esta diseñado para preguntar sobre tripletas

(para los mas avezados en el tema, en tracker soportamos el SparQL basico [consultas] y las extensiones para actualizar y borrar informacion)
aqui la spec de sparql, por si alguien se aburre: http://www.w3.org/TR/rdf-sparql-query/
y aqui la propuesta de UPDATE: http://jena.hpl.hp.com/~afs/SPARQL-Update.html
si entendeis las tripletas, sparql es casi directo

aqui va una consulta de ejemplo:
SELECT ?u WHERE {
?u a nie:InformationElement.
}

lo que le decimos es
"dame todos los values de ?u" (lo que empieza con un signo de interrogacion es una variable)
que encajen en ese esquema
esto buscara en la lista de tripletas
y nos dara todos los valores de ?u que sean validos

si tenemos en algun sitio
<url:1> a nie:InformationElement.
<url:2> a nie:InformationElement.
el resultado de la consulta será
<url:1> y <url:2>

este patron puede hacerse mas complicado:
SELECT ?u WHERE {
?u a nco:Contact ;
?u nco:fullname "Ivan Frade".
}
en este caso los valores de "?u" tienen que cumplir con _las dos condiciones_

antes de continuar otra pregunta

si

pregunta de gpoo 
pregunta: Al utilizar URL's como <file:///home/ivan/a.mp3>, se tiene la información de a.mp3 en ese directorio.  Pero si muevo ese archivo a otro directorio, me quedará "basura" en tracker ¿cómo se limpia el contenido en tracker?
la pregunta se relaciona a que programas como Banshee no se dan cuenta de ello, y si no se dan cuenta, mal podrían notificar a tracker

si
la solucion que tenemos en tracker, es un poco mas complicada
usaremos una uri generada para el "contenido"
y enlazaremos con la uri "de la localizacion"
mejor con un ejemplo
en tracker ese mp3 sera:
<urn:uuid:bonito-numero-autogenerado> a nmm:MusicPiece.
<urn:uuid:bonito-numero-autogenerado> nmm:duration 1000.
# pon aqui mas propiedades del mp3
<urn:uuid:bonito-numero-autogenerado> nie:isStoredAs <file://a/b/c.mp3>.
de tal manera qeu al mover el fichero
esta ultima URL cambiara
pero para banshee la URI del fichero es la misma
es mas, si hay dos copias del fichero y somos capaces de detectarlo
podemos ponerle dos nie:isStoredAs al mp3
y banshee solo verá uno
(pero esto tiene otros inconvenientes... es un tema en el que estamos trabajando)

bien, volviendo al lenguage de consulta
un detalle mas es que las variables pueden ir tambien en el lado del "objeto" de la tripleta
podemos hacer:
SELECT ?name WHERE {
  <urn:1> nco:fullname ?name.
}
eso nos devolvera el valor de ?name que encaja con esa tripleta

y finalmente, podemos concatenar variables
SELECT ?name ?codigoPostal WHERE { ?u nco:fullname ?name. ?u nco:PostalAddress ?x . ?x nco:postalCode ?codigoPostal. }
(perdon por el spaglish en las consultas)
en resumen: tripletas/grafo es un esquema adecuado para representar informacion y relacionarla entre si
y SparQL es un lenguaje de consulta sencillo que se mapea directamente en tripletas, para consultar esa informacion

la instalacion de tracker 0.7 ahora mismo es solo recomendada para desarrolladores
pero si alquien se anima a instalarlo (desde el repositorio)
las consultas SparQL estan funcionando
e incluso devuelven resultados despues de indexar los directorios del usuario
no voy a entrar mas en detalle sobre RDF/Sparql
si teneis alguna pregunta sobre esta parte...

pregunta
pregunta de cal: tracker-sparql solo esta disponible en la version de desarrollo? *no lo encuentro en la 0.6.95-2/debian sid*

si
tracker-sparql es una herramienta nueva en tracker 0.7
tracker 0.6 no soporta Sparql
de hecho, usa un RDF muy muy muy reducido para las consultas
todo esto se aplica para el nuevo tracker

otra
pregunta de cal: que store de rdf esta usando tracker por debajo

tracker traduce el SparQL a SQL, y usa SQLite realmente para almacenar las cosas
la "magia" con que hacemos tracker eficiente, esta en esa traduccion
en lugar de usar una tabla con 3 columnas.... (la primera solucion qeu se nos viene a la cabeza si pensamos en como almacenar tripletas)
traducimos cada clase a su propia tabla, con las propiedades basicas como columnas de la tabla
y las propiedades entre clases, como una tabla separada, estilo Entidad-relacion

tracker 0.6 usaba la tabla con 3 columnas y el rendimiento es malo cuando la informacion crece
un tabla por clase significa que 10000 contactos no afectan el rendimiento de las queries sobre 100 ficheros de musica
(el rendimiento es proporcional al tamaño de la tabla, y cada clase esta en una distinta)

preguntas?

una mas 
pregunta de cal: se han planteado la integracion de ciertos contextos del repositorio semantico con aplicaciones de pim para dar permiso a grupos de contactos a realizar consultas sobre nuestro repositorio

el asunto de compartir la informacion de tracker ya salio a discusion alguna vez
introducir usuarios y permisos es muy complejo ...
se podria hacer, pero de momento la idea es mantener tracker como algo para el usuario
a lo que solo el usuario tiene acceso

aplicaciones por encima de tracker serian las encargadas de la comparticion/restriccion de acceso
de alguna manera, cualquier con acceso a la sesion dbus del usuario, tienen acceso a su tracker...
(no esta descartado que en el futuro haya granularidad mas fina en permisos, pero sin planes concretos, es un asunto complejo)

otra pregunta?

no hay mas al momento

bien, pues creo que podemos acabar hablando de GNOME3
o mas bien de mi idea de GNOME3 y como tracker puede ayudar en ella

Si por fin nuestra idea de tracker vuela, conseguimos reunir una masa critica de aplicaciones
que metan informacion
entonces podemos ofrecer al usuario una experiencia de escritorio _nueva_
hay gente que pide "mostrar el status online de la gente a la que le escribo un correo"
eso seria posible si tenemos esa informacion en tracker
(email esta, contactos estará cuando telepathy empiece a usar tracker)
mostrar documentos relacionados, 
el viejo projecto del "dashboard" sera casi trivial de implementar...
y ademas hay otros dos proyectos que complementan (y en cierta medida se solapan) la oferta de tracker
CouchDB sobre sincronizacion
y Zeitgeist aportando informacion "extra"

con estos 3 componentes, GNOME puede tener una "capa de datos" potente
le sumas GNOME Shell para la gestion de ventanas
y podemos ofrecer un escritorio radicalmente nuevo

y para la gente que este en el canal buscando ideas para programar, hay un monton de huecos donde ayudar
1) plugins para programas (tomboy es presa facil!)
2) widgets para hacer mas facil el acceso a tracker
3) refactorizar programas para que admitan varios backends (y uno de ellos tracker, por supuesto)
4) hacer una UI que explote la informacion relacionada...

(otra presa facil para el punto 1) es hacer plugins para EOG)
y sobre 2) es casi vergonzoso que no haya un widget para poner tags en gtk 
[al menos que yo conozca]

y ...
mas o menos eso es lo que queria contar sobre tracker :)
cualquier pregunta sobre el tema, no dudeis en escribirme
ifrade@gnome.org
o uniros al canal #tracker aqui en GIMPNet (en ingles, pero podeis encontrarme alli y abrir un privado)
tenemos una lista de correo, como es habitual (tambien en ingles)

la charla ha estado completa, interesante, y pues ya saben hay mucho por colaborar
me parece que dejamos la moderacion para las preguntas ya finales
si alguien tiene alguna
antes de cerrar entonces, gracias por tu tiempo frade 
y la voluntad y esfuerzo para la charla de este mes

muchas gracias a todos por vuestra atencion