Re: Package tags for Debian-Lex

On Tue, Jun 03, 2003 at 02:24:41PM +0800, Jeremy Malcolm wrote:

> Here are some proposed package tags for the Debian-Lex sub-project:

I quite lack the necessary knowledge to summarize your proposals in a
short tag, nor the experience necessary to undertand wether they
represent an atomic, generally valid concept or they can be made by
combining legal-specific tags with other tags already present:

> [Lex] Legal Software : Legal Office Administration

legal::office or "legal, office" ?

> [Lex] Legal Software : Practice Management

legal::practice-management ?

> [Lex] Legal Software : Document Management

Can it be just document-management outside of a "legal" context?  Or
maybe "legal, document-management", with the addition of a
"document-management" tag as well.

> [Lex] Legal Software : Court Administration

legal::court

> [Lex] Legal Software : Legal Research

Could it be expressed by a combination of "legal" and something related
to search engines?

> [Lex] Legal Software : Legal Subjects : Taxation Law

taxation-law

> [Lex] Legal Software : Legal Systems : Common Law

common-law

> [Lex] Legal Software : Legal Systems : Code/Civil Law

civil-law

> [Lex] Legal Software : Legal Systems : Other Legal Systems

What do you mean with "other legal systems"?


I'd suggest that when those tags are specific of debian-lex, you should
consider trying installing a tag patch enabling them in debian-lex
installations (I'm willing to help you in that process).

Instead, with your experience with legal things you could help in
defining and assigning tags to legal-related packages: many of the tags
you proposed could as well be generally valid outside of a debian-lex
environment.


> I am a bit unclear about why Tasks couldn't have been modified to serve
> the purpose of Tags.  Since woody, can't Tasks already do most of what
> Tags do?  If we are supposed to use Tags in preference to Tasks, should
> Tasks be deprecated?

I consider them two completely different things: tasks are used to
install specific groups of packages, while tags are used to give
more structure to the package database.  With tags you enhance the
navigation of the package database, but tags are not involved in
automatic selections of what packages should be installed.


> Are Tags going to be added to the Policy Manual?

We definitely hope so; however, I'd like to wait until some tools start
to make use of them before thinking about policy proposals, so that the
policy could be augmented based on established practice and/or real
problems that need to be solved.

So far, since afaik there is nothing that makes use of tags besides
Erich's Package Browser and my tools, it means that all existing tools
are doing their job without needing a policy change.  I hope the
situation will change soon, though, altough I don't have the time at the
moment to work on patching existing tools to use tags.


> The other question is whether Debian-Lex and the other [sub|meta]-
> projects should add their categories to the main package tags database
> or whether to maintain our own separate and privately-maintained package
> tag databases which we would install into the tags.d directory.  If the
> latter, would the tag package have to be a dependency in any package
> tagged with one of its tags? 

I'd go with the latter, and no, there's no need for such a dependency,
since a package can work perfectly without knowing how it has been
tagged.  The only dependency scheme I could see is this:

Package: debian-lex-tags
Description: Tag patches to introduce debian-lex specific package tags
Depends: debtags
  (this dependancy might even be unneeded, and the package could just
  put the patch there in case debtags gets installed in some future)

Package: debian-lex-common  (or whatever)
Depends: debian-lex-tags

That is, debian-lex brings in its customizations to the tag database, so
that if debtags is installed, the package tags will be smoothly
consistent with the debian-lex flavour of the system.


Ciao,

Enrico

--
GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini <[email protected]>

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

iD8DBQE+31No9LSwzHl+v6sRAijvAJ4gPT0Gd9tEphrN2ZQf8VfJUtXomQCfS/UA
ZzSVYWAz0H4NRO96xofRK3c=
=C8pl
-----END PGP SIGNATURE-----