Just finished: One core part of reorganization -- finding large replacable partitial networks. I figured, that might get me rid of those double feed news, as having this functionality available might enable me to sort news by topic. ... Which makes me ponder about wrapping this bit into a rails site. ;-)
Updates: none so far
Showing posts with label MOM SSC framework. Show all posts
Showing posts with label MOM SSC framework. Show all posts
Tuesday, July 31, 2007
Sunday, June 17, 2007
MOM's reorganization could reveal topics/theme complexes
Currently, I am preparing to implement MOM's reorganization capabilities. 
Today, some time amidst of it, I noticed that MOM could provide service already with only the reorganization functionality in place: Based on popular tagging, MOM [actually, its reorganizer] could reveal topics different sources (e.g. flickr photos or blog entries) deal with, unrecognizedly so far. -- The background:
Problem:
I've got lots of papers which are tagged. They deal with several different topics, on and off over time. There might be far later papers dealing with similar topics like any far earlier ones. -- Using the tags alone, doing that task intellectually, I might have a rather hard time: There are too many distinct tags to keep track of.
Approach for solution:
Reorganization could be applied: It might detect clouds of tags that belong together and 'mark' them by pooling them to separate new -- but yet unnamed -- 'tags' (= MOM nodes). That new tag, then, points to every paper the topic the tag represents deals with. -- That reduces the workload to be performed intellectually to find appropriate names for the newly created, first unnamed, tags. And, of course, to tag all those papers beforehand.
Benefit:
That does not only apply for my private issue of getting clear what topic I touched with MOM at what time, but also to any other unordered collection -- e.g. for papers collected in preparation of a diploma thesis..any scientific work, maybe even a law library..any library..all literature ever written.
Updates: none so far
Today, some time amidst of it, I noticed that MOM could provide service already with only the reorganization functionality in place: Based on popular tagging, MOM [actually, its reorganizer] could reveal topics different sources (e.g. flickr photos or blog entries) deal with, unrecognizedly so far. -- The background:Problem:
I've got lots of papers which are tagged. They deal with several different topics, on and off over time. There might be far later papers dealing with similar topics like any far earlier ones. -- Using the tags alone, doing that task intellectually, I might have a rather hard time: There are too many distinct tags to keep track of.
Approach for solution:
Reorganization could be applied: It might detect clouds of tags that belong together and 'mark' them by pooling them to separate new -- but yet unnamed -- 'tags' (= MOM nodes). That new tag, then, points to every paper the topic the tag represents deals with. -- That reduces the workload to be performed intellectually to find appropriate names for the newly created, first unnamed, tags. And, of course, to tag all those papers beforehand.
Benefit:
That does not only apply for my private issue of getting clear what topic I touched with MOM at what time, but also to any other unordered collection -- e.g. for papers collected in preparation of a diploma thesis..any scientific work, maybe even a law library..any library..all literature ever written.
Updates: none so far
Sunday, June 03, 2007
new release: documentation improved, dotty output added
New version is out! It mainly features improved documentation of all of the files of the framework, but also introduced better MOM net output for MOMedgesSet and MOMnet class. For the latter even a simple dotty output method.
See here a sample MOM net created by MOMnet and rendered by dot:
Two layer MOM nets oftenly contain hidden, i.e. not explicit (i.e. implicit) content. To have a generator for them available constitutes the chance to develop a detector for such implicit content and to make it explicit. A mechanism that takes both of these steps is known as reorganizsation. -- Which might become implemented next.
Updates: none so far
See here a sample MOM net created by MOMnet and rendered by dot:
Two layer MOM nets oftenly contain hidden, i.e. not explicit (i.e. implicit) content. To have a generator for them available constitutes the chance to develop a detector for such implicit content and to make it explicit. A mechanism that takes both of these steps is known as reorganizsation. -- Which might become implemented next.Updates: none so far
Friday, May 25, 2007
New version is out!
As before, the version is on gna.org, part of a subversion repository. Quick sum up of the changelog: What changed mostly is MOMnet.rb: Now it is validated and can generate MOM networks.
The option to get MOM networks to be generated relieves the developer to define -- and possibly debug -- MOM networks by his/her own. (I experienced, because of their dual nature -- edges meaning might be given/is given --, MOM networks are harder to debug but pure program code.) Having one -- better: more but one..multiple -- MOM network(s) at hand allows to reorganize the network to make implicit content explicit (marketing speak: "generate new content from yet given one/determine previously unknown content").
Other changes made possible to derive one HomogenousSetDerivatesInfrastructure class from another and inherit the class of the items to be dealed with too. Previously, that class was mentioned in a plain class variable of HomogenousSetDerivatesInfrastructure, which Ruby does not inherit normally. The recent change circumvents that Ruby default behaviour: MOMnet derives from MOMedgesSet, but only the latter becomes initialized to deal with MOMnetEdges only. MOMnet inherits that initialization from MOMnetEdge. -- Previously, there had been a need to tell every derived class explicitly which kind of items it should deal with although a developer would have expected the class to know that because of its anchestry/because its parent was for item class X, hence any child should be like that too. So, the change makes the framework meet that intuitive presumption: Now, children of HomogenousSetDerivatesInfrastructure know the class of the items to deal with.
A minor improvement was to add some output methods to the framework. Additionally, MOMedgesSet now can export to dotty, a graph visualization tool.
Last not least, I extracted changelogs from my local subversion repository for earlier check-ins to the public repository and added them to there too.
Updates: none so far
The option to get MOM networks to be generated relieves the developer to define -- and possibly debug -- MOM networks by his/her own. (I experienced, because of their dual nature -- edges meaning might be given/is given --, MOM networks are harder to debug but pure program code.) Having one -- better: more but one..multiple -- MOM network(s) at hand allows to reorganize the network to make implicit content explicit (marketing speak: "generate new content from yet given one/determine previously unknown content").
Other changes made possible to derive one HomogenousSetDerivatesInfrastructure class from another and inherit the class of the items to be dealed with too. Previously, that class was mentioned in a plain class variable of HomogenousSetDerivatesInfrastructure, which Ruby does not inherit normally. The recent change circumvents that Ruby default behaviour: MOMnet derives from MOMedgesSet, but only the latter becomes initialized to deal with MOMnetEdges only. MOMnet inherits that initialization from MOMnetEdge. -- Previously, there had been a need to tell every derived class explicitly which kind of items it should deal with although a developer would have expected the class to know that because of its anchestry/because its parent was for item class X, hence any child should be like that too. So, the change makes the framework meet that intuitive presumption: Now, children of HomogenousSetDerivatesInfrastructure know the class of the items to deal with.
A minor improvement was to add some output methods to the framework. Additionally, MOMedgesSet now can export to dotty, a graph visualization tool.
Last not least, I extracted changelogs from my local subversion repository for earlier check-ins to the public repository and added them to there too.
Updates: none so far
Sunday, April 08, 2007
upgrades on MOM SSC classes, introduction text
To several of the ruby MOM Simple Set Core classes, I added a demo program which aimed at showing the respect class works/aimed at crashing if there's a bug. Well, actually, the demo programs shall call each method with any possible value (including invalid ones). If the program runs trough, everything is okay; if it doesn't, that means homework, i.e. the class needs to be fixed. Yet a few days ago, I uploaded the upgraded classes to the MOM SSC repository (changelog).
I didn't change the version number, since the moment I want to do this, is when MOMnet.rb is completed also. -- That equals the moment, when all the classes using MOMnetNode and MOMnetConnection work.
Additionally, I took the time to improve (well, actually, replace) the description the goals of the MOM SSC project. I hope, now any passer-by can figure out the idea quite easy.
Updates: none so far
I didn't change the version number, since the moment I want to do this, is when MOMnet.rb is completed also. -- That equals the moment, when all the classes using MOMnetNode and MOMnetConnection work.
Additionally, I took the time to improve (well, actually, replace) the description the goals of the MOM SSC project. I hope, now any passer-by can figure out the idea quite easy.
Updates: none so far
Subscribe to:
Comments (Atom)
