Tags are designed to be really simple things, and part of the reason for that simplicitly will become apparent when Zotero starts implementing social networking services.

In your example, I would expact rather than using "oscillatory integration (series extrapolation)" you would use two tags: "oscillatory integration" and "series extrapolation". That gives you more filtering options without redundancy.

Regarding future social networking extensions: These would seem to make it crucial that tags and collections be merged if at all possible: Suppose I have a collection called "Numerical analysis", with various subcollections including one called "Oscillatory integration", which itself has several subcollections. (It seems certain that users will have structures like this right now in their Zotero libraries.) Surely this metadata is just as important as any "tags" another user may have.

CB, I also use tags and collections quite differently---I don't use collections at all. The fact that you and I use them so differently shows I think that no distinction can reasonably be made between them for the purpose of categorisation in a social networking context.

For transient, procedure-related purposes, I use tags like: "to read", "to update", "to acquire source material", "untagged", "unprocessed", or whatever. I would love it if I could organise these tags hierarchically under a parent tag called "procedural metadata" or similar.

CB, can you envisage a parent tag called "projects"? Imagine all the tags you currently have being stored under such a parent tag, and all your collections being stored under a different parent tag called "procedural metadata".

FWIW, I use collections and tags in different, but overlapping ways. I tend to assign collections for very broad categories, like the new project I'm working on. I use tags for finer-grained metadata. So do I see them as different, in the same ways that putting a label on document is different than putting it in a folder (though collections in Zotero are not real exactly in the same way).

Also, there's no reason that collections can't be integrated into a social-networking infrastructure. RDF is well-suited to supporting all of this stuff in a distributed way. I wrote about some of this awhile back here. The upshot of my suggestion there would allow defining relations between tags.

Andrew, I can't see what would be gained by removing a distinction that some find pragmatically useful at the GUI level. If GUIs had reached the stage where we could take an aspect of the (meta)data model, and improvise a visual metaphor for it based on our own preferences, then merging tags and collections would make sense. But for now, I find the pragmatic/metaphorical difference between a container and a label an ergonomically useful one.

Being able to specify hierarchical (and other) relations between tags would be very useful, so I'm with you there. That would give you most of what you want, if I understand you correctly, and you could just go on not using collections.

... there's no reason that collections can't be integrated into a social-networking infrastructure.

I would think it important to be able to switch off sharing for private and transient means of organisation. Perhaps this could be done on a per-collection basis. Personally, I'd hate to have to make this choice for every individual tag, but based on Andrew's comments I can see that people are going to differ on this, so it might just have to be togglable for everything.

Thanks everyone for your comments.

Metaphors

For me personally, as you can probably tell, the difference between the two metaphors "container" and "label" is gone. But I do see that both metaphors are important. I especially think that new users of Zotero need to be able to see at once that their own thoughts on the classification of their literature (whether currently stored in their heads or on 3x5 index cards or whatever) can be represented intuitively in Zotero. I hadn't thought about this reason for the distinction before.

GUI

I can also now see that "collections" and "tags" being browsed and filtered in slightly different ways in the current GUI is good. It allows people to establish personal systems like the one CB has (where collections are for procedural metadata, and tags are for content-related metadata), and have that personal system reflected in the GUI. I think this comment by CB is really pertinent:

If GUIs had reached the stage where we could take an aspect of the (meta)data model, and improvise a visual metaphor for it based on our own preferences, then merging tags and collections would make sense.

