Comment 2 for bug 363978

This is the example I had in mind:
For a few years I have been using a spreadsheet to keep a list of events, participants, and notes on the events and the participants. I started working on transferring this into a database, but I then thought that I would much rather be able to put all of the information into Zim. The advantage of putting it in Zim would be all of the advantages of a wiki -- in a spreadsheet or database I cannot so easily link between different people or events, nor can I so nicely integrate images and web links and different formatting of text. My notes on Event 5 could link to a previous, related event (Event 2) and to the participants (Person A and Person E) and also contain a photo of the event. Also, Zim notebooks can be easily tracked within a revision control system.

However, in its current form, the Zim version of this event/participant data would lack certain useful features of a spreadsheet or database, including structuring the data into separate fields and being able to automatically generate lists of people or events and sort them by criteria (date of event, or location of person). A spreadsheet or a database also allow fairly easy export of data for use in other applications. So, if I was in Zim able to define a Person schema and an Event schema, and have wiki pages acting as instances of those schemae, and export it all by means of RDF to be used in other situations, such as to be queried using SPARQL, it would basically eliminate any disadvantage of using Zim for this data.

In more general terms, as wiki systems like Zim and MediaWiki and so on are used to organize more and more of the world's data, it increasingly makes sense to enable these systems to encode metadata and other semantics to increase the usefulness of the data. But I'm sure you developers all know that already :-)