zim-wiki team mailing list archive

[Jaap Karssenberg <jaap.karssenberg@xxxxxxxxx>]

On Mon, Mar 4, 2013 at 1:41 PM, Mark Hughes (Zim mailing list)
<mark@xxxxxxxxxxxxxx> wrote:
> 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.
>
> 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 :-)

My intention is to store the data directly in the text files and cache
the data in the sqlite database already used by the page index. This
sqlite database is used for search and visualization.

> 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.

Sounds like you are thinking in the direction where the data in the
objects is populated from an existing database.

Not directly my intention but should be possible with a custom backend
for the page data. The code that stores the wiki pages in text files
is a very thin mapping class. Can easily be replaced with something
that uses e.g. a database.

But would help to have a more specific use case in mind. I don't think
zim is necessarily a good generic databse viewer.

My use case is more the other way around, to do a little bit
structured data without the need of a "real" database.

Regards,

Jaap