zim-wiki team mailing list archive

["Mark Hughes (Zim mailing list)" <mark@xxxxxxxxxxxxxx>]

On 04/03/2013 12:01, Jaap Karssenberg wrote:
> What may or may not be related is the work I'm doing to integrate 
> "cards" in zim.
>
> Basically this will be a plugin that adds inline objects in zim pages 
> that contain a couple of fields. These fields can be e.g. properties 
> of an object being described.
>
> A concrete example would be to use zim as a book catalog. I would want 
> to define a "book" card that contains fields like "Title", "Author" 
> etc. The Title would be a text field, the Author could be a linked 
> field referring to another page with info about the author.
>
> This become semantic in the way that fields can be links that have a 
> type (e.g. the type "author" in the example above) this forming a 
> triple of the source page, the target page and the type of relation. 
> Next step of course is to integrate such objects in the search dialog, 
> link map visualization etc.
Jaap,

Are you planning integration with database backends? It makes sense to 
me to have a front-end / back-end interface, and for the plugin to 
provide a ready-to-use backend that works within the existing Zim 
storage paradigm, though I have no idea what that means as I say that :-)

While I don't fully understand the Zim paradigm yet, from my past life I 
do have experience of the kind of structure I'm describing so if you 
want to explore this direction I might be able to help with ideas. We 
had a desktop application (data visualisation) and built different 
plugins to allow it to query, display and edit data directly from 
different kinds of database, and different database schema's, and 
ultimately to integrate data from multiple databases into a single view. 
So each plugin knew how to connect to a particular database, and allowed 
the user to create multiple mappings between the application and a 
different database schemas.

I've changed the title in to allow separate elaboration on your Cards 
plugin.

Mark