Specifying constraints between tags

Hi all!

Tags are a very powerful concept, but very few (if any) tag systems support the more interesting features that they inherently support. Several such features are already requested on the forum. To name a few: I'd just like to look at this from a more theoretical point of view and suggest a feature that basically encompasses all the others. It's too big to 'just add', but hopefully it will invoke some discussion. Let me emphasize that users that are not interested in this feature need never even notice it is there.

Fundamentally tags are just propositions (on/off switches) on documents. Propositional logic formulas combine them with logical connectives (and, or, not, etc.)

My suggestion is to allow users to constrain their tags by propositional formulas: formulas that always have to hold for all documents. (One might also think about filtering and tagging with formulas, but that doesn't add any expressive power and would unnecessarily complicate the interface.)

To put this in perspective, Zotero does not support propositional constraints at all, but does support filtering by specific kinds of formulas: through clicking on multiple tags, you can filter on an arbitrary conjunction ([X] and [Y] and ... and [Z]) of tags. Saved searches can filter by any conjunctive or disjunctive clause, though with a bulkier interface.

Constraints could express things like

  • [Modal Logic] implies [Logic]
    anything tagged with [Modal Logic]
    should also be tagged with [Logic]
  • [Grammars] iff [formal grammars]
    the tags [Grammars] and [formal grammars]
    mean the same
  • not ([Read] and [Unread])
    nothing can be tagged
    with both [Read] and [Unread]
But power-users could use this to do pretty much anything they like. These formulas can be specified in a popup-window hidden in a menu somewhere. When they are in effect they can automatically add 'virtual tags' to documents (tags/formulas that are forced there because of constraints) and they can disallow the user to add extra tags that would otherwise break constraints. (For the purpose of this discussion, not tagging a document with [X] does not mean that it is tagged with "not [X]".)

There are a lot of SAT solvers out there that can act as a backend to Zotero and do most of the difficult work. They're very fast these days.

There are a number of issues I haven't addressed, but I'll leave it at this for now.

What do you think?
  • While fine in theory, I have some reservations about this feature. The main thing is that this sounds too complex for the typical user, so the effort for implementing this may not be justified considering the number of users who would potentially use this.

    Also, considering that many users do not understand propositional logic, this, if adopted more widely, would probably require quite a lot of user support.

    There are also technical issues: How would this be presented in the user interface in a way that is not confusing? Also, it is not immediately clear where this would sit well in the current technical architecture of Zotero: Consider the case of group libraries. Where would the rules reside, would they be library specific (like tags) or user specific. If they are user specific, how would you enforce a rule that you have created if also other can edit the tags?
  • I share mronkko's concern. If all the work is going to go into implementing this it needs to be accessible to people not comfortable writing propositional logic (aka 90%+ of Zotero users).
    What I could see, though, is implementing this under the hood (and make it accessible as an advanced feature via prop logic statements) and then use it as a backbone for GUI implemented features. Without having thought about that much, that'd be a _ton_ of work, though, both on the GUI and on the tag-handling side of things, so that'd either be a very ambitious 3rd party project or something that's going to take a lot of time.
  • The complexity of this feature from a users point of view is a valid and expected concern.

    But adamsmith hits the nail right on the head: The full extent of this feature doesn't need to be available to the average user. It can be exposed through a GUI in a simpler form and still be available for geeks like me behind three levels of menus.

    About the work: yes indeed. This would take some time to implement properly, though perhaps not as much as you're imagining. The constraint solving itself would be delegated to an existing backend, accessed through an API. Once clear design decisions have been made (and this, at least, is something I'd like to help with), the programming itself doesn't have to take all that long.

    (Disclaimer: I am not familiar with the Zotero code/API. But I've been quite impressed with Zotero so far. I'm guessing it is set up in a sufficiently modular fashion to accommodate this feature.)

    It will certainly be easier to go this route than to code ad-hoc solutions to many of those other feature requests. A bonus: many existing Zotero features might at some point be reimplemented in terms of this framework. Collections, notes, attachments, saved searches, ... could basically "be" tags, if only under the hood. This might greatly simplify the code-base.

    mronkko: As for the technical issues you bring up: those are certainly points that require thinking about. Some preliminary responses:

    The user interface

    The user interface doesn't need to expose the full functionality. For mainstream use it's probably enough to allow the user to draw "requires" and "excludes" arrows between tags. Perhaps something akin to feature diagrams may be appropriate.

    Where do the constraint rules belong?

    Where do the constraint rules belong? Primarily, I think the rules should sit where the tags sit. Perhaps it is wise to make editing the rules a separate permission from editing the documents. Group administrators should be able to change the rules, but users with lower editing-rights should probably only be able to read them and 'be constrained' by them.

    That being said, it would also be useful if users could set additional rules for their own personal experience. These rules would not affect other users of the library. When only virtual tags are affected by personal rules, there is of course no problem.

    Broken constraints?

    I suspected it would not be possible to prevent constraints from being broken in all situations, especially in a collaborative environment. It might also go wrong by syncing independent changes. But it's not a problem, as such. Documents with broken constraints could simply sit in a special folder until someone fixes the problem.

    It might also be possible to figure out exactly which tags and rules are responsible for the conflict, and still let the document exist problem-free inside all unrelated tags. There is research on this, but it goes a bit beyond hard propositional logic (where a model either satisfies constraints or doesn't, no middle ground) and might be a bit too ambitious for now.
  • edited May 30, 2021
    The suggestions here are great and I'd love to see more features in this regard. Citavi has already proven that there is a demand for this kind of advanced reference organization.
Sign In or Register to comment.