Piggydb V5.0-dev5 released
Posted: August 30, 2011 Filed under: uncategorized 15 CommentsThis release adds a cloud view to the Tag Palettes:
The cloud view also supports drag-and-drop tagging.
The Tag Palette on the sidebar has been updated to save the selection of the view type (tree/cloud/flat).
The releases of the V5.0-dev branch are experimental. So the default download remains version 4.23. If you want to try out V5.0-dev5, please download it from the links below:
Piggydb 
Greetings Daisuke
Thanks for this! From your discussion with Hans Peter I was concerned you were deprecating tags a litte, vs hierarchies. Tags, particularly via the dropdown, are a terrific way to place fragments in several groups quickly, in no fixed order, with sorting and filtering available at view time. Very glad you’re enhancing this capability rather than building away from it.
Question for you. I use one modified version of a Piggydb layout: fragment.htm without the sidebar. I’ll probably be making another: a version of document-view.htm with some markup for use in MJBook, which makes self-contained jar documents that run on cheap cell phones like my $15 Tracfone.
The fragment.htm replacement is recognized by Piggydb without a problem because it uses the same name as your original. But the document-mjb-view will be an additional page, which I can form a URL to access. It’s not being recognized just yet. Do these htm page names have to be compiled into Piggydb load code to be seen by the server? I haven’t found them in modifiable run-time code. Thanks for any info about possible integration with user-customized htm pages.
Looking forward to digging into -dev5 later today.
Warmest Regards
Jerome
Hi Jerome,
Thank you for your comment and I’m glad you like the new feature.
Sounds great.
The framework on which Piggydb is based requires that one page should composed of one Java class and one template file (*.htm). So, unfortunately, If you want to customize an existing page, you have to replace or directly modify the template file. As far as I know, there’s no way to add alternate templates to the existing pages without modifying the program.
I will consider adding a feature to add alternate views for such as smartphones.
Best regards,
Daisuke
>The framework on which Piggydb is based requires that one page should composed of one Java class and one template file (*.htm).
Ah, thanks for explaining. Fortunately, there’s a good chance I’ll be able to create the cell phone markup via a Stylish template. Just have to automate MJBook a bit first.
Warmest Regards
Jerome
Hello Daisuke,
This seems a great addition and it will certainly fill someone’s needs (Jerome’s for sure 😉 ). However, I’m sorry to say that I’ve decided to move away from using PiggyDB and am now going back to using a wiki instead. My decision is based on the ongoing discussions that we had before; for me PiggyDB is lacking certain features to manage (VERY) large inter-connected data-sets. I’m not going to elaborate on these shortcomings as I did that already before. Suffice to say that using a wiki gives me greater control over the actual inter-linking data-model.
I still think PiggyDB is a great program that fills a niche, but sadly not any longer for me. I wish you all the best with your ongoing development, and maybe I revisit PiggyDB in another year or so to see where you are taking it.
Take care,
Hans Peter.
Hi Hans Peter,
I’m sorry that the current Piggydb doesn’t meet your needs.
Piggydb is a kind of exploratory project, so it may fail to achieve the goals, or succeed in creating an epoch-making software. I’m just focusing on creating a software that provides a unique value.
Thank you for the valuable discussions. I hope you find a good solution to your problem.
Best regards,
Daisuke
Greetings Gentlemen
Hans Peter: Hope you’ll hang in for this thread, at least. I wanted to continue the discussion and bring up a model that may help us achieve what we’re seeking in Piggydb, but I can’t get to it until later today.
Daisuke: Cloud option for the tag palette is terrific. Possible to retain the preferred view on the dropdown version as we do on the sidebar? Dropdown always returns to hierarchical view.
Thanks
Jerome
Yes, in a future version.
>Hans Peter: Hope you’ll hang in for this thread, at least. I wanted to continue the discussion and bring up a model that may help us achieve what we’re seeking in Piggydb, but I can’t get to it until later today.
I’m looking forward to what you come up with 😉
Hans Peter.
Greetings All
Hans Peter is bringing up a dilemma that we face in describing the relationship between fragments in a hierarchy. How do we classify like fragments and group them together most usefully? Currently, we do so with some combination of tagging and intermediate fragments.
Tags work very well as filters, but they describe the fragment itself, not the relationship between fragments. And they can’t group a series of like fragments within a hierarchy. On the other hand, an intermediate fragment cannot describe relationships beyond its own hierarchy. Daisuke expressed a concern about the overhead and manageability, both for the program and the user, that would come from replicating the hierarchies in the tag system, i.e. from making tags too specific to particular fragments.
I think there’s a possible approach that would bring the advantages of tag grouping into hierarchies while easing manageability. A “Type” attribute that would be very similar to a Tag, except mutually exclusive, and applied both to Fragments and to Relationship Links. A Type is essentially a Primary Tag, and might be structured that way internally.
How would it work? Consider this information from Wikipedia about Stephen Sondheim, the great theatrical composer/lyricist. Just a few of the shows to his credit:
West Side Story (1957) (music by Leonard Bernstein; book by Arthur Laurents; directed by Jerome Robbins)
Gypsy (1959) (music by Jule Styne; book by Arthur Laurents; directed by Jerome Robbins)
A Funny Thing Happened on the Way to the Forum (1962) (book by Burt Shevelove and Larry Gelbart; directed by George Abbott)
The “Type” attribute invites the user to set all tags and hierarchies aside for the moment and declare, finally, what this fragment or relationship really is. So Gypsy and West Side Story are of Type: Shows. Sondheim is of Type: Theatrical Composers. (As they’ll show up in groups, I’m declaring Types in the plural, but it’s the user’s choice.) If Type is structured like Tag, then the hierarchical search/filter is possible, so with a single Type, Sondheim comes up in searches for Theatrical Composers, Composers, and People.
Presently in Piggydb, if we want to keep information about Sondheim manageable, we have to create sub-groups in the hierarchy like these:
Shows (Stephen Sondheim)
Songs (Stephen Sondheim)
Books (Stephen Sondheim)
The relationship between Sondheim and his works is thus indirect. It becomes very difficult to see connections unless we’ve drawn them explicitly, which detracts from the expressiveness of the database. It becomes difficult to filter. And thus it becomes tempting to create a Sondheim tag, introducing redundancy and overloading the Tag system.
In a model with Type, we can link Sondheim and his works directly. There may be hundreds of fragments associated with Sondheim. But if they take Types (Songs, Books, Shows, Articles, Events), they can be organized into collapsible groups, as Hans Peter was seeking.
We thereby save the overhead of intermediate headers. Moreover, much of the benefit of an associative database comes from its ability to reveal secondary relationships we’ve not explicitly spelled out, and that becomes routine with Fragment Types and Link Types.
Suppose we’d like to know who has collaborated with Sondheim. If we link a group of names to Sondheim, or create a subgroup with collaborators, then we’re telling Piggydb something we’d prefer Piggydb to be telling us. The real collaborators are the individuals who have worked with him on shows and songs. With a model that includes Type, Piggydb can display fragments with two or three degrees of separation from Sondheim, filtered to include only other composers and lyricists, for example. And if Link records also carry a Type, we have a way to describe their role:
Type: Directors
Hal Prince: Company
Jerome Robbins: Gypsy
Arthur Laurents: Anyone Can Whistle
Must stop for the moment, but this should be enough to continue the discussion.
Warmest Regards
Jerome
> Tags work very well as filters, but they describe the fragment itself, not the relationship between fragments. And they can’t group a series of like fragments within a hierarchy. On the other hand, an intermediate fragment cannot describe relationships beyond its own hierarchy.
You summed up my concerns very nicely 😉
> The relationship between Sondheim and his works is thus indirect. It becomes very difficult to see connections unless we’ve drawn them explicitly, which detracts from the expressiveness of the database. It becomes difficult to filter. And thus it becomes tempting to create a Sondheim tag, introducing redundancy and overloading the Tag system.
Again very close to what I described before.
> In a model with Type, we can link Sondheim and his works directly. There may be hundreds of fragments associated with Sondheim. But if they take Types (Songs, Books, Shows, Articles, Events), they can be organized into collapsible groups, as Hans Peter was seeking.
I like your suggestion. It is similar to the ‘additional role’ that I was suggesting for tags, but separating them into ‘types’ might indeed work even better. Also, maybe this can be established within the current framework by giving tags a checkbox that make them behave as ‘types’, although that might complicate the model even further.
Extending ‘types’ to categorize links will take PiggyDB much further in usability. I asked for the option to classify links before as well so I vote for this also 🙂
Jerome, I really like your suggestions. Let’s hear from Daisuke if he is going to run with this.
Hans Peter.
Jerome, thank you for sharing your idea.
As Hans Peter pointed out, Piggydb lacks a feature to describe (categorize/group) relationships between fragments. He also pointed out that the heavily depending on tags will hide how the entities related to each other.
Basically, I’m not against the idea of categorizing the relationships, and actually I’ve been thinking about this for a long time.
Piggydb is not aiming to be a mere ontology or semantic database. A knowledge fragment does not necessarily represent an entity. Thus, it is not that simple to introduce this kind of features while keeping the consistency or integrity of the model.
Before thinking about these issues, I’m not satisfied with how the relationships are presented in the current UI. It kind of puts an implied meaning on the fragment-links. I’m going to fix this issue in V5.1 branch.
Daisuke
Greetings Daisuke
>>Piggydb is not aiming to be a mere ontology or semantic database. A knowledge fragment does not necessarily represent an entity. Thus, it is not that simple to introduce this kind of features while keeping the consistency or integrity of the model.<<
Yep, understood….but I'm sure you can see why our examples would tend to be a bit on the concrete side. Everyone can see the relationship among composers, shows, songs, albums, etc. It's tough to come up with examples that illustrate the subtle gradations and interplay among ideas. But if we were writing an introduction to various theories about the interest rate, we'd have our economists, their schools of thought and their articles, as well as a narrative branch. And there'd be all sorts of valuable information in the half-sibling and grandparent fragments, the peer groups and nearest alternatives. So the same principles would apply.
But there's indeed a problem with too rigid a Type, exactly as you've observed. Fragments have lots of attributes. If some fragments have X as a Type, i.e. a primary tag, and others have X as an ordinary tag, where's the integrity of the group of X-tagged subfragments? It'll be missing some members. So I'll refine the suggestion to make grouping a scoped attribute of the tag, rather than of the fragment.
Suppose we wanted to specify "Songs" and "Shows" as tags that we'd like to see grouped. We could convey this to Piggydb by putting them together in a Fragment that also has the special tags #group_local or #group_global. Of course some subfragments would show up in several groups, but that's why we need to be selective for the view desired. And Piggydb would have to keep track of the subfragments not grouped, and show them individually.
Relationship tagging would work very well in the existing interface. You might create a target in the subfragment's indent area, and be able to drag a single tag to it. Now, under Sondheim, one song would have a relationship tag "Composer" while the next would have a tag "Lyricist". And there's probably no reason why a fragment can't be related in several ways to its immediate subfragment. Multiple links at one tag per link.
I think tag grouping and relationship tagging would be an excellent evolution for the program. Very glad you're mulling on it.
Warmest Regards
Jerome
Hi Jerome,
I think that a tag or category, type essentially represents a relationship between the subject and object. It is not inherent in the object itself. For example, a tag represents the relationship between a user and data (a user regards a fragment as something described in the attached tags).
With this insight in mind, I think your Type idea is less flexible than categorizing relationships. Your aim is to make it easier to define relationships using a primary tag concept, but in exchange for this, any relationships to a typed fragment are forced to have the same category. And it needs workarounds for unexpected situations as you wrote, which complicates the application.
I think also that the model of categories should be distinguished by what type of relations they represent. So simply applying the current tags to the fragment-links would not be a good idea.
And if you consider the relationship categorization only as a way to group relationships (presented as collapsible nodes in the UI, for example), you should think about what is the difference from intermediate fragments.
Best regards,
Daisuke
Hi!
I am currently searching for some app that allows me to note down all kinds of things related to my research. I experimented with piggyDB, but one thing was missing for me: the ability to type Math (Latex). Are there any plans of incorporating this feature?
Or any other suggestions for me?
thanks!
Hi,
I have a plan to extend the wiki formatting, but the priority is not high.
Piggydb allows you to embed images within your content, so how about referring to images of mathematical expressions managed in an external LaTeX system?
Best regards,
Daisuke