Agree to that assessment, but that might not always be in control of the people using the tool. I believe that my list is good proof for this: one paper is from 2008, when I did not even have any degree, and the second case I was middle author and thus not any driving force either. So it apparently simply happens, sometimes out of control of those using this platform. (I have however seen this before too, especially for workshop papers (like in one of the two cases reported), because workshop papers are often completely consumed by their follow-up versions; sometimes it's even the very exact same paper. In such cases I would understand if some argued that it makes sense (or at least "is OK"). Anyway, thanks for looking into it!

Can you please delete this post? I've accidentally posted it in "ideas", which I noticed only *after* posting. But it seems I can't delete it myself. (Here the new post in the correct category, bugs, https://bibbase.userecho.com/communities/1/topics/501-entries-appear-duplicated-when-searching)

Also, since now it has its own entry, I think you should consider deleting my posts with the very same topic in https://bibbase.userecho.com/communities/1/topics/10-multiple-entries-with-same-title-and-same-year-are-displayed-as-duplicates# as they did not they answered there anyway.

Re you can edit: Yeah... Still seems easier to allow editing by the authors. (Though I noticed that we *can* -- it seems that it only gets deactivated after a time, so one has a short timewindow to make edits; which seems okay.)

Re you see two different entries: Wow! What the hell. :) Below what I see:

Ahhhh, interesting! I see what you see if I simply scroll down to that year. But if I use the *search* function (e.g., type "mattm"), then I get this duplicate! So it's a bug in the search function. Should I post another post to report this since this is technically a different bug?

Debugging is fun! Here some further observations:
- the very same bug is responsible for the duplication of the "Johnson" entry (see above). For example, search for "john" and you get two identical entries. Just scroll down to that year and you have the two different one. (But see the next point first)
- once you searched you already corrupted the list. I.e., if you refresh and hence see the correct list, all is good. If you search you get, as said, the duplicates. However, if you then delete the search again to see the entire list it remains broken. I.e., even then you see duplicates (although the search is empty)
- also note that it does not matter what you search for; the list remains broken. I.e., you can even search for 2024 (which doesn't have problematic entries), and then delete that search again. Afterwards, you still get the duplicates (in the full list; look for 2022 and 2008).

Thus, in conclusion: the "search filter" corrupts the list by creating duplicates where authors and title are identical.

Again, let me know if I should just re-post this under a new thread (since it's a different bug), then you can document it as "under review".

Anyway, thanks for being so quick!

I just realized that I used your last name.^^ Sorry for that.^^ Why can't we edit old posts? That's odd! We can't even delete an entry... That is super odd! What if somebody accidentally posts sensitive information? Or am I just not finding the right button?

Dear Fritz,

Wow, that was already fixed 4 years ago! Such a long time... Thank you once more anyway. :)

It seems however that the bug was either re-introduced or persisted but was never discovered. So I have two cases where this problem still occurs. (Just some background: previously I had all my publications separated into different files and so those entries where the issue now becomes visible were never in the same file and bib list -- but now they are.)

// I was too lazy to make it anonymous; I don't see the point anyway. :)

@techreport{Bercher2008FONDPGHeuristicTR,

author = {Pascal Bercher and Robert Mattm{\"u}ller},
title = {A Planning Graph Heuristic for Forward-Chaining Adversarial Planning},
...}
and
@InProceedings{Bercher2008FONDPGHeuristic,
author = {Pascal Bercher and Robert Mattm{\"u}ller},
title = {A Planning Graph Heuristic for Forward-Chaining Adversarial Planning}, booktitle = {Proceedings of the 18th European Conference on Artificial Intelligence ({ECAI} 2008)},
...
}

In the list, bith entries are however shown identically; it uses the one from the TR.

The same issue happens with the two papers with keys Johnson2022aSATPruning and Johnson2022bSATPruning (from 2022).

You can verify this by taking a look at:
https://bercher.net/my-publications/all-publications

You can access the bibfile on:
https://bercher.net/bibtex/bibliography.bib

Thank you again! :) 

O wow, you are right! Thank you, I didn't expect that... You could consider (I would definitely do that) adding this also to the description of hidemenu.(As those users like me who'd like to find/suggest that option would have to realize that this is related to grouping. Of course it *is*, but those concerned with citing just a single paper (like me) might not "think in groups" in that context. :)

Anyway, thank you again!

That is great news! Thanks for clarifying/updating. :)

Hey Christian,

First of all, thank you for your response! I remember to have read it a *long* time ago, but it seems I've never responded to it... I just remembered due to my other question you've just answered. :)

Regarding your question whether it would also be *possible* to use just a single huge bib file: I guess it could? By using these additional fields as you suggested I do not see why that shouldn't be possible *technically*, but it has few clear drawbacks:

(1) One would lose a clear separation of how the bib entries are organized. It's just 'semantically' sooo much nicer to separate bibtex entries into different files if they do have a clear semantic difference. After all, this is what one does with cose as well -- refactoring is a huge part of any successful project. Once one has more than maybe a few dozend entries I think separation might be very beneficial. In my case it's even more severe since I do not only have approx. 100 publications of my own, but I also organize publications by several authors. It doesn't feel right mixing them, just from an organizational point of view.

(2) The second downside is simply the workload of the users. The bibbase service only receives "one large list" anyway, I would assume that technically it wouldn't matter whether this comes from one physical file or whether that "single list" is the result of merging n files together ad hoc (let me know if I'm wrong!), which we'd get with a syntax as suggested by Jorge (e.g., bib1=...&bib2=...). If however the user had to merge all these files together he/she had to add all these additional bibtex fields to remain the desired functionality. Also the call itself would be a bit complicated since we had to use the additional filter. (Though otherwise we of course have to use additional parameters as well, namely those required for the different bib files; but that still seems much more appropriate semantically.)

(3) Lastly, the current workaround would make the bibtex files less nice (and more error-prone as all these categories had to be added for each new entry). The former is "relevant" when recognizing that the bibbase service also allows to show the bibtex entry itself. I argue that this bibtex entry should only contain the information relevant for the website visitor, i.e., all those that are 'semantically' relevant to the paper, but internal stuff like keywords used for filtering shouldn't be accessible to him/her. Thus having them in there is just not very nice. (Though that is clearly the -- be far -- least important argument; the first two are much more important.)

In principle, we (i.e., we users who'd like to have this feature) can just write a program/script that creates such a single bib file from the sources for each source file. E.g., say that I'd like to call your service with bib1, bib2, and bib3 in a merged fashion, I could instead write code that creates a new file bib-1-2-3 that (a) merges all files together wile (b) adding the required keywords into the entries of the new files (even that can be automated since once can just use folder+filename as keyword). The downside (apart from having to write that code :)) is that this code/script had to be called after every single change done to either bib1, bib2, or bib3 in order to create an updated bib-1-2-3. Is seems easier if that exact process would simply be done by the service. Even if bibbase caches the files that it receives, couldn't it even then cache the fusion of inputs? Or would that make any "difference" to the service/underlying data base? I don't know how that tool works internally (though I know that somewhere you have quite an elaborate explanation online...), but at the end I'd assume it simply receives one big "list" (file) with content. Wouldn't it be a trivial task of supporting the concatenation of several input files, or is there indeed a difference? Without knowing the technical details, I'd assume that calling bibbase with bib1=...&bib2=...[...]&bibn=... would be nothing more than calling it with the concatenation of bib1 to bibn -- isn't that the case?

(I'm of course not at all saying that this would be trivial to implement (and maybe others don't even have the demand! though I'd be surprised if others don't organize their works in different files as well), one still had to change the syntax; though it can probably be expanded in a downward-compatible way by just adding *additional* sources as parameters -- to append the cited bibfiles at runtime for each call.)

