Hi,

another version of Vazaar is out for testing. Get it while hot. There are a lot of changes respect older versions. Now, you can manage easily your notes, diary, bookmarks an other resources. Also, you can display them as graph of connected resources or as a list. Resources can be imported/exported to/from other persons.

Don’t hesitate to email me with your comments (kaskaras @ gmail.com). Please, visit my launchpad project page for more info, report bugs, ask questions, etc.

.

How to get it

• Direct link to download
• From repository: bzr branch lp:~kaskaras/trunk/vazaar vazaar-readonly
• From Pypi (updating)

How to install it

Once unpacked in any arbitrary directory:

• Exectute it by running: ./bin/vazaar

• Install it system-wide by running: sudo python setup.py install

Similar Posts:

• Reports with Cheetah templates
• distutils implemented
• What is coming in the next version
• Blog info updated
• vazaar-04-starthere

Most of time, I’ve been reading more and more about NEPOMUK and playing with SPARQL queries. I have to recognize that it not that simple as I thought in a first moment but I’ll talk about this [intlink id="41" type="category" target="_self"]later[/intlink].

I have something to say about RDFLib: it is wonderful. From time to time I have to deal with some glitches but, most of them, are related to my own code. Anyway I am not using all the potential that this library offers.

Current work:

• Vazaar is more stable than before. But (there is always a but) sometimes it crashes with a “segment fault”. This behavior is random and it is related with ‘Website’ resources.
• Resources are not added directly to database. Before that, resources are passed to a queue. That means that you can enqueue new resources without waiting to finish the last one. Despite of Vazaar is designed to work with threads sometimes the GUI is blocked. This part is the most difficult and annoying thing that I’ve found. Someone smartest than me should take a look to the code.
• By now, it is only possible to create/edit pimo:Notes (it’s finished but needs a deep revision)
• “Copy & Paste” mode is working very well. If you copy any text from anywhere from your Desktop it will be added as a note. But Vazaar can recognize if it is more than simple text: if you copy an URL, the text will be added as a Website or if you copy a file from Nautilus the text will be added as a resource depending on its mimetype.
  Also, clipboard monitoring can be toggled at any time.
• One of the most important features that I want for Vazaar is the possibility of displaying the resources content. Right now, Vazaar is able to display text-based resources (like the source code from a given program), audio, video, images or websites. Other resources like OpenOffice.org documents, compressed files, ISO images, etc. are executed in its own program.
• Backup & Restore of your knowledge database. Although it is working very well it is not finished yet.
• Basic D-Bus support implemented. Although I haven’t yet decided an API, in the future, others applications will be able to interact with Vazaar to query its database, add resources, etc. …
• A basic but extensible plugin system based on hooks is available and working. I have tested it developing smalls plugins which extends the funcionality (send notes to twitter, extend menus, ..). In the future I hope to extend the funcionality of Vazaar by releasing plugins instead of releasing new version of this application.
• The SPARQL Editor have been improved: now it groups triples according to its subject.
• New icons to describe resources
• I’ve developed a new Tag Cloud widget. Websites are analyzed getting their tags (if any). Tags are saved as resources as well.
• I’ve started to define the PersonalInformationModel. The Knowledge Database must know who is the owner of (meta)data. This is necessary to share info with other people. Right now it is defined by a set of triples which define a pimo:PersonalInformationModel, which has a pimo:hasOwner. The owner is defined by a nfo:Contact
• Another feature that I am trying to handle is related to bug lp:425877 in lauchpad. I’m trying to keep Vazaar window size as small as possible in order to be used in small devices.

Work to be done before releasing the next 0.5 version:

• Be able to handle other kinds of resources like: pimo:BlogPost (diary entries), pimo:Topic, pimo:Person and pimo:PersonGroup (nco:Contacts), pimo:Organization, pimo:Project, pimo:Event, pimo:Meeting, tmo:Task, and tmo:TaskGroups, nfo:Bookmark and pimo:Collection
• Be able to define relations between resources
• Temporal bags: a way to make operations over different resources at the same time. Think in it as virtual collections of resources.
• Annotate resources. Any kind of resource can have any number of annotations.
• Support for i18n (make Vazaar translatable)

I’ll try to develop all of this along the summer and I hope to have the new version ready for production before next Ubuntu release. Also, I hope to have Debian packages ready to install easily. At the same time, Vazaar be able to be installed from Pypi.

If you are interested in the development of this application (and you are really welcome), take a look to my Launchpad webpage. Check out lp:~kaskaras/vazaar/trunk for last bits (bzr branch lp:~kaskaras/vazaar/trunk)Similar Posts:

• Reports with Cheetah templates
• About Vazaar 0.4 Beta development
• vazaar-04-starthere
• New custom timeline widget
• Dynamic SPARQL queries and Datatypes

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.Similar Posts:

• Extrayendo metadatos: libextractor
• Nepomuk
• GUI improvements
• Reports with Cheetah templates
• What is coming in the next version

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).
Similar Posts:

• Nepomuk
• Comenzando…
• Dublin Core
• Initial import
• Metagoofil

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).Similar Posts:

• Nepomuk (y II)
• About Vazaar 0.4 Beta development
• Extrayendo metadatos: libextractor
• Comenzando…
• How to fix your sqlite database after corruption