many-to-many relations

Establishing relations is potentially a powerful feature. I currently add relations but had not utilized them yet.

When I read an article on a topic, I usually search related articles on the same topic too. What Zotero currently enables us to do is to relate that record with many other records (1-to-many relation). Let's say I found 5 articles on topic W related to topics X, Y, and Z, whose records happen to be stored in folders X, Y, and Z. I would like to select these 5 articles and relate them to folders (and dynamically to all the current and future records in those folders).

So my request of feature is relating not only records-to-records but records-to-folders and folders-to-folders.

Best,

--mehmet
  • So my request of feature is relating not only records-to-records but records-to-folders and folders-to-folders.
    Maybe I'm missing something, but doesn't adding a record to a collection, or creating a subcollection, do exactly what you are asking for?

    The current "related" field isn't really any more useful than that.
  • Let me give you an example: Suppose I have two subcollections Disease-X and Disease-Y under the collection Disorders, and a subcollection Drug-Z under the collection Drugs.

    Say Disease-X (e.g., Reye Syndrom) is caused by the Drug-Z (e.g., Aspirin) and I want to associate these two subcollections. In this case all current and future articles in Reye Syndrom subcollection will be associated with all current and future articles in Aspirin subcollection.

    Suppose some articles in Disease-Y discuss treatment with Aspirin. An efficient way to relate them to Aspirin is to select all those articles and relate them to Aspirin subcollection.

    Furthermore, since this particular subset of Disease-Y articles discuss about Aspirin treatment, I want to relate them to each other by selecting all and relating them to each other in one shot. Currently, what needs to be done is selecting one article and relating it to the rest; selecting another article and relating it to the rest, and so on. One needs to do that (n - 1) times for n related articles.

    --mehmet
  • I think (the already existing) tagging is already good for this--it is trivial to put give a bunch of articles the "Disease Y" tag & to give a different bunch of articles the "Aspirin" tag & to then look at which articles have both tags.

    Or (as per Bruce and since articles can belong to multiple subcollections), you can have a "Disease Y+Aspirin" folder & place this wherever you wish.
  • Noksagt:

    You are right to the extent that tags are explicit relations. As long as you can utilize Tags fully, there is no need for the field Related whatsoever.

    From my point of view, the usage of Related is simpler and easier than the use of Tags; thus, people like me who cannot spend much time with the best organization of articles, the field Related is usually the only realistic way. Using relations (via the Related field) is more practical, since in the tagging approach, one needs to spend time to find the right tags to establish relations in a unique fashion. Plus, one needs to search items of interest via those tags, which is an additional overhead.

    My suggestion, establishing relations with collections (vs. with individual items), ensures the persistence of the relations for the items that will be added into that collection in the future. And I do not buy the idea to create new subcollections as intersections of two or more independent collections (as an alternative solution, that approach combinatorially and practically too complex -- it requires duplicating them in two or more places or searching a single subcollection in a number of possible locations).

    My example in my previous communication was a simple one to explain what I need. Apparently, it is clear what I need and the disagreement is about the legitimacy of the need (i.e., why I need it).

    One other reason that we need is the cases where complex relations cannot be easily defined with a single or a few tags. Suppose I have an article which has 15 tags (the number of MeSH tags in Medline is usually 10-20) and suppose there is no other article in the entire Zotero library that contains all those 15 tags (intersection is a null set). How can you identify the related articles? There is a number of answers to this question, and none of which that I can think of is simple. And I do not think the union of search results for each tag (disjunctive normal form) comprises the set of related articles of interest.

    Another example. You read one article and found a bunch of referenced articles that you also placed into your library. You want to relate them all to each other (instead of relating all to those articles only to the article that contains those references) but don't have any good tag set in your mind at that point. Practically what happens in this situation (at least for me) is typically as follows: You would postpone doing that since tasks in your hand would be usually more urgent than this kind of bookkeeping, but you would rarely find a chance to go back and do what is necessary.

    Anyway, enough said! If you are still not satisfied with my explanations and are not convinced that this is necessary, I am giving up; but I thank you for taking my request into consideration.

    Best,

    --mehmet
  • edited May 25, 2007
    Keep in mind that I don't speak for the Zotero devs (and neither does Bruce), but:
    Apparently, it is clear what I need and the disagreement is about the legitimacy of the need (i.e., why I need it).
    I suppose I'd agree with this--I don't see how "Related" (in the current form) can really scale. It doesn't answer HOW records are related. I use it for both "cited in" and "cited by." Adding any interface complexity to achieve what can already be achieved through some other method until this is addressed seems like a bad idea to me.
    no other article in the entire Zotero library that contains all those 15 tags (intersection is a null set). How can you identify the related articles?
    This I agree with--we need to not only perform "AND" searches, but also "OR" and "NOT" searches. Someone already made a feature request for this. The interface for mass tagging is already implemented & is good. We just need better searching.
    You read one article and found a bunch of referenced articles that you also placed into your library.
    Until/unless there are "types" of relations, I think that a subcollection would sufficiently group these together. The subcollection could even have the name of the first paper (as a hack to tell you how you related them).
Sign In or Register to comment.