[Debtags-devel] Proposed Debtags goals for Etch

[Enrico Zini]

On Sun, Jul 24, 2005 at 03:47:52PM +0200, Erich Schubert wrote:

> > We are currently separating concepts, such as "colour", from their
> > instances, such as "red, blue".  We are categorising stuff that is so
> Well, not consequentely. Maybe because you can't really do that.
> What is this "audio" thing. Is it a concept (well, audio::mp3,
> audio::ogg are instances of the audio concept!) or is it an instance
> of the works-with concept?

It is both, or possibly more.  If you consider the context of the
works-with facet, then 'audio' is an instance of the works-with concept.
Or it could be the "audio format" concept.  Or it could be the "what do
you do with audio" concept.  Or it could be an instance of the "made-of"
concept.

After the last reorganisation, we chose to make it an instance of the
"works-with" concept.  And we chose that, instead of having an "audio
format" concept, we just put audio formats inside the "works-with"
concept.  And we chose to group them under the "works-with::audio"
instance, to make them easier for users to find.

Of course in doing that we are assuming that the file formats we grouped
under 'audio' will always be used for audio, which is reasonable to
assume.  If in the future that won't be the case (for example, sensors
for some phisical experiment could export sampled data in wav files), we
can always duplicate the same file format somewhere else:
works-with::sampled-data:wav.

A problem will arise as this would go on, because you then wouldn't be
able to look for all packages working with wav, no matter if for audio
or not; or you could, by ORing many tags.


> Thats the real point I'm still picking on: it just doesn't work well
> with only 2 levels, where the first has a special role and a special
> name...

It has a special role and a special name for a reason.  All of which I'm
tired to explain.


> > The one I had before (lots of atomic facets with a flat omogeneous set
> > of tags), where you could reach any needed level of hierarchisation
> > withouth the need of creating the hierarchies in advance.
> At the cost of increasing the number of facets a lot, making them even
> harder to cleanly separate.

Yes, it would increase the number of facets a lot, and no, it wouldn't
make it harder to separate them cleanly as a denser granularity of
facets can capture an group together more omogeneous properties of the
real world.


> > The one we are currently using, where it is indeed useful to group tags
> > inside facets.
> Which isn't vey different from the real "hierarchic tags" approach,
> except that you don't admit it. ;-)

Eric, I'm tired of such jokes of yours.  I'm spending hours (HOURS,
damnit, HOURS, you realise that?) explaining you things in different
ways just to get you to ignore all of my messages and answer with a
nasty comment to a minor part.  I'm seriously considering that my time
would be better employed fixing bugs in debtags.


> I do not find it easy to understand why we don't have a real hierarchy
> in the tags. Everything in computers has hierarchies, starting with
> the file system...

Right, except that hierarchies do not work to model real-world
phenomena.  And that's the reason we don't have a real hierarchy in the
tags.

In order to fit the file formats in the smaller hierarchies we are
having, we have duplicated the tags of the file format properties.
We've basically encoded a dag into a hierarchy, just for simplicity
user-wise.  We could keep doing the same, merging duplicating
hierarchising by having lots of separated tags such as:

  application::editing::text::plain
  application::editing::text::html
  application::viewing::text::html
  utility::editing::text::html
  utility::viewing::text::html
  utility::viewing::text::plain

That'd be a nice hierarchy.  Incidentally, it is already autogenerated
by tagcoll hierarchy, but it needs non-hierarchised data on input unless
you want to maintain all the redundancy by hand.


> > You mean implications?  You can still get them by encoding them in
> > autodebtag.
> No, I'm talking about the UI. About not offering too many choices to
> the user in the UI.
> That is my really big concern without a real hierarchy:
> We already have 51 tags in works-with. Thats too much. Even with
> grouping. Next thing we are going to need another level of grouping,
> and then we *really* do have hierarchies.

We are badly in need of a better interface to select tags.  Because you
can't make a good hierarchy out of tags in many cases.  Give me an
example good hierarchy of the tags in the 'culture' facet, for example.

My current best take is a full-text search à-la "debtags tagsearch".
Or, for searching the archive, a totally different approach like this
one: http://lists.alioth.debian.org/pipermail/debtags-devel/2005-June/000516.html


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico at enricozini.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/debtags-devel/attachments/20050724/a2a468dd/attachment.pgp