In Drupal, the tagging feature is achieved with a combination of widgets and permissions on taxonomy term form elements. Tagging so far has been an autocomplete widget and some function that creates new terms when necessary. Tagging and controlled vocabularies have co-existed in taxonomy.module because both have a need for an administrative UI and both need to do pretty much the same things in response to node operations.

The hierarchical listing of terms is not helpful for managing tags, and other interfaces could be more useful. (Is there any feedback from usability testing on managing huge massive behemoth collections of tags?)

Once we've ported terms and term-node relationships to Field API, the coexistence of tagging and controlled vocabularies in taxonomy.module begins only to be justified by legacy.

For Drupal 7, the goal is that term fields can have a variety of widgets including an (as of yet unported) autocomplete widget, select elements, radio button and checkbox elements. This means that we can get the widget we want for the field instance of a vocabulary. We won't need to choose "tagging" as a vocabulary setting simply because we need an autocomplete widget. It would be nice to develop widgets that allow users to add new terms to a vocabulary if they've permission, and this could also be dissociated from the "tagging" vocabulary setting.

So then what is tagging in Drupal 7?

What are the benefits to maintaining multiple no-namespace, user generated tagging vocabularies on the same drupal site?

What kind of foundation can we build to help give contrib modules a good foundation? OpenCalais, Yahoo Terms and potentially other modules are tagging modules.

Are there any other interesting ideas worth considering for Drupal 7 tags? Triple tags, machine tags, hashtags, auto tags, reader tags, author tags. If people want to develop contrib modules for this kind of metadata, what would benefit the maintainers of these modules?

Should we put synonym collapsing into core for tags?

What kind of UI suits people who manage tag collections? I would imagine that it's more like the string translation UI than it is like the current vocabulary admin UI.

Comments

Anonymous’s picture

This issue should also be read in light of #490916: Add a concept URI field to taxonomy terms, which illustrates some of the need with RDF going into core.

Xano’s picture

+1 for synonym collapse in core.

Using select elements and autocomplete textfields as term selectors have been part of Taxonomy for a long time. Although tagging isn't necessarily a feature of taxonomy (note the lowercase) I feel it is a great addition that requires only little code and should continue to exist in Drupal core as an optional widget for selecting (and possibly creating) terms. A new use case for the autocomplete widget would be to use it as a means to quickly add new predefined tags via the administration pages. Bottom line: I vote for a default autocomplete widget in core.

As long as we make widgets pluggable and selectable, we can ship any widgets with Taxonomy we want. Tagging will no longer be a setting for a vocabulary, but rather a field's widget type. Basically widgets define how users select and possibly add terms from and to a vocabulary.

IncrediblyKenzi’s picture

In creating the autotagging module I had thought about this approach as well, but given that all taxonomies are equal in D<7, we opted for a "just add to what's there" kind of approach.

