Group hierarchy lost when moving to BibEntry

[HainesB]

When moving from JabRef 9.10 to 3.4, the philosophy governing groups changed. Rather than
a key being linked to a group in "jabref-meta: groupstree" the group is attached to the individual entry, as in "groups = {culture},",

The big disadvantage is that groups are no longer in a hierarchy but a independent. As the result, a key associated, say, with "culture", is associated with that term everywhere it appears in the database. So when I select "culture", hundreds of keys are elected that use the word "culture" in a different context or meaning. If I understand the situation there is no way now to avoid the hundreds of irrelevant links.

The issue is now to avoid duplicating the situation in the future. I find that if a BibEntries share a
string, they are viewed as the same. Since they are case sensitive, I can distinguish Culture, cUlture, cuLture, etc. Then go through all the keys selected by "culture" and re-associate them with one of the new names. Since this is hundreds of hours of work, I wonder if there is a better method.

[simonharrer]

So the issue is when the group name is used multiple times in a large group hierarchy at different places? Like you have GroupA -> culture, GroupB -> GroupC -> culture and in this case the two groups will be merged falsely? Did I get your question right?

JabRef should not be doing something like this. We need a step to uniquify the group names before they are converted. What do you think @tobiasdiez ? Or this this already done? I am a little bit uncertain if I have understood the question correctly.

[vchouraki]

Hi. This is exactly that.

I usually use one group per project/paper, each one having subgroups with generic names, such as "to_review", "introduction", "materials", "pathophysiology" etc. With JabRef3.4, a given "to_review" subgroup contains the articles from all the "to_review" subgroups.

[HainesB]

Since movement from JabRef 9.10 to 3.4 resulted in massive loss of information, I reverted to the former and recovered the jabref-meta: groupstree for each database. While I lack any expertise, it seems that the hierarchical structure of group names could be readily preserved. For example, here is a hierarchical group tree:

1
-A
-- a
2
-B
--a
3
-C
-- b

So a bibliographic entry that is associated only the first "a", and with "C" and "b" would have the field:

groups = {1,A,a; 3,C; 3,C,b},

If this could be done, I recommend it.

[koppor]

Refs #628: "Feature: Hierarchical Keywords"

[simonharrer]

Okay, this is confirmed.

A solution using like 1>A>a or something like this sounds reasonable.

A quickfix is not possible. This requires a major rework as a lot of issues are caused by this.

• the name and the keyword differ in static group
• explicit group needs to now its context always to compute the correct key (or the other classes must ensure that the correct keyword is always set which encodes the group hierarchy)

@tobiasdiez we should discuss this when you are back

[tobiasdiez]

I could implement that the whole hierarchy is always written in the groups field. But what about cases where the same group name is used on the same level, i.e. 1 > A > a and 1 > A > a with different entries? should this case just be forbidden upon creation of the group?

[anassal]

@tobiasdiez I think so: duplicate names should not be allowed for sibling groups, just like file names in a classic file system.

[koppor]

@tobiasdiez I don't get your example. Does that mean, that it is not possible to have the same group a associated with two different entries? (With a being nested in A, being nested in 1). I would allow two entries belonging to the same group... Maybe, I did get something wrong.