But if you prefer a wide-system install, you must use the following command:

sudo python2.5 setup.py install

You can find an entry under Applications -> Office -> Vazaar

python 2.6 also works but it throws warnings.

Please, note that you can NOT combine different versions of python because database sqlite formats differs each from other.

Hi everybody,

a new version of vazaar have been released for testing purposes. Although it’s stable you can consider it as proof of concept.

This version is a redesign of the previous one. While the old one was developed in C, the new one is being developed with Python. Also, I’ve been studying a new approach. Instead of work with tags and tagging operations, the new version is powered by the semantic web vision, ideas and tools.

I’d like to highlight RDFLib, a RDF library containing an RDF triple store and RDF/XML parser/serializer which deals with the logic of the application.

Go to the Download page to get it. Check the screenshot page as well.

Development is carried out at Lauchpad.

Now that I understand how a semantic model works I have more and better ideas to implement.

Next version will be released, hopefully, before this year ends.

Enjoy it.

After some headaches I’ve found how to write dynamic SPARQL queries by passing parameters. For example, to query graph about resources collected last hour this code could be a first approach:

#!/usr/bin/env python
# Dynamic query (example code)

from datetime import datetime
import rdflib
from namespaces import XSD

def last_day():
    """ get date """
    now = datetime.now()
    date = now - timedelta(hours=24)

    return date

def get_date_filtered_query():
    """ build query """
    period = last_day()
    mydate = Literal(period, datatype=URIRef(XSD))

    query = """
        PREFIX rdf: 
        PREFIX nie: 
        PREFIX nfo: 
        PREFIX nao: 
        PREFIX pimo: 
        PREFIX xsd: 
        SELECT ?id
        WHERE
        {
            ?id rdf:type ?type .
            ?id nao:created ?date .
            FILTER (?type != pimo:Collection) .
            FILTER (xsd:dateTime(?date) >= xsd:dateTime("%s")) .
        }
        ORDER BY DESC(?date)
        """ % mydate

    return query

# query graph
query = get_date_filtered_query()
result = graph.query(query)

for id in result.selected:
    print id

For more information is worth to take a look W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes. A self explained list of XML datatypes:

Checking others parts of the Vazaar GUI, I’ve realized that I can query remote ontologies and vocabularies with a simple SPARQL sentence. In the screenshot you can see how I query for the comments of all NAO entities.

Just for the record, it would be nice to save user queries and integrate them within Vazaar. And, of course, to export result data to a file (eg.: in a CSV file) ready to import to a any spreadsheet program like OpenOffice Calc.

After a long weekend coding and trying new design ideas finally I think I got a nice GUI. At least for the StartHere module:

There are still too much glitches in the GUI but I’m trying to fix them as I go. But for now, I feel satisfied. Queries against the model are working as expected.

After clicking in any stats button you get a nice visual for your resources. In next commits, you will be able of choosing one the two kinds of views: ListViews and IconViews. By default, the IconView is preferred.

More ideas are coming like content filtering, properties tagcloud, timeline widget, etc…

At this moment, you can only add new resources by copy&paste operations. An improved dialog for this operation is in the way. Resources can be selected for be deleted. If the selected resource is a collection, all resources which belong to this collection will be deleted. There is no actions popup menu yet but it’s planned.

I’m thinking if a Trash resource is worth. NEPOMUK brings especial classes for this cuestion. I need check twice these. Anyway, it wouldn’t be very difficult.

One of the most important things now is to code common operation for resources: tagging, annotations, relations between them and how to display their content. For example, display text or an image is easy to do but it is not very easy to display websites content. There is not a good browser widget ready to use in PyGTK yet. I put my hope in webkit bindings for Python.

After months of improving my skills with Python and PyGTK and reading documents about semantic web and its integration with Desktops Interfaces (like GNOME or KDE) a lot of improvements have been made in Vazaar. This is an overview of the current state of development.

