[Debtags-devel] Proposed Debtags goals for Etch

[Enrico Zini]

On Sun, Jul 24, 2005 at 03:11:57AM +0200, Erich Schubert wrote:

> Forget about the web interface, I've been admitting that it
> despeartely needs a rewrite for more than a year. ;-) I agree that our
> notion of facets and tags is very useful to make a better user
> interface, too.

Thanks.


> > You don't mix axes with values.  They are different.  Axes define a
> > direction; values define a position.
> Well, I'm a mathematician. Axes don't really exist. But axes is the
> wrong term anyway, since we don't have a continuous value anyway. ;-)
> I'd more call it a domain or something like that. I refuse to call
> anything an axis unless you have a ring to value items on.

Could you please get out of the mathematician shoes and try to talk with
people who are not?  I'm doing my best to explain things, many times, in
different ways, and it's very depressing and annoying to get answered
with jargon nitpicking.


> We have many domains that do not apply to all packages anyway.
> What is the culture of mpg123? Is works-with::audio more or less than
> works-with::text?

Why do you need facets to apply to every package?  And why do you need
to sort tags?  Are you just nitpicking again because I used the axis
metaphore, or do you really have a use for them?

We're not trying to categorise abstract entities, but software whose
meaning changes according to the usage environment and to user's needs,
and which is connected to real-world objects and processes.  This is
likely to either break any simple formalisation we can come up with, or
to require an overly complicated formalisation to get it right.  More
shortly put, we either approximate, or we create a system that noone can
to use.


> In my point of view, you have to think of them as sets.
> You have a set of packages that "works-with::audio". A subset of that
> is the set of packages that "works-with::audio::mp3". And the set of
> packages that "works-with::*" is just a superset of that: the set of
> packages that is classifyable by the data they work with.
> That is a *very* consistent point of view.

It is, but where would it lead us?  Who would get it right besides you,
maybe me, and another 3 or 4 people who've been into this topic for a
while?

Another nicely consistent point of view was my previous breaking down
tags into flat groups of omogeneous ones, and let the nature of packages
merge things together.  That didn't lead us very far either; maybe
because I was the only one with an idea of the algorithms to pull
everything together, or because these mini-facets have not been clearly
crafted.  Too bad.

Now we have a chance of having a decent tradeoff: we can establish some
general facets of packages we're interested in, and try to describe them
as best as we can.  That's easy to understand and to work with, and
consistent to some (IMO) reasonable extent.


> In your case, "works-with" by itself doesn't really exist. It's a
> group of tags basically. works-with::audio is a group of tags, too.
> But it's not a facet. Thats inconsistent! And if you say
> "works-with::audio" is a tag, and ...-mp3 is a separate tag, there is
> no reason to treat works-with::audio somehow special-

It's funny to see that this approach looks a lot like my previous
approach, where you would have had 'works-with::audio' (a tag) which, if
it suggests further properties of packages, gets an associated facet of
'audio-format::{ogg,mp3,wav,...}'.

And if you wanted to tag "all the packages that work with something",
you would have made another conceptual step in understanding what is
that property and then created another facet such as (I improvise)
"behaviour::{works-with-something, entertains-the-audience,
provides-generic-functions, sits-there-and-thinks}".


But going back to the tradeoff we seem to have made now, I do really
care to keep the little of distinctions that we have, as they help us,
and people joining the group later, think together.

We are currently separating concepts, such as "colour", from their
instances, such as "red, blue".  We are categorising stuff that is so
diverse that not all properties apply.  Suppose that you're categorising
both cars and car building practices: you are not categorising the
colour of cars because you can't assign a colour to "mounting the
steering wheel"?  Or would you instead mix categories like "red",
"color" and "black" in the same pot, hoping that your engineers as well
as the car dealers will understand?

Maybe two years from now Debtags will become so popular that the need
will arise for something more formalised, in order to support whatever
new needs will come to life.  And we will refactor the system to reach
that level of formalisation.  But if we try to be perfect right from
now, we will probably never get to that point.


> Fortunately, for the information we are interested in, there is no
> difference between our points of view, so we can work together just
> fine. ;-) But I took this opportunity to remind you that not everyone
> agrees with your "there are facets, and below that there are tags"
> view. And you have to admit that a second level (and maybe sometimes a
> third) is useful.

We have 3 approaches here:

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.

The one you have, where you define many nested sets, and where
hierarchisation is indeed useful.

The one we are currently using, where it is indeed useful to group tags
inside facets.

The last one is probably the best for where we are now.  It's
expressive, and easy to understand.  It gives us a chance of taking more
of the Debian community with us as we grow in understanding.  Maybe
it'll prove good enough; if not, we have not one, but two backup plans
:)


> I also liked the "old" approach of putting certain constraints upon
> the branching of the UI very much. This was somehow lost now, with all
> the facet-tag things.

You mean implications?  You can still get them by encoding them in
autodebtag.

I removed them mainly because I wanted to index the tag database as it
comes from the server, without needing to post-process it every time on
program load.


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/5e8b2b21/attachment.pgp