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