Interesting Discussion about Piggydb at outlinersoftware.com
Posted: September 11, 2012 Filed under: uncategorized 8 CommentsAn interesting discussion about Piggydb has been going on at outlinersoftware.com, which was mentioned in a blog comment (thanks, Alexander!).
Piggydb is a kind of software that is difficult to explain, so I have been struggling to find good words to describe this software to people who are not familiar with this organizing tool sphere (whereas I think the difficulty of explaining is important to invent a new paradigm).
Piggydb is certainly similar to an outliner.
By the way, in Japan, outliners are often called ‘Idea Processors’. I don’t know why, but I guess they focus on the MindMap-like functionality of a tree structure.
I think that an outliner is a basically one-theme-session-oriented organizing tool (like a MindMap), while Piggydb is for a longer span of idea exploration involving multiple themes. And also, there is the difference of the organizing processes: top-down (outliner) and bottom-up (Piggydb).
Then, most importantly, Piggydb has been striving to extend organizing or structuring functionality to promote concept discovery (structuring ‘information’ into ‘knowledge’ and more, ‘wisdom’ maybe). I’m going to write about it in detail in the series of articles ‘The Piggydb Way’.
Anyway, it is very inspiring to see discussions on a site like outlinersoftware.com. If you are interested in outliner software, definitely check it out 😉
Piggydb 
Thank you for the mention Daisuke! At the outlinersoftware.com forum we have often discussed about the limitations of classic outliners. Their strong point –hierarchy- can become a weakness when you have items that fit in multiple branches. Even in mind maps, which in practice are outlines on a plane, you often have to link nodes from opposite sides of the map. Piggydb overcomes this limitation with the relational links but also with the hierarchical tagging, which is the hierarchy without the category limitation. So yes, I believe you are on to something with the “Piggydb Way”.
By the way, if there’s one major suggestion I want to make for Piggydb, it is to have some form of export, e.g. a web publish function. I’m not sure how this would work in practice, in terms of the structure, but now it is very difficult to get “out” what is in Piggydb.
Hi Alexander,
Thank you for your comment.
As for publishing functionality, I think there are two ways to implement it. One is to extend the current Document View to be more browsing friendly, and the other is to provide more flexible export functionality that allows you to export a certain part of your database in a more portable format.
I would personally vote for the latter. Being able to export into some universal format (XML, CSV, …) would be useful for getting material to other programs. A third alternative would be to export to some javascript module which allows one to view the database but not edit it.
I don’t know if you are familiar with the Brainstorm software; see the last part of this video http://www.brainstormsw.com/sbp/index.html for its “web publish” feature which works this way. You may want to download the trial version and see it for yourself.
Thanks for the info about the Brainstorm software, which I’ve never heard of before, but seems like an interesting software and I’m interested more in its history.
I feel the Brainstorm’s “web publish” feature is more like the Document View if it has more dynamic behaviors by JavaScript. The Document View is not exactly an exporting feature though.
I am definitely interested in implementing flexible import/export features and have been thinking about how to do that, so your suggestion is really helpful.
[…] Show all 2 highlights Sort Share piggydb.net 3 months […]
Hi, I appreciate very much this application, specially the capability to create a complex network connection among all ideas / fragments and its advanced tagging features.
Anyway, I write technical documentation (so MathJax support is welcome) and usually I do not use wiki, also for compatibility with a lot of online sources.
Given that wiki syntax seems to be translated in html by the server, why not to allow the user to edit fragments in html/xml?
I do not think to html editing features (to heavy for this kind of app), but a minimal set of features:
– set fragment ‘type’ as wiki, html, xml (for data storage) – html would be embedded directly by the webserver, xml would be loaded as txtcode or translated to generic xhtml (xml tags as .. items)
– allow tag-based css association (insert custom css, e.g. selected by tagnames starting with css..)
– allow fragment editing with external apps (to configure) – maybe this would imply the temporary exportation of the currently edited fragment to a local folder and import after modification
– exportation to a single xml is too big for massive projects – maybe better having one xml for the network (without content but referencing it) and a folder with all fragment codes (html, xml, txt files cooording to the type)
Just to suggest an additional feature not concerning the import/export:
add names / tags for relationships (relationship name, role names for each connected fragment)… but this is maybe too advanced at this stage.
Anyway my best wishes for this very smart way to manage knowledge…
Netsaver
Thank you for your feedback!
> why not to allow the user to edit fragments in html/xml
I thought it would cost too much because of the need for security measures and it would just complicate the program. Now I think it is not a high priority feature to implement.
> allow tag-based css association
This is included in the plan.
> allow fragment editing with external apps
I have a plan to provide Piggydb API in future versions, so it can be realized with this API.
> add names / tags for relationships
This is also included in the plan, but as you wrote, it should be considered carefully because of its impact.
Been using piggyDB for only about a month, am excited about it and feel it is going to save this non-coder a lot of time. My ideas aren’t going to overshadow the above editing suggestions but might help a little before requiring exta-piggyDB-editing. Two improvements that I would like to see are:
1. the ability to edit a fragment as new, this can affect efficiency and accuracy.
2. the ability to bring up fragments using tags while continuing to edit current fragment, and the opposite, to edit a fragment or create a new fragment while having other fragment(s) visible.
Editing a fragment while accessing other fragments will help me in using my favorite piggyDB function, the ability to embed other fragments and files.
A good example would be having a fragment (e.g. #100) with many fragments and images embedded in it while editing text in at least one other fragment (e.g. #135) that will be, or already is embedded in fragment e.g. #100.