Hi Peter, I think I missed it with my earlier reply, so excuse the noise. I gather now that the effort is to introduce tags into Ephy while keeping the Topics? (I had already accepted that Topics == tags).
Still, as I wrote, I don't think these definitions quite fit. Tags can be anything the user wants, not just properties or keywords. Since this is the way tags work, it would be mistake to seperate these things in Ephy. Not that Ephy cannot introduce some class of tags that are to be regarded as topics, but it shouldn't force seperation. I think this would get messy when you start imporing/exporting. Now if you look at it as a usecase and focus on usability, the definition are more fitting. If the WIMP userinterface is going to use tags it would easily get bloated, so introducing topics (as you define them) there makes sense to me. (Is this the point of the discussion?) But this might be accomplised by renaming Topic to Tag, and by introducing another dialog/feature to manage a new kind of Topic, which is nothing more than a special tag (one which the user likes to use when organizing his stuff). Ephy does already deal with the tag bloat by this 'multiple access paths' thing. I think it's based on frequency and I think I like the structure it infers from a flat list. But as you state on your site, this might be too restrictive for some users. To offer an altenative one could structure his own hiearchy with the tags he deems relevant, tags you might call Topics now. Just don't make any assumptions on what tags are. People use them for all kinds of things including keywords, categories, topics, properties, etc., and this is the flexibility they offer. > > As for namespaces, I'm trying to avoid them. :) > > They're unavoidable if you want to do really cool things like reasoning and > ontology-to-ontology mapping. The semantic web is just steps away... I agree. But at first I think this only means that tags should be managed per user. As I wrote earlier, they are personal and could mean different things to different users (eg 'mouse' or 'internet') so this makes sense. (And on export or publish the user could indicate what the namespace is, eg http://tags.mydomain.com/{tag}, this could be important when integrating into a more advanced resource organizer, but it's not in the scope of any 'libtag' I think) A triple store could be a nice idea for Topaz, or perhaps a more advanced filesystem is what needed there (is ReiserFS making any progress in this?). But a libtag for storing and managing tags should be much simpler (an probably faster) since the schema is fixed (say, a dictionary like 'resource identifier':['tag',]). Also this makes it more accessible to other developers. hth, Berend -- web, http://dotmpe.com email, berend:dotmpe.com irc, berend/mpe at irc.oftc.net
_______________________________________________ epiphany-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/epiphany-list
