Open ror3d opened 7 months ago
koppor
commented
7 months ago We somewhere have discussion to do following:
The idea is "copied" from TagSpaces: https://www.tagspaces.org/
koppor
commented
7 months ago I need input on following: We had en exhausting debate on the "keywords" field. One opinion: it is from the publisher AND MOST NOT be changed. Other opinion: This is what I categorize entries with - and it should be automatically reflected in the groups ("keyword groups" is one step). -- Maybe the "solution" is to have a "tags" field. groups would be JabRef 5.x behavio, and tags a new JabRef 6.x behavior.
(Side note: We changed the group format in the 3.x line inbetween and that caused confusion -- https://github.com/JabRef/jabref/blob/v4.0/CHANGELOG.md#34--2016-06-02).
ror3d
commented
7 months ago
- groups should be tags (which can be categorized)
Ah I see, what would be the changes between groups and tags? It seems to me groups already work basically like tags would. The feature request is mostly about UX of how those are managed.
About keywords, I'm of the first opinion, keywords are set by the paper authors or the editor, and if a bib entry is to be shared with someone it might be best to have that as original. On the other hand, if importing entries, the existing keywords might not be relevant to the tags I have in that library, so keeping those might also not make sense.
koppor
commented
6 months ago Just as note to think of it later.
dret.bib (https://github.com/dret/biblio) has the idea of topics:
topic = "jsp[0.7] asp[0.7] perl[0.7] cgi[0.7] servlet[0.7] php[0.7]",It seems that these are "tags" with a matching ratio added.
(Refs https://github.com/JabRef/jabref-issue-melting-pot/issues/421)
koppor
commented
6 months ago Another note: JabRef supports hierarchical keywords (a > b > c). Maybe, we could use that for tags (or taxonomy items), too?
koppor
commented
4 months ago The feature of hiearchical keywords is explained at https://github.com/JabRef/jabref/issues/628
andr-groth
commented
4 months ago Since the new keyword tag systems #10910 does not supporty hierarchical keywords anymore, I'd would be happy to see this feature #628 restored. This could be hopefully added to the tag systems, by extending the tag box:
On the other hand, the feature #628 is already quite powerful:
But since keywords are not required, they do not immediatly appear on the required tab when editing an entry. This is maybe why the feature #628 is not very well known. Only mentioned in a short paragraph of the documentation on groups (even not mentioned in the keywords section) : https://docs.jabref.org/finding-sorting-and-cleaning-entries/groups#nesting-sub-groups
What I would suggest is to make this feature #628 more visible, in the documentation and in the UI. The keyword tags are a good starting point :thumbsup: and maybe they should be made more prominent in the UI:
On the other hand, adding a new tag field might add a new level of complexity and confuse the user. I would keep it with the Occam's razor and the principle of parsimony.
andr-groth
commented
4 months ago And of course I would second the long-term goal #6191. At the moment there are over 30 input fields spread across six different tabs.
andr-groth
commented
4 months ago And of course I would second the long-term goal #6191. At the moment there are over 30 input fields spread across six different tabs.
Please see also my remark on koppor/jabref#679.
InAnYan
commented
1 month ago Here are my thoughts on groups in JabRef and bibliography management. WARNING: high probability of overthinking.
Let's start at the beginning.
The purpose of groups is to organize/sort/clasify entries.
The way JabRef groups work... Truly speaking, I can't explain. I think that JabRef actually tries to implement two approaches, that are actually too different in nature.
Here are some concepts that came in my mind when I was thinking about organization of entries:
For convenience, I would also like to add this statement:
Folders are a way to group entries, they are created manually, an entry can't belong to its sibling folder (only to a parent folder, hope you got the idea).
Also folders should be manually filled, because if we used a search expression, then one entry can be true for two or more search expressions, and so they can appear in different folders, which violates the 4 principle.
It's a kind of a mix between folders and tags.
JabRef groups are similar to folders, because I can make a hierarchy of groups. However they're not folders because I can have an entry in a child group, but it can not belong to the parent group. That's the thing I got very-very confused with.
JabRef groups are similar to tags, because filling groups with entries can be automatized.
In my opinion, folders and tags are different approaches and it's hard to explain how they can be mixed together. The explanation may have many 1) bugs, 2) ambiguities, 3) edge conditions.
I see N ways to improve grouping in JabRef:
Make groups behave like folders: Pros: easy, predictable, stable, https://github.com/JabRef/jabref/issues/10930 is easy to implement. Cons: we lose the feature of automatic assignment. And we also can't have one entry to belong to 2 sibling folders.
Make groups behave like tags: Pros: maybe easier to implement, automatic assignment Cons: no hierarchy.
Still, think about how folders and tags can be mixed. Pros: we can have a very powerful system. Cons: but that system will be complex. This impacts the development (bugs) and user experience.
Introduce a new way to organize entries, except folders and tags.
Extreme: implement folders and tags in JabRef separately. So we split the group panel in two: one for hierarchy of entries that is filled manually, the other is for tags that are automated way of searching entries.
Do nothing.
You can see, that I'm a fan of folders, and I don't like tags. So the review is biased. And whenever I assign an entry to group, I, as a beginner user of JabRef, imagine this as moving entry to the group.
How I (as a beginner user) organize entries: I mostly use the 5th approach. There are 2 kinds of groups in my BIB file: one are folders (I categorize papers), the second is utility groups. The utility groups are groups to see 1) which entries don't have a linked file (maybe I forgot to add it), 2) which entries don't belong to group (then I should group them). The 5th approach fits to my workflow. (But I'm only an amateur, and maybe you utilize groups better).
LoayGhreeb
commented
1 month ago However they're not folders because I can have an entry in a child group, but it can not belong to the parent group. That's the thing I got very-very confused with.
If you set the parent group's hierarchy to union, it will display all entries within both the parent and child groups. However, this won't affect the "groups" field in the bib source.
ThiloteE
commented
1 month ago You are right Ruslan, JabRef's groups feature is actually a tags feature, but we call it groups :D
IMHO, the larger your library becomes, the more difficult it is to manage via folders (because it takes long to find entries in deep nested structures; Too much scrolling, too much clicking). Folders are good for small and mid sized libraries, whereas large libraries work better with tags.
Both tags and folders profit immensely from a workflow that revolves around "search" or "search groups", but tags especially, because they easily allow you to find entries that haven't been categorized into groups yet. Categorizing via groups is a second more labor intensive step, whereas many entries already come with existing tags and keywords (and the title or words in an abstract also can be relevant) so less work is required.
InAnYan
commented
1 month ago Okay, I see.
After some thinking, I came to conclusion, that it is faster to make a keyword group for "document management" or "Ukraine", rather than manually moving them...
Then okay. I don't see any problems of changing groups to tags.
But, I have questions:
Is your suggestion for improvement related to a problem? Please describe. Currently, as far as I'm aware, the only way to remove an entry from a group is by selecting the entry (or a set of entries), right clicking on a group, and checking "remove selected entries from this group".
That is a bit cumbersome, but specially it's not intuitive. The group system is basically a tag/category system (since an entry can belong to many groups at once) and most systems that use tags have a way to manage the tags an entry belongs to from the entry itself, not from the tags.
Describe the solution you'd like Either a right click on the entry > groups > checking/unchecking the ones it should belong to, or some other way that a list with checkboxes (or similar) can be accessed to manage them, such as a dropdown somewhere that opens the list of groups with checkboxes that that entry has assigned. This option would allow for editing the groups of multiple entries at once.
Another option would be to have these tags also accessible from some tab in the entry editor panel, although that would only allow for one entry at a time to be modified.
Additional context For example, outlook's solution,
(this one requires right-clicking for every category you want to add or remove, which is not ideal, much better would be that you could select and unselect several with opening it only once)