Re: [Zim-wiki] Cards plugin
On Mon, Mar 4, 2013 at 3:27 PM, Mark Hughes (Zim mailing list) wrote: > Let's say you build your personal data example. Often these things start > simple but then it becomes tempting to add new objects, and then to want to > access them from different devices, run complex queries etc. Soon even a > little "homer" can want much more database functionality. If the data is > stored in a "proper" database, it is relatively simple to extend the plugin > functionality and grow its capability along with user demands. Agreed. So far my data base design did not go further than a big table with properties per object: one column for the object id, one for the property id, and one for the value. I did look at specific solutions that allow to store semantic triples (which is what I really want) but seems to me most of them are just some sugar on top of a basic table as described above. At least I found no triple-store that is fast and as easy to integrate as SQLite. Regards, Jaap ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Cards plugin
On 04/03/2013 12:51, Jaap Karssenberg wrote: 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 I don't have a use case in mind - just triggered by what you described. My thought is that by considering this you could make something much more powerful possible, while if it isn't thought about it won't be easy to add later. The difference will be ensuring your object model allows for database transaction cases, which it may if you do your SQL with this in mind. My thought is not just connecting to existing databases, though that could be very useful and widen Zim's appeal, particularly into corporate scenarios which could be good for promoting Zim. Let's say you build your personal data example. Often these things start simple but then it becomes tempting to add new objects, and then to want to access them from different devices, run complex queries etc. Soon even a little "homer" can want much more database functionality. If the data is stored in a "proper" database, it is relatively simple to extend the plugin functionality and grow its capability along with user demands. That's my thought process. Mark ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
Re: [Zim-wiki] Cards plugin
On Mon, Mar 4, 2013 at 1:41 PM, Mark Hughes (Zim mailing list) 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 ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
[Zim-wiki] Cards plugin
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 ___ Mailing list: https://launchpad.net/~zim-wiki Post to : zim-wiki@lists.launchpad.net Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp
