[Debtags-devel] I want a X to Y Z

[Enrico Zini]

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

On Thu, Jun 09, 2005 at 12:49:47PM +0100, Justin B Rye wrote:

> Enrico Zini wrote:
> (I've been tagging things and wondering
> -- why is uitoolkit separate from interface?
> -- why is media separate from format?

Interface is the kind of interface, while uitoolkit is the tecnology
used to create it.  Same idea is with media.

One could think of uitoolkit as a refinement of interface (and of format
as a refinement of media), however there can be cases in which uitoolkit
happens without interface and format without media, such as "the
precompiler used for QT (which has a commandline interface but it's used
to develop for QT) or the GTK libraries (which have no user interface
but they are indeed related to GTK).

Same stands with media and format: I can have user documentation about
PNG which is not a raster image.

Finally, user-wise it's quite nice to allow people to search for a
certain kind of interface regardless of its technicalities, or to look
for something to work with a specific kind of media regardless of the
format.


> -- why is data separate from role?

That is less clear.  Role was a sort of catch-all for tags telling what
a package roughly is, but it's never been really well defined.

Data was intended for software which is not programs, to tell what kind
of data it is; that's as well another area noone's bee very sure so far.


> ...but I can come back to questions like these some other day)

I look forward to it!


> > So, I was considering some example such phrases we could compose:
> >   I want a program to edit text
> >   I want a program to view raster images
> >   I want a library to edit raster images
> (By the way, "raster images" is a good watertight category, but it's
> not a term ordinary users are likely to set out looking for.  I
> suppose you could arrange for "porn" to be a synonym...)=20

I share the feeling.  Maybe pictures could be used for rasterimage and
drawings for vector images, at least in the description.  For the tag
itself (which should usually be hidden from the user) it probably makes
sense to keep the watertight technical term.


> >   I want an applet to search dictionaries
> > Question 1: Can you point out examples with more tricky cases?
> Ys where Z isn't a data type; "I want an X11 app to monitor
> processes" (gps, tkps...).  Or where it's a rare and obscure one
> ("to download webcomics", "to convert TNEF attachments").

About 'processes': interesting.  It could go in 'media' if we define it
as 'things a program manipulates', but one doesn't think 'processes' as
some sort of media.  That seems to call for an extension of 'media' (to
include 'processes') and possibly a rename ('domain'?  'concern'?
'realm'? 'works-with'? 'specialty'? 'territory'?  'specialty' seems to
be the best in the list for me).

  I'm tempted to do this!


Now, about webcomics or TNEF attachments, I'd like to keep rare and
obscure things into domain-specific facets (such as 'accessibility')
that can offer a selection of tags with an insider jargon.  That way we
avoid taking specific jargon and put it into a general area where it
would have a hard time preserving its meaning.


> > Question 2: Can you point out examples in which such a phrase will be
> >             absurd?
> Intransitive Ys, like "timekeeping" or "dialing", which can lead to
> searches like "I want a commandline app for chatting dictionaries".

This one is easy, if the interface only shows the tags that are actually
present.  That way, the moment you'd select "chatting" you are likely
not to find "dictionaries" among the media anymore, while if you select
"dictionaries" first, you are likely not to find "chatting" among the
actions.

Now, if I think more about it, there can always be a "spellchecker for
gaim" that has both tags and screws up what I just said.




> A trickier variant is "converting", where you'd naturally want to
> search for both input and output Zs.

With this one can always put one of the two and look at the list of
packages coming out.  The goal is not to offer perfect matches, but to
substantially narrow the search domain.

There's been some discussion about adding some predicate into the tag
mix, though.  I personally believe that the results are not worth the
effort[1] and I'm not going to implement it, but I'm happy if someone
else (not you, not you, I know :) wants to give it a try.


Ciao,

Enrico


[1]
As in: if with normal tags I can narrow down a search to 20 packages, do
I really need a complex and hard-to-maintain technology to further
refine that down to 10, or isn't it easier to just go through those 20
packages to see which is the one I need?  And who'd enter those
predicate data with a decent precision, when we're having problems
already tagging packages with the current approach?
--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <enrico@enricozini.org>

--DocE+STaALJfprDB
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)

iD8DBQFCqEK89LSwzHl+v6sRAkAeAJ46JcGpanKu90U9S2NnSUi+f3z9fgCffOjp
3cofClW9kVAFWzHsvDmloAA=
=SOsP
-----END PGP SIGNATURE-----

--DocE+STaALJfprDB--