Thank you for your super-quick response!

I've just finished testing everything:

- When only calling bibbase with my bibtex file and the css as argument (i.e., directly in a browser without being embedded in the webpage that uses other css files) then your code snippet (using ".bibbase_paper") does indeed work as hoped! I.e, the entire entry including title and links gets adjusted as intended.

- However when including the same into my website, then it only changes all after the title, i.e., proceedings title and so on, but the title itself as well as the links beneath each entry remain overly large (as defined by the website css files).

So I went looking through your example css files and found a title-specific option (i.e., .bibbase_paper_title). That however works nowhere (i.e., also when called directly in the browser), so I guess that doesn't mean what I think it does or it is simply overwritten by some other style. Any other ideas? Since the title remains the same whereas all the stuff afterwards use different sizes there *must* be something that's differentiating these two elements. Do you know what that is? (I.e., what's the property that's specific to the title and link size?)

I checked the HTML code of the generated website and it appears as if all website css files are loaded before/above the bibtex inclusion -- if that helps.

[Suggestion: By the way, and thus orthogonal to my actual question: What's your opinion about linking these two css files you just posted also in the table (https://bibbase.org/documentation) that mentions that such css files can also be used? I would highly expect that this is *very* useful for designers wanting to make their own adjustments. Those files are public already anyway, so why not linking them there.]

Regarding you taking a look at said website: I'd be happy to, but it's not online yet. I'm testing it locally so far. I hope that I can publish it next week. But I can let you know that it's the grav CMS with theme Vela_v.1.2.3 (https://github.com/danzinger/grav-theme-vela). In case you don't know grav, you can find it here: https://getgrav.org/ -- a *really* great CMS that's based entirely on markdown files, thus very easy even for "normal people" without webdesign skills!

Hey Christian!

I do have the exact same problem as discussed here, though I believe that it's actually still not resolved. Let me first describe my situation before asking the specific question I have:

- Like probably everybody I embed the used citation list using <script src="https://bibbase.org/show?MY-BIB-FILE&jsonp=1&theme=SOME-THEME"></scrip>
- I am not aiming at using a specific self-defined css since your default themes already look awesome!
- But the webpage that embeds the bib (i.e., that includes the above-mentioned line) does include various css files. Note that I do not have control over the css files loaded by the webpage because I use a Content Management System (CMS) that includes all these css files by itself. I do not have control over this part of the code, so those css files are definitely loaded, I cannot prevent this. (Also, this does make sense as they define the style of all the rest like the navigation and so on.) However, these css files mess up the appearance of your otherwise great-looking bib list!

Thus finally my (first) question:
(1) How to tell your bibbase list that it shall *not* be screwed up by all the other css definitions? I would assume that this is "outside the power" of your plugin since the included content will *automatically* be formatted by the css files of the page -- you couldn't even possibly change that, is that correct?

But *if* I am right and you can indeed not change this behavior,do you still know how to fix it? E.g., can one put a certain environment *around* the "script" line in which the other css definitions are ignored? Otherwise I really don't know how to include it, as it's really messed up.^^

To be precise: the titles of all entries are huge (whereas the authors use a reasonable font side), and also the links placed below it (like doi or the entries starting with url) use this (too large) font size.

I was also experimenting with loading a bibbase-specific css file to compensate for these other unintended changes. However, in your only css example file (here: https://bibbase.org/css/styles/default.css) I wasn't even able to find the definition of the font size of the paper titles and links, so I also couldn't set it to a reasonable size.

Thus,
(2) where in this example css is the font size of title and links defined?