The presentation layer, the GUI, is more difficult to develop than I’ve ever thought. Althought the concept is simple: given any kind of data, transform them into triples (subject, predicate, object) and operate with them, the time consumed to create an infrastructure around the program has been very high.

As resources can be added at any time, I had to develop a system of queues (qIn and qOut). Furthermore, I had to deal with very high responsiveness times. It’s very annoying when the GUI gets frozen because the kernel is working in other stuff. So I had to implement threads (one thread for the kernel and another thread for the GUI). Along the way, I’ve found a lot of code (see source code in Launchpad) which has helped me to carry on.

In some way, I would like to forget these kind of glitches when I’m developing a Desktop application (not a kernel module). Maybe I’ve learnt something about gtk threads but nothing interesting for this project. Never mind…

I’m still reading some documents and asking about how to create a data model around NEPOMUK. By using the semantic web paradigm things change a lot. There are no database records or tables. Instead there are thousands (or hundreds of thousands) of triples.

But it looks easiest than I thought, at the moment.

Everything is a resource (even collections). A resource has a unique identifier (UUID objects according to RFC 4122). Every resource belong to a unique Nepomuk class. They are a small subset of classes with their properties. Examples of Nepomuk classes are:

• nfo:Feed
• nfo:Website
• nfo:RemoteDataObject
• nfo:Image
• nfo:Audio
• nfo:Clipboard (this class doesn’t belong to NFO but I need it until I find a smart solution for copypaste operations).

As I say before, a collection is a resource. It belongs to the class Collection from PIMO namespace and use the property nie:hasLogicalPart to link resources.

Example of a single resource:

<nfo:Image rdf:about="vazaar://7971c05a-3a69-469e-875c-5ec76b0d0cfb">
    <nao:created>2009-06-09 17:34:51</nao:created>
    <nie:title>comment-icon.png</nie:title>
    <nao:lastModified>2009-06-09 17:34:51</nao:lastModified>
    <nie:mimeMedia>image</nie:mimeMedia>
    <nfo:fileUrl>/home/kaskaras/Documentos/vazaar-export-r303/data/icons/comment-icon.png</nfo:fileUrl>
    <nfo:fileBasename>comment-icon</nfo:fileBasename>
    <nfo:fileScheme>file</nfo:fileScheme>
    <nfo:fileName>comment-icon.png</nfo:fileName>
    <nfo:fileExtension>png</nfo:fileExtension>
    <nfo:fileSize>3269</nfo:fileSize>
    <nfo:belongsToContainer>/home/kaskaras/Documentos/vazaar-export-r303/data/icons</nfo:belongsToContainer>
    <nie:mimeSubtype>png</nie:mimeSubtype>
    <nie:mimeType>image/png</nie:mimeType>
</nfo:Image>

And here and example of a collection:

<pimo:Collection rdf:about="vazaar://9fcea6ca-cc79-4259-baff-6c025319a36e">
    <nao:created>2009-06-09 17:35:13.338280</nao:created>
    <nie:title>/home/kaskaras/Escritorio/screenshots</nie:title>
    <nao:lastModified>2009-06-09 17:35:13.338280</nao:lastModified>
    <nie:hasLogicalPart>
      <nfo:Image rdf:about="vazaar://15e820cb-398c-4917-b162-3b6d10cd8054">
        <nao:created>2009-06-09 17:35:13</nao:created>
        <nie:title>Pantallazo.png</nie:title>
        <nao:lastModified>2009-06-09 17:35:13</nao:lastModified>
        <nie:mimeMedia>image</nie:mimeMedia>
        <nfo:fileUrl>/home/kaskaras/Escritorio/screenshots/Pantallazo.png</nfo:fileUrl>
        <nfo:fileBasename>Pantallazo</nfo:fileBasename>
        <nfo:fileScheme>file</nfo:fileScheme>
        <nfo:fileName>Pantallazo.png</nfo:fileName>
        <nfo:fileExtension>png</nfo:fileExtension>
        <nfo:fileSize>188465</nfo:fileSize>
        <nfo:belongsToContainer>/home/kaskaras/Escritorio/screenshots</nfo:belongsToContainer>
        <nie:mimeSubtype>png</nie:mimeSubtype>
        <nie:mimeType>image/png</nie:mimeType>
      </nfo:Image>
    <nie:hasLogicalPart>
    <nie:hasLogicalPart>
    <nie:hasLogicalPart>
    <nie:hasLogicalPart>
 </pimo:Collection>

