Re: Of tags and topics

["Berend van Berkum" <berend van berkum gmail com>]

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