Being able to specify plugins / widgets for taxonomy selection or insertion is an interesting idea, but how useful beyond a few select cases (I'm thinking hierarchical select widget, for example)?

The notion of how taxonomies are defined and architected is more interesting however: For example, how to define relationships between taxonomies? I'm also curious to see if anyone had thought of any ontological mapping (e.g. adding a term "cats" if other tags include "siamese," "himalayan," "tabby," and/or "russian blue"). There's a WHOLE TON of things that a plugin system for taxonomic data structures offers.

Open to hearing what everyone else thinks.

Anonymous’s picture

acstewart:

The widget offerings are simply part of the deal. We have to be able to insert new terms (tags) from some at least one proposed widget (autocomplete textfield similar to D6 tags), and Field API's design means this should work for other widgets. It really can't be avoided.

If I'm understanding your second point (relationships between taxonomies [vocabularies?]) then I think this is a fundamental issue as well that differentiates "tagging" from the controlled vocabulary. Controlled vocabularies are supposed to be a kind of ontological "whole" whereas tagging is sort of dynamic. Tagging "vocabularies" (not the best word for them) are usually/always developed in the context of other content on the site. Initiatives like http://commontag.org/ and http://tagthe.net/ point in the direction of either breaking out of our separate tag "silos" or at least mixing our individual buckets a little more.

The prevalence of autotagging services means we'll probably keep the possibility of multiple tagging vocabularies (or buckets?) in Drupal. Though I think it's important to understand usability issues related to tagging, and I simply have no idea about this. If we want users to think about relationships among tags or relationships between their site's tags and objective RDF concepts, having multiple human-generated tagging vocabularies on the site (i.e. not generated from a web service like Calais or Yahoo Terms) doesn't make sense. So I think it could be possible to answer "I want my site to have this thing called tagging like I see on Flickr" with the click of a checkbox and maybe a few more (to limit down the kinds of content). Meanwhile, autotagging modules can create their vocabularies as needed.

Scor has already provided an example and proposal for linking terms to commontag.org with a ctag:means URI field. One way to develop relationships among tagging vocabularies on a site is to link to external RDF concepts. If tag "X" in vocab 1 and tag "Y" in vocab 2 both mean U2 (http://rdf.freebase.com/ns/en.u2), then your Drupal site can assume that tag "X" in vocab 1 is the same as tag "Y" in vocab 2.

Do we also need to maintain relationships among tagging vocabularies internally? Or does this only encourage content silo-ism?

All of these auto-tagging services, do they include RDF concept URIs? Are these mapped in dbpedia? Are they using a commontag.org schema?

catch’s picture

Version: 7.x-dev » 8.x-dev
giorgio79’s picture

I have thought about this issue a lot as well, and given that taxonomy has become a term reference field in D7, I believe it starts to overlap with the node reference field module. I believe both fulfill a similar purpose, namely establishing relationships between nodes.

With the recent node relationships module:
http://drupal.org/project/noderelationships

I would go as far that for D8 we may not even need taxonomy any longer, because if Node Relationships matures enough we can just link together nodes with a node reference field, that references a "taxonomy" content type :)

And immediately you get all the benefits of nodes, namely moderation, commenting etc. that are a coveted feature of taxonomy...

So try this:
1. Create a new Tags content type
2. Add a node reference field (with http://drupal.org/project/noderefcreate) to your main content type

And voilá you have a "vocabulary" that is now a content type with all the benefits of nodes, that is moderation, voting, comments etc etc etc :)

Xano’s picture

- We do need Taxonomy (for now), because Taxonomy's two main features are referencing terms and nodes and references between terms. AFAIK it has already been decided that comments, users, terms, etc. will not be converted to nodes, but that we will move towards an entity API that is linked to field API.
- From this point of view Taxonomy will probably at most be converted to an hierarchical reference field system.
- I want comments as fields (very subjective wish from the lonely developer writing this post and completely unrelated to this issue.

giorgio79’s picture

We do need Taxonomy (for now), because Taxonomy's two main features are referencing terms and nodes and references between terms. AFAIk it has already been decided that comments, users, terms, etc. will not be converted to nodes, but that we will move towards an entity API that is linked to field API.

Good point Xano, although I believe relationships between terms is just a nested tagging of terms.

If we continue with my example, if we create a third content type called for example Tags Relations, we can create a node reference inside the Tags content type, and just start tagging away :P

How about that? :)

I am not saying this is ideal or is the best, all I am saying is that it is easily achievable in 2 separate ways.

So far all my sites used taxonomy, but I got fed up with its lack of moderation, voting etc. I also want my term pages to be much more elaborate , so I am slowly moving over to node references and such.

One thing that is not as easy at the moment is hierarchy.

However, if Node Relationships (http://drupal.org/project/noderelationships) module merges with Node Hierarchy (http://drupal.org/project/nodehierarchy), than bingo... Bye bye old taxonomy. We still keep its features, but now use new shiny stuff.

Xano’s picture

AFAIK it has already been decided that comments, users, terms, etc. will not be converted to nodes

Anonymous’s picture

Status: Active » Closed (won't fix)

I'm going to close this one out, since it is close the 3 years with no activity.