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. 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
