Infosofía := 0×69AEE7

Introducción

Es la respuesta de KDE a un escritorio semántico. Consiste en un framework para crear y consultar meta datos de cualquier tipo de recurso, por ejemplo un archivo. Dentro de los meta datos podemos encontrar tres tipos.

• Meta datos propios de los archivos.
• Meta datos creados por el usuario (ej. tag o ranking).
• Meta datos que no pueden ser obtenidos fácilmente.

En los últimos es donde podemos encontrar el verdadero poder del escritorio semántico. Plantemos tres ejemplos:

1. Un usuario descarga un adjunto de un mail. Cuando el adjunto se guarda al disco, se pierden las referencias tanto del que envió el mail como la uri desde donde se descargo el mail.
2. Mantener datos para poder consultar que aplicaciones tenía abierta un determinado usuario en el momento que hubo un error en un programa de servicio.
3. Generación de ranking de aplicaciones, archivos, etc de algún usuario. Por ejemplo, cuál es el usuario que más escrituras hace al disco sda1? Cuál usuario tiene el mayor número de paquetes recibidos?.

Componentes

Nepomuk esta compuesto principalmente por Soprano, Stringi y KMetaData. Soprano es un framework orientado a objetos para datos RDF y Strigi es un pequeño y simple demonio de búsqueda portable.

KMetaData

KMetaData es una librería que facilita el acceso a los metadatos a través de wrapper de los mismos. Por lo tanto, manipulamos objetos de clases de recursos.

Soprano

El papel que cumple Soprano es poder bajar el acoplamiento entre nuestros datos RDF y Nepmuk. De esta manera podemos tener un enfoque cliente/servidor y colocar nuestros repositorio de datos RDF remotamente. Además cuenta con una interface para comunicaciones TCP (dentro de otras), es posible tener un repositorio en cualquier parte del mundo. Se podría pensar en la idea de conectarse no con uno, sino con varios. Aquí entra mucho en juego, al tener muchos repositorios, podríamos especializarlos, por ejemplo tener un repositorio especial para programadores y proyectos. Entonces el usuario programador al leer el código fuente de su aplicación favorita, tendría información sobre el perfil de los programadores que la desarrollaron.

Strigi

Strigi es el encargado de indexar y consultar datos disponibles en el disco. Pero la ventaja de Strigi es su sistema JStream, el cual le permite revisar e indexar contenido de los archivos. Por ejemplo podría obtener la duración de un archivo de audio o obtener todos los meta datos disponibles en el contenido de un archivo PDF. JStream esta limitado en estos momentos a un número reducido de tipos de archivos, los más elegante para mi gusto son:

• Paquetes Debian
• Paquetes RPM
• PDF
• MP3

Se podría aumentar ampliamente el potencial de administradores de paquetes, por ejemplo aptitude hace un amplio uso de la rica meta información contenida en los paquetes .deb, el hecho de poder darle un valor semántico, facilitaría las resoluciones de dependencias o conflictos de aptitude. Incluso antes de resolver con determinado conflicto (por lo general pide confirmación al usuario), podría consultar meta información propia del usuario y poder inferir la confirmación del usuario para resolver el conflicto…

Strigi hace uso del subsistema inotify del kernel de Linux. Inotify notifica sobre eventos sobre el sistema de archivos. De esta manera, Strigi puede aprovecharlo para reindexar archivos modificados y ahorrar estar haciendo búsquedas frecuentes por todo el sistema de archivos. Aquí las aplicaciones podrían generar muchos meta datos en relación a log del sistema y como los log son archivos de texto plano se puede aprovechar JStream para obtener más relaciones entre los datos.

En este video se puede ver el potencial de Nepomuk.