Faceted tags

Thu, 8 Apr 2004 18:22:13 +0100

On Wed, Apr 07, 2004 at 09:27:21PM +0200, Erich Schubert wrote:

> >   devel:: (supports the goal of development)
> >   langdevel:: (supports looking for tools specific to a given language)
> I don't understand this distinction.

Basically, devel shows the kind of tool while langdevel shows the
supported language.

Some examples of devel:
  devel::bugtracker, devel::rcs, devel::code-generator,
  devel::ui-builder, devel::compiler, devel::debugger,
  devel::interpreter

Some examples of langdevel:
  langdevel::ada, langdevel::c, langdevel::java, langdevel::lisp,
  langdevel::ml, langdevel::objc, langdevel::perl, langdevel::php,
  langdevel::python

So, if you code in ada, you look at langdevel::ada and then see what
devels:: are available to see what kind of tools you have available. 

Instead, if you want to see what kind of compilers are in Debian, you
choose devel::compiler and see what languages you can compile.

> >   media:: (supports looking for software working with a media of interest) 
> >   tech:: (supports looking for specific technology)
> Isn't media some kind of tech itself?
> i'd suggest using tech::media:: then.

No, not really: media is generic.  In real life, think of media like
"paper" and "magnetic tape" and of technology like
"lito-offset"/"laser-print" and "VCR"/"DAT".

Some examples of media:
  media::audio, media::rasterimage, media::vectorgraphics,
  media::ascii-art, media::plaintext, media::textdocument,
  media::spreadsheet, media::video, media::font, media::webpage

You use media:: when you don't care about technology.  For example, if I
want to do vector graphics, I just choose media::vectorgraphics.

> >   suite:: (allows to differentiate among all the element that compose
> >           big pieces of software)
> Not having looked at your data i find this hard to understand.
> suite::wordprocessor ? What is this good for?

No, no: it's like suite::gnome, suite::openoffice, suite::zope,
suite::xmms.

> >   interface:: (allows to choose the interaction method)
> >     (actually, I don't think interface::3d belongs there, and I think
> >     that that "3d" should be defined better.  Maybe by creating specific
> >     tags under "tech::", like "tech::vrml", "tech::opengl"...)
> 
> Well, you can think of it like the following:
> daemons  (logrotate etc.) don't have a real interface
> cli apps have a kind of "linear" interface (a string.)
> x11 apps usually have 2d interface
> there a couple of apps coming which have a spatial interface.
> This can be things like a 3d window manager; or an opengl pool game.
> Such an application can be unuseable for some people, which might prefer
> apps with a "voice" interface.
> Servers are hard to place here; usually they are daemons (for the
> administrator) and the clients are x11 etc.

I tend to differentiate "server" and "daemon": "daemon" is a program
without interface, while "server" is something providing some service to
clients.  For example, we can have a "daemon" which is not a server, and
maybe just samples data and writes them to disk.

You convinced me: "daemon" belongs to "interface::".  "client" and
"server" don't.

> >   x11:: (nice, clean distinction from the x11 point of view)
> which would be? technical aspects of x11 like window managers?
> that should go into tech::x11:: IMHO.

The full x11:: tag list I have so far is:

  Tag: x11::display-manager
  Tag: x11::window-manager
  Tag: x11::xserver
  Tag: x11::screensaver
  Tag: x11::terminal
  Tag: x11::font
  Tag: x11::libraries
  Tag: x11::application

I think of it more like packages as seen by Mr. X11 than something
specific to some technology, that's why I put it outside of tech.
Also, I think it's self-contained and coherent enough to stand alone. 

Technologies involved here could be Type1 and TTF (for fonts), XRender
and other X11 extensions (for libraries) and maybe not much more.

We could see that the X11 protocol is a technology in itself, but I
think it's useless to cathegorize it and I'd leave it out.  If we'll
later want to bring it in, however, we could always add tech::x11 to any
package that has some x11:: tag.

> > I don't like so far:
> >   role: I lack the cognitive structure to find out the name for
> > 	the point of view under which an application is a client or a
> > 	server.  "daemon" is another thing so far I can't assign a point
> > 	of view (maybe "interface", as a daemon is something that has no
> > 	interface?  Uhm...  it could be)
> The reason i added both "daemon" and "server" is that for example the
> gnocatan server has a GTK UI; whereas my cpufreq daemon has no interface
> but certainly isn't a server.
> client, server, proxy, browser, viewer - these roles are similar to the
> use item. We need to sort that out.

Definitely.  Actually, use::server could even make sense.  And maybe
also use::client, as I may look for something that can be used as a
"client" for something.  I'd say let's put them in the "use::"
facet/namespace!

> >   data: the intent was to categorize non-software content, as Debian now
> >         contains manuals, books, artwork, and this part could be
> > 	expanded (I plan to package a kitchen recipe collection, for
> > 	example).  However, the effort so far didn't go very far and
> > 	needs more thinking, de-constructing and clarification of ideas
> > 	:)
> well, we should tag these anyway. This is also to mark packages which
> don't contain applications but their (arch-independant) support data
> files.

Agreed.  There's nothing wrong in starting with a not-well-defined
facet/namespace: at least we know where to work next :)

About -data packages, I was thinking of putting them under
special::package-data, as they're not really useable by anyone except
their package.  When they get generally useable (like a clipart, or some
fonts), then I'd say let's take out "special::package-data" and move
them under data::something.

> >   platform: just "laptop" and "embedded"?  Uhm... it's a point of view
> >         from which I can't see very much, but a point of view I see
> > 	a reason for
> well, there's OPIE, which IMHO is different from regular embedded linux
> and laptop use. You could also add "server-machine" and "desktop" here.

"server-machine" and "desktop" are tricky, as someone would like to have
openoffice in his servers (ugh!) and apache in his desktop PC.

Maybe we could ditch platform:: and just use hardware::laptop and
hardware::embedded.

About "desktop", I'd leave it to be handled in a special facet/namespace
handled by the debian-desktop people.

I almost forgot to talk about facets/namespaces that could be maintained by
corresponding Custom Debian team: I think this'd be so great!

Some examples:

Facet: junior
Description: [Junior] Applications recommended for younger users
 (it could be argued that all junior apps should be games, and this no
  junior::games should make sense)
 Handled by Debian-Jr people
Tag: junior::toy
Tag: junior::paint
Tag: junior::learn

Facet: educational
Description: [Edu] Educational Software
 Handled by Debian-Edu people
Tag: <TBD>

Facet: non-profit
Description: [NP] Non-profit/NGO related software
 Handled by Debian-NonProfit people
Tag: non-profit::fundraising
Tag: non-profit::publishing
Tag: non-profit::membership

> > This is a problem I recognize, too.  I see it only arising inside facets
> > with more than 10/15 tags, and more like a problem of how to organize
> > tags inside a facet.
> Facets like the tech:: or use:: facet will grow quite big i fear.
> And actually that is okay for me, if we force the tags to keep that
> structure. (which we did previously with implications)

Agreed, then.

I'll start coding in libtagcoll some tag-hierarchy management infrastructure to
enable that in applications.

> > Is there the University of Urbino involved in that?  I know they are
> > planning to start an Information Architecture course there, which is
> > exactly the topic we're moving in here.
> I havn't seen them on the list, but maybe they'll join. Also the web
> pages are in the process of being built.
> http://www.pms.ifi.lmu.de/rewerse/participants/

Thanks: I'll look into that.

Ciao,

Enrico

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