[Debtags-devel] New version of Debtags stuff uploaded to experimental

[Enrico Zini]

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Fri, May 27, 2005 at 03:56:48PM -0700, Erich Schubert wrote:

> > One problem is that that would mean imposing a rational (and possibly
> > incorrect) choice from the beginning, while the automatic
> > "hierarchization" follows the corpus of tags we have.
> Facets are also a (shallow) hierarchization, that can be incorrect as wel=
l.
> If I see a hardware facet, the existence of a hwtech facet definitely
> confuses me, I would expect that to be inside hardware.

Please, have a read of the Debtags draft paper I posted about yesterday:
there is a bit more of explanation on facets.

Now, the point of facets is not to hierarchise, but to give a specific
and well-defined domain to categories.  There is no hierarchy here.  I
don't want hierarchies.

Faceted categorization is like saying "If I look at what is the use of
this package, I see *editing*".  "If I look at what is its user
interface, I see *a text-mode user interface*".

Facets are "If I look at X"; tags are "I see X".


So, the 'hardware' facet addresses the domain of "what kind of hardware
can be run by this software".  The 'hwtech' addresses the domain of
"specific hardware technology this package provides support for".

Hardware tells you if it's a car, an airplane or a vacuum cleaner;
hwtech tells you what kind of technology it uses, like electric or
diesel engine.  You can have electric and diesel engines inside cars,
airplanes and vacuum cleaners, and you can have theorical books about
physics of electric engines that have nothing to do with the hardware
they are installed in.

Even hardware and hwtech are not so hierarchically related as you seem
to think.  There are currently no examples on the current Debian archive
of hwtech::* without hardware::*, but please consider that it's two
different aspects there. =20

Here's an example:

  Suppose that 5 years from now noone uses CDs anymore, and we have so
  many still around that people start to cut them, bend them and use
  them to build sculptures like they were LEGO bricks.

  Then we could have the package "cdsculpture-designer" tagged with
  "hwtech::cd" but not "hardware::storage", because it doesn't drive any
  hardware device to store anything.

  That day, when cdsculpture-designer kicks in, the Debtags algorithms
  will automatically rearrange the navigation so that hwtech will be
  accessible, say, from "field::art" and not only from inside
  "hardware".

The deal here is that we're not encoding hierarchies anywhere, but we're
just encoding properties of the packages.   The facets serve to clarify
what aspect of the package we're categorizing, and to identify what
aspects of the packages we want to categorise.


Then we have structure.  Structure is not encoded anywere, not even in
the facet-tag relationships, because the facet is just part of the
description of the tag itself.

Structure is generated, for the purpose of analysis, navigation,
whatever.  Have a look at the paper, where I speak about Effective View
Navigation: to provide a nice interface for navigating the packages
using tags, you want to minimise the information per navigation node,
and to provide information trails ("residues" in the paper) sufficient
to find the path to every other destination.

These algorithms induce a structure that looks like a hierarchy if you
see it from debtags-edit menus, but it's a graph instead.  Every tagset
you can select in the filter is a node in this graph, and has paths (one
per every single change you can make to it) leading to other tagsets.
That is used to navigate, and to navigate only.  I try to minimise the
number of outbound edges to make navigation easier.  This, is the
purpose of the algorithms, not to create a hierarchy.

But again, please have a read of the Debtags draft paper I posted about
yesterday. =20

=2E..

Then, if we want to discuss if "hardware" and "hwtech" makes sense to
have as facets, that's a completely different topic.  The whole
technology-related facets need some bit more thinking IMO at the moment.
But first, we need to agree on what a facet really is.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@debian.org>

--C7zPtVaVf+AK4Oqc
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFCmHms9LSwzHl+v6sRAov0AJ4pOAaWqTPzDNsARItSSV7OjJcPWgCfYY72
+5knbllB8cIFeicbRORS7fU=
=laBl
-----END PGP SIGNATURE-----

--C7zPtVaVf+AK4Oqc--