Thank you for raising this issue. While I can see how this feature would be useful, we have no plans to implement it in the foreseeable future. In order to set expectations, we're closing this request now. Thanks again for your idea.

Btw, the need of not letting others than the document owner remove certain labels can be addressed by the add-labels macro, which ensures that if someone removes a label from those listed there it gets re-assigned immediately - so page editing rights are required to be able to remove those.

We definitely need to separate "edits page" et "edit labels" permission

Our organisation would like to separate 'edit labels' permission from 'edit page' permission also.

We use labels + the contentbylabel macro extensively to build navigation lists, but we are concerned that the labels could be accidentally deleted. What we really want is a way to prevent labels from being accidentally deleted. Perhaps a mechanism where a certain labels could be protected?

This can be implemented in 2 stages: in a first stage it's bound to page/news creation, but the final implementation should have an independent set of permissions.

One of our users requested the same as Volker:

"I'd like to request separating the 'edit labels' permission from the 'edit page' permission."

He had an interesting idea for avoiding a whole new permission scheme though:

"If that's not possible, consider associating the 'edit labels' permission with the 'add comment' permission, rather than 'edit pages'"

Aside from limiting who can assign labels, it would also be useful to be able to grant labelling privilege without granting page editing privilege - e.g. when we write a KB-article on our doc-Wiki we may not think of all the labels that end users (clients) are associating with the article and it may thus be harder than necessary to find. If they could simply add the label themselves that issue would be solved.

Personal labels don't help here, we need clients to be able to add a label that will allow other clients to find the page better - we want a community-based tagging approach, and we do let them comment (so the suggestion to tie labeling permission to commenting permission would work for us) but at this stage we don't want to let the community edit pages in the main KB (they have a separate space where they can contribute articles).

In additon to restricting the use of labels in general for a given page, what I would like to see is a permission setting on a label by label basis. For example, if there is a label 'delete-me' that is used by moderators to flag pages that will be automatically deleted by some process, an organization may want to limit the use of that specific label by space and/or by user. LIkewise if there is a label called 'featured-article', perhaps only a fraction of the users should be permitted to add or remove this label. Labels should, however, be wide-open by default. unless specifically restricted. I will post this as a separate but related feature request.

In the context of Brian Thomas's very well thought out proposal for recording 'according to whom', what this would translate to would be that anyone could create a given label (say 'delete-me'), but only certain people would be given the trust / authority that allowed that label to be used for everyone with macros such as content-by-label, metadata-report, checklist or a 'page deletion daemon'.

(the proposal of label stewardship has now been pitched separately as CONF-9742)

This issue brings up the question of what labels are, and how they are intended to be used.

Two ways of labeling come to mind: those intended primarily to benefit the owners of a document, and those that benefit the users.

The first sort are used extensively in access-control settings, to apply specific rights requirements or classifications to documents, thus designating the classes of users who can access the documents for various purposes. They may thus be thought of as properties of a document itself, and applying or removing them is properly under the control of the document's owners, since changing them is effectively changing the document itself. This mode of labeling is relatively rare in practice, except in military and other government applications in organizations characterized by centralized, hierarchical control, and its main characteristic is that the labels carry the authority of the documents' custodians.

Much more popular today are the second sort, probably because any given document typically has many more users than owners or custodians. They are generally called "tags", and exist so that users can make associations, meaningful to themselves, of documents to concepts or categories, primarily for the purpose of finding them quickly, or reminding them of their content or their opinion of them, without having to open and read them.

A general model encompassing both types is a very simple one: in both cases, a document D is associated with a label L by party P. The first type has controls built in to support the assumption that P has some authority granted to it by the custodians of D regarding L; the second (as used by del.icio.us et al.) only supports the assumption that all associations of labels and documents are identified as to the party that made them.

Thus the first can be expressed as a specialization of the second, so that building the second, which supports the more popular usage, will also be a major step toward the first.

To get concrete, then: The one thing currently missing from the labeling system that would be required for either case is the identification of the labeler. With this, you get not only "what labels are associated with this content?" but also "according to whom?". This, then, requires no controls on the posting of labels, and transfers control to the viewing side, where labels not placed by parties trusted by the viewer can be ignored at the viewer's discretion.

This plus private labels (currently identified by prefixing with "my:") can be robustly implemented by means of user preferences specifying users and/or groups whose labels are to be regarded (or ignored) by default, and also users and/or groups by whom the user's own labels may be viewed. Both categories could also characterize the affected labels by value or regular expression or (if labels are really made robust) by XQuery expressions (see CONF-8629).

I agree, I think that a lot of organisations using the wiki as a company-wide intranet could benefit from this feature.