On 8/20/07, Yen-Ju Chen <[EMAIL PROTECTED]> wrote: > On 8/20/07, Quentin Mathé <[EMAIL PROTECTED]> wrote: > > Hi everybody, > > > > Here is a lengthy mail to describe a proposal about a Tag Object > > System which would be implemented by an improved version of > > OrganizeKit playing the role of CoreObject name service. It is > > inspired by OrganizeKit itself and a discussion on SILC with David. > > One thing I cannot decide is how to store the data on file system. > The current implementation is in a single property list. > If you want to use it for everything, database may be better, > but will be slightly slow. > On the other hand, database ususally provides machenism for > transaction while property list doesn't. > So that is the only thing I am concerned.
This has been mentioned before, I guess. http://www.dekorte.com/projects/opensource/tagdb/ We can seriously consider it as a backend of OrganizeKit instead of property list if we plan to use it for system-wide tag. I never really look at it, but two advantages I see: (1) in-memory search, which is the reason OrganizeKit use property list. (2) transaction using qdbm, which is exact what OrganizeKit lacks now. Yen-Ju > > Yen-Ju > > > > > Yen-Ju has already discussed some of these ideas when he introduced > > OrganizeKit. Here are links to OrganizeKit explanations: > > - README: <http://svn.gna.org/viewcvs/etoile/trunk/Etoile/Frameworks/ > > OrganizeKit/README?rev=2249&view=auto> > > - <https://mail.gna.org/public/etoile-discuss/2007-05/msg00063.html> > > - <https://mail.gna.org/public/etoile-discuss/2007-05/msg00065.html> > > (only the beginning of the mail) > > > > I think OrganizeKit offers a tag-based model which would work far > > better than "basic" tag-based model. In "basic" tag-based model, tags > > are only keyword labels. In OrganizeKit, tags are first-class > > objects. This brings organizational features similar to hierarchy (at > > UI level) without the rigidity of hierarchies. In other words, it > > provides some sort of spatiality over "basic" tag-based model. In > > this model a tag is in fact a group which can contain other objects, > > thereby you can organize your objects into "hierarchy" of groups and > > subgroups if you want to. > > > > The set of rules below describes a way to extend OrganizeKit model to > > integrate Projects and Documents. Instead of having OrganizeKit store/ > > library insulated from each other, we could add the possibility to > > reference other root groups (from other stores/libraries) and we > > could treat both Projects and Documents as stores/libraries. Sharing > > between stores/libraries would be made user-friendly by implementing > > a retain count mechanism. > > iirc OrganizeKit hasn't no such cross store reference support. Yen- > > Ju, can you confirm? > > > > Below I will use 'contain' when 'reference' would more accurate. > > > > 1) Everything is an Object > > > > 2) Some Objects are known as Group Objects: > > - Tags/Groups (Groups is OrganizeKit terminology) > > - Documents > > - Projects > > > > 3) Documents and Projects are two subtypes of Tag/Groups > > > > 4) Tags/Groups and Projects can contain any Objects > > > > 5) Documents can contain any Objects except Projects and Tags/Groups > > > > Implicit rule: > > 3, 4, 5) Group Objects can contain objects of their own types > > > > 6) All Objects have a retain count except Projects > > > > 7) Objects (matching rule 6) are retained by all Group Objects except > > Tags > > > > 8) An object retain count is incremented when it is added to a Group > > Object (matching rule 7) > > > > 9) An object retain count is decremented when it is removed from a > > Group Object (matching rule 7) > > > > 10) Objects are created with a retain count equals to 0 > > > > 10) Objects are deleted when their retain count is equal to 0 (more > > in comments about 11)) > > > > 10) The user visible root object is an arbitrary Project > > > > 11) All Group Objects (except Documents and Projects?) are > > automatically referenced by a special Group Object named "tag" which > > lists them all > > > > For 11), Group Objects could be referenced weakly so when no objects > > use a tag anymore, the tag simply disappears. In other words, Groups > > Objects would released when their retain count is 1. That's probably > > not wished for Projects though. > > A side-effect of 11) is that tagging an object with "cool" would > > create the following two level "hierarchy": tag -> cool -> myObject. > > > > Photo, Music, Contacts etc Libraries would be bound to a tag but > > wouldn't retain their objects (this is the role of Projects). We know > > a tag is a group, so each Library is a group too with the possibility > > to contain subgroup "hierarchy" like Playlists, Photo collections. > > For example, the Photo Library would be bound to "photo". At File > > System level, OrganizeKit can store them in a completely different > > way (in a folder hierarchy based dates for example). Photo Manager > > may offer the possibility to create multiple libraries at File System > > level by binding the initially created library to a subgroup of > > "photo" rather than "photo" itself. That would allow to separate > > professional photos from personal ones at File System level (useful > > when working outside of Étoilé). > > > > The retain count ensures plays the role of spatiality in a desktop > > environment. For this tag-based object system, spatiality is replaced > > by referential stability in Project and Document: > > --> Removing an object/element in a project or a document deletes the > > object/element only if no other projects or documents uses it. > > --> Removing a project deletes objects/elements in it only if they > > aren't retained by any other Projects or Documents. > > > > I have the feeling a model alike (which adds Groups and retained > > Objects) could work well unlike a "basic" tag-based file system which > > would miss some basic landmarks playing the role of spatiality in a > > usual desktop environment. Missing stable nodes would translate into > > accidental deletions because you would always have to be careful of > > existing owners of objects/elements. It would be like using a file > > system where all symbolic links are replaced by hard links. > > > > From my own subjective experience, my mind seems to be able work in > > a purely associative way, but it cannot handle a purely associative > > model without some referential stability playing a role similar to > > the external world in my daily life (when I'm away from the > > computer :-). > > > > For rule 9), this comes from the fact Projects are organized here in > > a graph and not in a tree. I think it could paradoxically make > > Project nesting quite usable at UI level by minimizing hard to reach > > Project leaves (located far away from the root Project). Each project > > would tend to have a higher number references on it. > > > > As a last note, imho metadatas should be handled exactly like tags > > (well, the reverse would be more accurate :-) because tags are just a > > kind of metadatas. It could easily be included later by adding two or > > three rules I think, but it's surely not worth the complexity for now. > > > > Cheers, > > Quentin. > > > > > > _______________________________________________ > > Etoile-dev mailing list > > [email protected] > > https://mail.gna.org/listinfo/etoile-dev > > > _______________________________________________ Etoile-dev mailing list [email protected] https://mail.gna.org/listinfo/etoile-dev