Right now, no problems working with this model. It is simple and I think that powerful. But I haven’t finished of defining the basic core of properties for a given resource (single or collection). Thinking in the future of this application, I would like to expose public resources through a SPARQL End Point so another semantic application will be able to ask it. It shouldn’t be so hard as I’ve seen a couple of python libraries to implement it. But the most important now is to have a solid model which I can work with.

Summing up, this is the result of the of the current code:

Start Here

Make your own SPARQL queries

Basic Import support

Basic Export support

About Vazaar

Syntax Highlighting for your sourcecode-based resources

Basic support for image displaying

It’s a prototype. Don’t expect too much. In the next weeks  I’ll try to work in the GUI adding visual improvements and new funcionalities.

Nine months after my last post, I’ve got a new home for Vazaar.

It lives now at https://launchpad.net/vazaar

I want to use the infrastructure provided by Ubuntu to accelerate the development and subsequent integration into
Ubuntu or Debian repositories.

Hope it be useful for everybody.

I don’t know what is going on but my svn repository hosted in Dreamhost is gone  :-(

patience

Edit Saturday, September 06 2008:

Well, finally, I know what happend. My hosting company deciced to upgrade their 32bits Debian OS to 64bits and it failed. A lot. I haven’t lost anything but the svn is misconfigurated. So I’ve changed my repository to google code.

Please, update your bookmarks. You can access to the repository here:
svn checkout http://vazaar.googlecode.com/svn/trunk/ vazaar-read-only

or check this page:

http://code.google.com/p/vazaar/

Sorry about that

Voy camino de ser el blogger más improductivo de toda la red. Creo que leo más que escribo. Intentaré remediarlo. De momento, os dejo esta perla que me he encontrado:

Dublin Core Metadata Glossary

Final Draft

The Dublin Core Metadata Glossary is a collaborative effort of the User Guide Committee with special thanks to Gail Clement & Pete Winn, whose original glossary was a basis for this version. Terms included in this glossary are based on Dublin Core documents, presentations at DC conferences, and discussions on the DC General listserv. We welcome comments and feedback regarding additions, deletions or changes to the terms and/or definitions found below.For related links, including the guide itself, see this site’s home page.

The glossary was last updated on 02/24/2001

Aunque data del 2001 no me consta que las definiciones cambién de lustro en lustro. Todo un manjar para comprender los conceptos de la web semántica.

Editado (jueves, 28 de febrero de 2008 02:16)

He encontrado el glosario actualizado (23 April 2004) en la propia página de Dublin Core

Bueno, después de casi dos meses, puedo decir que he avanzado un poco más. Para no quemarme, aburrirme o morir en el intento voy alternando entre la programación de la interfaz gráfica y el motor de la aplicación.

La parte gráfica de momento es un laboratorio. Me limito a saber leer correctamente los recursos de la base de datos semántica, interpretar lo que me duvuelven las consultas y presentarlo chapuceramente al usuario. Voy a tener que buscar o hacerme bastantes widgets a medida. De momento me he creado una nube basada en una Gtk.Table donde represento los datos y sus frecuencias. Bastante útil, por cierto.

En relación al motor de la aplicación hay tres grandes cambios:

- Para no bloquear la parte gráfica estoy implementando hilos. Deberían llamarse líos.
- He adoptado el uso de colas para todas las peticiones de trabajo.
- Vazaar dispone de un sistema de plugins.

Los hilos es una de las partes más problemáticas y la quiero eliminar en cuanto pueda. Lo natural sería tener un motor que funcione independientemente de la parte gráfica.

La solicitud de trabajos (jobs) se van enconlando y procesando por el DataProvider. Este módulo se encarga de procesar los argumentos y dedcidir de qué tipo de recurso se trata: fichero, directorio, remoto y string. Dependiendo del tipo y el numero de argumentos pasados se llama al módulo Resources donde se construyen colecciones o recursos únicos. Las colecciones albergan dos o más recursos. Uno de los problemas que me ha resuelto la cola es permitir que el usuario pueda trabajar cómodamente mientras se van añadiendo recursos. Por ejemplo, todo lo que corte o pegue quedará automáticamente almacenado como recurso. Automáticamente, el programa se encarga de identificarlo y clasificarlo.

El sistema de plugins era necesario desde un primer momento. Desde que arranca la aplicación hasta que termina hay muchos eventos que atender y muchos recursos que descubrir. Está basado en las setuptools y por medio de ‘capabilities’ el sistema se puede extender. Hasta ahora el sistema de plugins funciona para dar soporte en la extracción de metadatos al módulo Resources y para presentar unas simples estadísticas.

Hoy por hoy el interfaz va unido al motor de la aplicación lo cual no es una buena idea pero de momento no tengo los conocimientos suficientes para montar un servidor de rdf. Lo cual sería una buena idea de cara a montar un servidor público/privado de un repositorio personal o de implentar su compartición vía p2p. Lo dejo para el ToDo.

SPARQL promete como sistema de consulta pero estoy encontrándome con problemas de rendimiento. Rdflib dispone de varios backends para almecanar la información del grafo: en memoria, (des)serializado en n3, rdfxml, etc., en una bbdd SleepyCat con ficheros planos y otro para MySQL. El primero sería impensable pues se comería toda la memoria del sistema. Puedo asegurar que (des)serializando tampoco (aunque de esta manera se aprende a leer e interpretar el propio grafo). El backend de Sleepycat es el que estoy usando ahora y de momento no me está convenciendo. Me parece lento y en la medida de lo posible no pienso aceptar tiempos de respuesta mayores al segundo. Por lo tanto me queda la opción de probar MySQL.

Si quieres ver estas ideas implementadas echa un vistazo al protipo 0.4p1:

svn co http://vazaar-project.org/svn/trunk/devel/0.4p1/ vazaar

Cada día más cerca de sacar algo en claro.

Un saludo

Este es el primero de una serie de artículos sobre Dublin Core (DC) y metadatos. Explicaré un poco la teoría e intentaré mostrar ejemplos prácticos de su uso en Vazaar. Para realizarlo me he ayudado de una traducción al español de DC que he encontrado en RedIris y diversa documentación que he ido encontrando en la web de Dublin Core. Antes de empezar definiendo que es Dublin Core hay que entender que son los metadatos. Por lo tanto,

¿Qué son los metadatos?

Los metadatos se pueden considerar como descripciones que hacemos sobre cualquier clase de recurso que nos ayude a encontrarlo, identificarlo, usarlo, manejarlo, evaluarlo y preservarlo.

¿Cómo se pueden usar los metadatos?

Puedes usarlos para:

• descubrir servicios
• identificar versiones
• marcar la estructura del contenido
• manejar documentos
• certificar auntenticidad
• situar geoespacialmente
• control de derechos
• indicar estatus
• describir procesos

Bases de los metadatos

1. La unidad básica del metadato es una afirmación
2. Una afirmación consiste de una propiedad (elemento) y un valor
3. Todas estas afirmaciones describen los recursos

¿A quién le importa los metadatos?

El término “metadato” tiene sentido en contextos tales como:

• El modelado de datos,
• la catalogación de libros en bibliotecas
• el descubrimeniento de nuevos recursos en internet

Metadatos y Dublin Core

Dublin Core fue diseñado específicamente para proporcionar un vocabulario de características “base”, capaces de proporcionar la información descriptiva básica sobre cualquier recurso, sin que importe el formato de origen, el área de especialización o el origen cultural (extraído de la wikipedia).

Este vocabulario es el resultado de muchos años de búsqueda colaborativa con el objetivo de determinar un conjunto común de propiedades universales que describan cualquier tipo de recurso. El uso de sistemas de clasificación estandarizados hace posible que los metadatos de diferentes colecciones sean combinados y compartidos.

El vocabulario de Dublin Core está formado por elementos. Elementos con nombres descriptivos que pretenden transmitir un significado semántico a los mismos.

Podemos clasificar estos elementos en tres grupos que indican la clase o el ámbito de la información que se guarda en ellos:

1. Elementos relacionados principalmente con el contenido del recurso
2. Elementos relacionados principalmente con el recurso cuando es visto como una propiedad intelectual
3. Elementos relacionados principalmente con la instanciación del recurso

Los 15 elementos del vocabulario de Dublin Core:

Continuará…

Para que Vazaar sea realmente útil debe extraer un alto porcentaje de metadatos que casi haga innecesaria la interacción del usuario. Hay una entrada en el wiki dedicada al análisis de utilidades y/o bibliotecas útiles para el proyecto. Ahora estoy probando con libextractor.

Lo interesante de esta herramienta es la cantidad de metadatos que es capaz de extraer. Este es un listado de los tags soportados por libextractor en mi sistema:

from extractor import Extractor
extractor = Extractor()
extractor.keywordTypes()
('unknown', 'filename', 'mimetype', 'title', 'author', 'artist', 'description', 'comment', 'date', 'publisher','language',
'album', 'genre', 'location', 'version', 'organization', 'copyright', 'subject', 'keywords', 'contributor',
'resource-type', 'format', 'resource-identifier', 'source', 'relation', 'coverage', 'software', 'disclaimer', 'warning',
'translated', 'creation date', 'modification date', 'creator', 'producer', 'page count', 'page orientation',
'paper size', 'used fonts', 'page order', 'created for', 'magnification', 'release', 'group', 'size', 'summary',
'packager', 'vendor', 'license', 'distribution', 'build-host', 'os', 'dependency', 'MD4', 'MD5', 'SHA-0', 'SHA-1',
'RipeMD160', 'resolution', 'category', 'book title', 'priority', 'conflicts', 'replaces', 'provides', 'conductor', 'interpreter',
'owner', 'lyrics', 'media type', 'contact', 'binary thumbnail data', 'publication date', 'camera make', 'camera model',
'exposure', 'aperture', 'exposure bias', 'flash', 'flash bias', 'focal length', 'focal length (35mm equivalent)', 'iso speed',
'exposure mode', 'metering mode', 'macro mode', 'image quality', 'white balance', 'orientation')

A pesar de la gran cantidad de metadatos que puede extraer no facilita manera alguna de saber con que tipo de metadato estás jugando. Según los creadores de esta librería, la mayor parte de los metadatos extraídos están basados en el vocabulario de Dublin Core. Sin embargo, otros metadatos han sido añadidos ante la necesidad de ciertos tipos de formato. Es decir, extrae un conjunto de parejas tipo clave/valor sin orden ni concierto dejando a la imaginación de los programadores la interpretación de los mismos.

En vazaar, MDX es el módulo encargado de la extracción de metadatos. Dado que libextractor está en la mayor parte de los sistemas y existen bindings para python me ha parecido razonable incluirlo. El mayor problema que estoy encontrando para implementarlo es la cantidad de tiempo que gasto buscando que significa cada cosa. Para ello estoy mapeando cada keyword de libextractor con su correspondiente elemento en Dublin Core. También tengo en cuenta los elementos cualificados:

# keyword['LIBEXTRACTOR KEYWORD-TYPE'] = ('DC-ELEMENT', 'DC-TERM')
keyword['album'] = ('type', 'collection')
keyword['aperture'] = ('', '')
keyword['artist'] = ('creator', '')
keyword['author'] = ('creator', '')
keyword['binary thumbnail data'] = ('', '')
keyword['book title'] = ('title', '')
keyword['build-host'] = ('', '')
...

Ejemplo del uso de MDX:

kaskaras@laptop:~/share/wc/vazaar/trunk/devel/swx$ python mdx.py screenshot.png
Adding item: screenshot.png
http://purl.org/dc/elements/1.1/description -> Created with GIMP
http://purl.org/dc/terms/modified -> 2007-11-01 22:04:54
http://purl.org/dc/elements/1.1/format -> image/png

Updated 19/XII/2009:
extract-metadata blueprint @ launchpad.net

He estado leyendo más detenidamente acerca de Nepomuk y sus objetivos llegando a una conclusión muy clara: Nepomuk es más ambicioso que yo. Mientras que Nepomuk se centra en estructurar semánticamente un escritorio con un determinado modelo (PIMO), Vazaar es simplemente un almacen semántico de datos.

Leyendo las especificaciones podría ser interesante utilizar al menos un subconjunto de aquellas ontologías que realmente necesito (nrl, nie, nfo principalmente). Sin embargo, creo que lo voy a mantener lo mas simple posible centrándome en lo que es: un repositorio centralizado de datos y metadatos.

Algunos comentarios sobre Nepomuk

• NRL: Según el abstract de la especificación, ha sido diseñado sobre las bases del lenguage de descripción de vocabularios RDF pero corrigiendo ciertas limitaciones de los actuales lenguajes de la Web Semántica. Dentro de unos meses me gustaría poder explicarlo con más detalle aunque si no he cogido mal el concepto se asemejaria al uso de las vistas en las bases de datos relacionales. Por un lado tienes el grafo y por otro lado las diferentes vistas que podrías crear del mismo (Named Graphs y Graph Views).
• NAO: esta ontología permite relacionar de muchas maneras un recurso con otro así como adjuntar anotaciones, tags, identificadores.
• NIE: Es la más interesante desde el punto de vista de mi almacén, vazaar. La descripción que hace de la misma es contundente: “The core of the NEPOMUK Information Element Ontology and the entire NIE Framework revolves around the concepts of DataObject and InformationElement. They express the representation and content of a piece of data. Their specialized subclasses can be used to classify a wide array of desktop resources and express them in RDF“.

Conclusiones:

• Debido a la complejidad que puede añadir al proyecto el hecho de usar las ontologías y vocabularios que provee Nepomuk voy a optar por ceñirme al ámbito de Dublin Core. Al menos en una primera fase del proyecto. Con RDFS consigo una plataforma ampliamente aceptada e implementada por muchos servicios (swoogle por ejemplo) para consulta/intercambio de metadatos.Dejaré para otra entrada en este diario una explicación más amplia de que es RDF, RDFS, DC, .. y como lo usaré en el proyecto.
• El uso de NIE implica que a mas bajo nivel enlaza con el resto de las ontologías y
• En el caso de NAO y su “Generic Annotation Vocabulary” me parece algo confuso.
• Tengo que estudiar más este tema. La teoría detras de Nepomuk es bastante interesante y podría aprovecharla para el proyecto. Pero la primera fase es aprender a manejarme con los triples, añadiendo, borrando y/o modificando, creando estructuras más complejas y aprender a relacionarlos. Y después representarlos. De nada sirve si el usuario no se puede aprovechar de esta inmensa cantidad de información de una forma práctica, sencilla e intuitiva.

Durante las interminables búsquedas me he encontrado con proyectos muy interesantes como Haystack o Gnowsys. Los dos, y basándose en conceptos similares a los de Nepomuk intentan llevar a la práctica un escritorio semántico. Y los dos, en mi humilde opinión, fallan en el cometido. El verdadero reto, la meta última sería que desde que el usuario entra en el sistema (gráfico) hasta que sale, debería estar haciendo uso de un escritorio semántico. Una aplicación aislada no sirve de mucho. Y Vazaar, de momento, es (será) una aplicación. Como Haystack y Gnowsys (pero en un futuro muy muy lejano, reemplazar a nautilus se me antoja posible).

Llevo unos cuantos meses vacilando sobre qué ontología debería usar para organizar y armonizar toda la estructura interna de Vazaar. No es solo el hecho de darle un identificador a un fichero y adjuntar unos cuantos metadatos ala Dublin Core sino que debería estar basado en una ontología o conjunto de ontologías que definan toda la gestión del conocimiento que se va a adquirir.

Hace unos meses descubrí este proyecto: Nepomuk. Al principio no le dí mas importancia de la que le doy a otros sitios. Buceé un poco en la documentación pero no encontraba más que textos con teoría (bastante interesante). A la saca. Hace poco lo revisité y por fin encontré lo que quería. Las especificaciones de todas las ontologías. Según la especificación, estas ontologías proveen un significado para construir los puentes semánticos necesarios para el intercambio de datos y la integración de la aplicación en escritorios semánticos distribuidos.

Es decir, mas o menos lo que yo estaba pensando pero sin saber como plasmarlo. No he tenido tiempo para estudiar en profundidad como funciona una ontología ni por donde empezar a crearla. Lo mas lejos que he llegado a implementar a sido un namespace llamado PFO basado en una presunta ontología mas conocida como Pathetic Filesystem Ontology. Creo que el nombre lo dice todo. Pero como experimento me sirvió para entender como debía ir usando e integrando las diferentes ontologías.

Un ejemplo del uso del namespace PFO:

<?xml version="1.0" encoding="utf-8"?>
<rdf:RDF
  xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
  xmlns:dc='http://purl.org/dc/elements/1.1/'
  xmlns:pfo='http://www.kaskaras.net/pfo/0.1/'
>
  <rdf:Description rdf:about="file:///">
    <pfo:child>
      <rdf:Description rdf:about="file:///home">
        <pfo:parent rdf:resource="file:///"/>
        <pfo:child rdf:resource="file:///home/kaskaras"/>
        <dc:title>home</dc:title>
      </rdf:Description>
    </pfo:child>
    <dc:title>/</dc:title>
  </rdf:Description>
  <rdf:Description rdf:about="file:///home/kaskaras">
    <pfo:parent rdf:resource="file:///home"/>
    <dc:title>kaskaras</dc:title>
  </rdf:Description>
</rdf:RDF>

Es posible que en algún momento tenga que definir una ontología propia que se adapte mejor a la idea que tengo en mente y que poco a poco quiero ir expresando en este blog pero de momento creo que el mejor camino es dejarlo tan simple como pueda y hacer uso del mayor número de estándares posibles. Y creo que Nepomuk puede ser un buen comienzo.

He echado un vistazo por encima y me he sorprendido de ver que hay una ontología encargada del aspecto más físico de los recursos. Una ontología que describe ficheros, directorios, servicios externos como páginas web, protocolos, … Se trata de NFO. Es una de las siete ontologías que, todas juntas, completan la especificación Nepomuk Information Element Ontology Framework:

• NIE: NEPOMUK Information Element Ontology
• NFO: NEPOMUK File Ontology
• NCO: NEPOMUK Contact Ontology
• NMO: NEPOMUK Message Ontology
• NCAL: NEPOMUK Calendar Ontology
• NEXIF: NEPOMUK EXIF Ontology
• NID3: NEPOMUK ID3 Ontology

Todas ellas están basadas en un lenguage de representación común (NRL) y dan cuerpo al Modelo de Información Personal (PIMO).

Acabo de encontrar una herramienta que va a dar mas vida al proyecto. Se trata de Metagoofil. Como la misma página indica, se trata de una herramienta para obtener nformación de documentos públicos.

Manos a la obra, me he descargado el script y lo he probado. Impresionant. Me he descargado en un momento cientos de documentos relativos a Dublin Core que de otra manera no hubiera encontrado.

Mi test:

kaskaras@laptop:~/tmp/rdf/metagoofil$ python metagoofil.py -d dublincore.org -l 100 -f all -o micro.html -t files

Nota: configura el path del ejecutable extract (libextract) para que apunte correctamente a dicho programa.

Por fin me he decidido a hacer el Initial import de lo que tengo en este momento. Tan solo una prueba de concepto para aprender a manejarme con python, rdf y pygtk.

Se trata de un explorador/visor de ficheros (si se lo puede llamar así) ala web semántica. Mapea un directorio dado en un grafo y muestra los triples, metadatos encontrados* y una imagen del grafo del directorio actual.

Este módulo (al que he llamado swx) se encargará en un futuro de añadir ficheros y directorios al repositorio central así como de proveer de metadatos la base de datos de conocimiento de Vazaar.

El código:

kaskaras@laptop:~/share/wc$ svn co http://vazaar-project.org/svn/trunk/
A    trunk/devel
A    trunk/devel/swx
A    trunk/devel/swx/vazaar.glade
A    trunk/devel/swx/RdfDir.py
A    trunk/devel/swx/file.xpm
A    trunk/devel/swx/namespaces.py
A    trunk/devel/swx/swx.py
A    trunk/devel/swx/folder.xpm
A    trunk/frozen
A    trunk/play
Revisión obtenida: 1

Pantallazo:

* letra pequeña: obtiene pocos metadatos. Falta desarrollar el módulo que se encargue de esta parte

Actualización: instala las utilidades de Redland (no he conseguido hacer funcionar bien pydot) para ver convertir RDF a DOT y poder ver la imagen del grafo.

Bueno, allá va el segundo intento con mi proyecto de los últimos cuatro años: vazaar.

Supongo que no soy el único al que al cabo del tiempo se encuentra con un montón de ficheros desparramados por el disco duro, clasificados subjetivamente en carpetas y subcarpetas sin prácticamente ninguna relación entre sí. Mi primer intento fue una interfaz de usuario sencilla basada en ‘tags’ que actuaban de categorías e ‘items’ que actuaban de recursos. Añadía o extraía algunos metadatos comunes a todos ellos (fecha de inserción, fecha de modificación, el tipo MIME, el icono) e intentaba de varias maneras mostrar esa información a traves de un navegador web integrado en la propia aplicación o haciendo uso de programas externos.

Creo que mi idea era buena pero estaba incompleta y no ofrecía muchas posibilidades de evolucionar. Se guiaba por una estructura de metadatos fijos e inmodificables que imposibilitaba su extensibilidad. Tampoco permitía relaccionar unos metadatos con otros. De ahí que tuve que parar el proyecto. Otro motivo es que me encontraba en Londres y a pesar de aprovechar una buena racha programando y pensando en ello, llegó un momento en que no encontraba tiempo para dedicarme al proyecto.

A mediados del 2006 me topé con dublincore.org y la puerta de entrada al mundo de la web semántica. Desde entonces vengo leyendo y ahondando en las ideas, estándares y documentación que he ido encontrando en la w3c así como multitud de páginas y proyectos de diversa índole.

Posiblemente no sea la panacea pero la web semántica me ofrece la plataforma ideal para desarrollar mi idea sobre lo que debería ser un organizador personal de escritorio. El desarrollo de esta idea lo podéis leer en el wiki. No soy experto en la materia por lo que comentarios, consejos, ayuda y críticas tienen cabida en este blog. Cualquier aportación y/o unión al proyecto también será bienvenida.

De momento, vazaar se encuentra en fase de diseño y cacharreo. A parte de este blog y del wiki está disponible un repositorio svn para el código que vaya saliendo de fábrica.

Empezamos.