Equivalence of collections and tags

It appears to me that there is a near-equivalence (and a potential actual equivalence) between collections and tags:

1. Tags are the same as collections, except (1a) you can't specify one tag to be a sub-tag of another tag; but (1b) you can view the contents of multiple tags using boolean AND (whereas you can't do that with collections), and (1c) there is a "Tags" tab in the rightmost pane that shows in which tag(s) a given item resides.

Or equivalently:

2. Collections are the same as tags, except (2a) there's no way to find out to which collection(s) a given item belongs, and (2b) you can only view the items of a single collection at a time; but (2c) you can specify one collection to be a sub-collection of another one.

Are there any other differences that I have missed?

I urge the merging of the two concepts of collection and tag in the long term. I particularly deseire this because of difference (1a), above.

For example, I have the following four tags: "oscillatory integration (contour integral)", "oscillatory integration (series extrapolation)", "oscillatory integration (levin-type methods)", and "oscillatory integration (other)". I would much rather have one tag, "oscillatory integration", and three sub-tags. This is not just a matter of preference; I often wish to view the contents of all four tags; but presently this is impossible without creating a separate, redundant tag called something like "oscillatory integration", which must be added to every item that has any of the other four tags.

I think this topic has been raised before, possibly by me; but I couldn't locate a reference in the forum.
  • edited April 12, 2007
    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.
  • edited April 12, 2007
    Thanks for your reply Bruce. I agree that tags should be simple. However, I believe that at present the relationship between collections and tags is complex:

    Some of my articles are about oscillatory integration.
    Ok, use a tag.

    Ok, but some of my oscillatory integration articles are of type A, and the others are of type B.
    Oh, you should have used a collection and two subcollections then. Or, you could give them all an extra tag.

    Ok, which one should I do? Collections or extra tags?
    Well, that depends on the details of how you're going to view them in the future...
  • 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
    edited April 12, 2007
    I can see where you're coming from here, as a principled difference between tags and collections isn't obvious to me either. But I use them quite differently, in ways that would be awkward if both weren't available.

    I use tags as long-lived content-related metadata, and collections for more transient, procedure-related purposes. So my specific projects are in collections, not tagged with a project identifier.

    If tags and collections were merged, I would need to distinguish these (for my purposes) quite distinct purposes by means of something like a naming convention for different classes of tags, which is a hateful idea.

    (There are though inconsistencies in my usage, eg. I use a ToRead tag, which should probably be a collection. Even more confusedly, I access my ToRead items via a saved search).

    Merging would also create a problem for me once social networking was implemented, as I'm happy to share tags, but would prefer my transient item-organisation to be private; and certainly wouldn't want them polluting any emergent categorisation.

    Pragmatically, I like the collection/tagging distinction, even if there isn't a deep principle involved (of course there might be, in which case no doubt we'll be told).
  • 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".
  • edited April 12, 2007
    I'd also add to this discussion the remark that a saved search is even more like a tag than a collection is like a tag. Saved searches can't have sub-collections. They can be combined using boolean AND with tags (by clicking on various tags in the tag selector in the usual way). In fact, I find it strange that saved searches aren't shown in the tag selector instead of the list of collections!

    Here are two of my saved searches: "Recently modified", and "Missing 'Read?' tag". The former lists recently modified items; the latter lists items which aren't tagged as either "read" or "unread". What if I wish to view the boolean AND of these two saved searches? (That is, I wish to view all recently modified items that aren't tagged as either "read" or "unread".) If saved searches were tags, I would just click on both tags in the usual way. But because saved searches are shown in the "Collections" user interface, I can't do this.

    My only options are to either rapidly switch back and forth between the two saved searches and try to identify by eyeball which items appear in both; or create a new search using all the criteria of the two saved searches.
  • 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.
  • I use tags as long-lived content-related metadata, and collections for more transient, procedure-related purposes. So my specific projects are in collections, not tagged with a project identifier.
    This is pretty much how we've been thinking of the difference ourselves.

    The similarities you point out are valid, Andrew, but I think that most people use the two in fundamentally separate ways. Everybody's workflow will be different, but as Bruce notes, collections can be thought of as folders, whereas tags are more like labels, and the fact that items can exist in more than one collection needn't change that basic metaphor. Folders and labels have rather different traditional use patterns in computer-based applications, and the Zotero UI tries to respect both, separately. Personally, I can't see not having a folder interface, and I also wouldn't want to manage a potentially large number of tags on an item through the same interface I use to manage my folders.

    Also, regarding saved searches, it would be fair to say that clicking tags in the tag selector is like running a search, because that's actually exactly what's happening behind the scenes, but most search conditions have nothing to do with tags, so I don't really see how saved searches are similar. Note, however, that for your example, you can specify saved searches as conditions for other saved searches (they're listed, perhaps somewhat confusingly, under the "Collection" condition), so you can simply create a new saved search that pulls from both "Recently Modified" and "Missing 'Read?' tag", and it'll update automatically based on the conditions of those other searches.
  • 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.
  • 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.
    That's exactly what we're thinking as well—collections will be the primary way through which you set permissions, though you'll probably also have the option of adjusting permissions (towards being more restrictive) on individual child notes in particular collections.
  • Thanks everyone for your comments.


    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.


    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.
  • Bump. This is good FAQ material.
  • edited September 8, 2008
    [deleted. for related post see:]

  • edited March 18, 2009
    Please implement hierarchical tags !

    The user has to maintain hierarchies only in one place (collections or tags) - and this should be tags since this semantic is already supported in certain ontologies and products - like Bibsonomy.

    So collections become more like smart folders, and tags support hierarchical organization.

    GUI - simply a tree of checkboxes as it is in Biblioscape.

    Thank you !
  • 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.
  • though apparently this is temporarily broken on the newest Mac interface (the key on mac is option, on linux it's alt)
  • 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!
  • edited October 15, 2009
    The Collections function is brilliant in my view, and I'm more than satisfied with the software as is. (The Option key does work for highlighting which Collections a given item belongs to.)

    If there were a hierarchical organization of tags, I would recommend that all tags still be displayed in a linear list, but clicking on a tag would cause any subtags to be shown. So, initially the alphabetical tag list would look like this:


    When you click on "Fruits", the Tag list would look like this:


    ("Fruits" would be highlighted in some way to show that it contains subtags. And the other tags would be highlighted in different color to show that they are also subtags.)

    In other words, subtags appear both as top-level tags and as sub-tags. This would help integrate the hierarchical tagging system with the realities of social tagging as well as the auto-tagging features of some citation download sites.

    (The way of doing it described above is based on my understanding of the "Categories" feature in ConnectedText.)

  • 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.
  • Yes, yes, this is an old post, but the problem still has not been resolved as far as I can tell and it's exactly what I'm interested in.

    The problem here that I am seeing is that, when using tags instead of collections, it becomes redundant adding the "parent" tag every time you add a "child" tag (going off of Andrew's example). So if one could assign a "parent" tag to a set of "child" tags that will automatically be added to a citation when it is tagged with a "child" tag, this might please everyone.

    As lucas pointed out, it doesn't seem to be all that necessary to display tags in hierarchical order, so the current display format would work just fine.

    Personally, I am a rather new user to Zotero and I was trying to figure out how to organize my citations. I didn't want to be stuck with a scheme that I would regret later, but on the other hand I couldn't really figure out how collections were different from citations.

    I like the idea of Tags, since conventionally folders (represented by collections here) are more restricted. To place an item into more than one folder you would have to have duplicates (which is where Zotero is not conventional). From a fresh user's point of view (which may be wrong), assigning more than one collection to a citation would mean dragging it into multiple locations, while tagging would mean just typing in the tags I want. Also, if I wanted to adjust categorization of a certain citation and I used collections, I would have to locate all of the collections the item belongs to and then go into each and remove whichever ones I don't like. This seems to be much more cumbersome than tags.

    The only thing that is keeping me away from tags, as already mentioned above, is the lack of a hierarchy.

    It seems to me that tags can potentially have all the advantages and none of the disadvantages of collections. Given the ability to set parent-child relationship they can completely replace collections.

    I also wouldn't say that most people would miss folders. GMail relies entirely on tags and there is not a lot of complaining about that. Yes, users still want hierarchical ordering and GMail came up with a decent solution.
Sign In or Register to comment.