I agree that GUIs have not reached that stage yet (and even if they are close, Zotero's probably not the right project in which to experiment in that direction). And I do see that the next best thing is having the most useful mix of current standard GUI elements (such as the hierarchical list called "Collections" list in Zotero) and somewhat non-standard GUI elements (like the excellent tag selector in Zotero). In that spirit, here are the important differences as I see them between the two GUIs:

Main GUI differences between collections and tags

1a. When you filter by clicking on a tag, all other tags vanish from the tag selector except those which are attached to one or more items in the filtered list. When you filter by clicking on a collection, the equivalent information is not presented visually.

1b. You can click on further tags to further filter the list using boolean AND. You can't click on additional collections to further filter the list.

2. Collections can be arranged hierarhically; tag's can't.

3. You can easily tell which tags are attached to a certain item; you can't easily tell to which collections a certain item belongs.

In my opinion, the most desirable one of these differences to resolve is number 2; but it is also the one for which no simple GUI modification jumps to mind. I have a couple of ideas, but none of them are clean enough to fit with Zotero. But I do really think that the current GUI features available for easily filtering by tag need to somehow be augmented with hierarchical tags.

The resolution of difference 3 also seems desirable (although I wouldn't know from experience how useful it would be, because I don't use collections at present). Perhaps it has already been resolved and I don't realise it? Anyway perhaps when selecting an item, all collections containing that item can appear navy blue instead of black, or boldface instead of normal, or whatever?

I think the resolution of difference 1a would also be useful to people using collections, because that information (the list of all other collections containing one or more of these filtered items) is certainly useful for tags. Perhaps when the list of items is filtered by clicking on a collection, make the names of any collections that contain items in the filtered list appear bold or coloured or whatever?

Similarly resolving 1b would seem to be useful for people using collections. 1b is the very reason I don't use collections, and instead only use tags. Being able to filter with boolean AND by selecting multiple tags is just too useful, even though it means I have no hierarhical structuring available to me. Could 1b be resolved by allowing multi-select (by holding Ctrl (or the equiv in Mac OS X)) in the Collections (and saved searches) list?

GUI suggestion for tag-collection conversion

As an intermission, here's a related idea I had: What if dragging a tag from the tag selector into the list of collections had the following behaviour: Create a new collection with the same name as the tag, and put all items that have the tag into the new collection; then delete the tag. And vice-versa for dragging a collection from the list of collections into the tag selector.

Personal example

Here are some of the ways articles are classified in my head. How can I best represent this classification in Zotero?

A. I have some articles that are "numerical analysis". In my mind, some of these fall into the subcategory of "oscillatory integration", and some of them fall into other subcategories. Articles about "oscillatory integration" themselves fall into various subcategories.

B. Some of my articles "have me as an author". A subcategory of these is "have me as the primary author".

C. Some of my articles are "unread". Others are "read". Some of the "read" articles fall into the subcategory of "worth another, closer look". Some of the "unread" articles fall into the subcategory of "don't need to be read", and others fall into the subcategory of "need to be read".

D. Separately, some of my articles "need their metadata updated". A subcategory of these "need to have their source material acquired".

Categorisation A is "content-related metadata". Categorisations C and D are "personal/procedural metadata". Categorisation B is somewhere in between perhaps. All of them contain a hierarchy, which points me to "Collections". But being able to filter across these categorisations ("show me oscillatory integration articles that are unread and need to be read and whose source material I am missing") is essential, which points to "Tags" and the wonderful tag selector GUI element. Shall I use collections or tags?

For now, as discussed above, I can emulate a hierarhical structure using extra tags. Here are the tags that a single item might have:

* numerical analysis
* numerical analysis (oscillatory integration)
* numerical analysis (oscillatory integration) (series extrapolation)
* unread
* unread (no need to read)

It feels redundant, which is why in particular I wish for hierarchical tags.

[deleted. for related post see:]

http://forums.zotero.org/discussion/4006/hierarchical-organization-of-tags/#Comment_17182

I didn't see this mentioned above, but you can determine which collections and sub-collections an article belongs to by selecting it and then holding down ctrl (cmd on mac?) - the relevant collections will be highlighted.

I vote for hierarchical tags! This will make having many tags much more manageable and add functionality that will allow Zotero to grow into a real knowledge base software!

A real-world example of what lucas describes (real-world for historians) would be tagging by period. i.e. a tag like "1920s" could belong to "inter-war period" and "20th century." I would love that.