Re: Of tags and topics

Hi Berend,

Actually, my aim is to define tags and topics so that we can:
      * address different use-cases with each one
      * realise that they *are* different, though overlapping
      * determine the appropriate time for application of each
      * design standard user interfaces based on that

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

In my definitions:
      * Tags are global. They are things which are factual about the
        object. They provide a way for people to write down and share
        simple "atoms" of metadata.
      * Topics are local. They are things which describe how the user
        associates with the object in his mind. They tell the computer
        how to present the object to *this* particular user.

Note that in the Nautilus/leaftag discussions I saw they were saying how
they would store the tags in the metadata for each file, and that they'd
have to create a separate metadata tag for each user. To me that seems
silly. It seems better to say "tags are global and they are facts" and
use just one shared metadata, and then have "topics are for the user".

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

Given the above definitions, I don't think we can say that a topic is a
special kind of tag. "Favourite" is a topic, but not a tag.

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

What I'm trying to do is take this notion of "tags can be *anything*"
and split it into "tags" and "topics", where "tags" are global and must
therefore (by definition) be facts, and "topics" are determined by the
user to suit their own thoughts. Don't complain that I'm limiting the
notion of "tags" - I'm just replacing your existing notion of "tags can
be anything" with "topics" and "tags" with a simple separation between
the two that leads to different usecases.

> 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{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)

We seem to be getting closer here. :) Perhaps I should just declare:
      * Topics = Personal Tags
      * Tags = Global Tags

Basically I want to take the world of "tags" as you understand it and
split it right down the middle, into "personal" and "global". I've
called "personal" stuff "topics" and "global" stuff just got called

Let's see if anyone swallows my latest attempt. ;)

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]