I am trying to use refbase mainly with its bibtex export function. When entering the various details about a citation (publisher, organisation, publication, number, volume, ...) the respective export is always missing some sensible fields, at least for the "report" type of citation, so the created citation page in the final document is missing quite some important publication details.
Additionally I would suggest to introduce another type of citation, called URL: It is nowadays quite usual to point to such entries, but using the obligatory "misc" as citation type will not create a sensible citation entry in the final citation list, as the explicit URL is not rendered there. Of course everything could be interpreted as "Article" abusing this schema, but I do not see this as the ultimate solution for a novel citation administration system like refbase.
> I am trying to use refbase mainly with its bibtex export function.
> When entering the various details about a citation (publisher,
> organisation, publication, number, volume, ...) the respective
> export is always missing some sensible fields, at least for the
> "report" type of citation, so the created citation page in the final
> document is missing quite some important publication details.
Could you give me an online example? What do you get from refbase & what would you have expected instead?
> Additionally I would suggest to introduce another type of citation,
> called URL
I'm not sure this is a good idea. In a few years, I'm sure that almost all recent data will be available online somehow. So everything will have an URL. I.e, IMHO it doesn't really make sense to have an explicit "URL" type. Instead, I think it would be better to improve the existing types so that they output the right thing. Again, I'd appreciate some examples. What do you enter in refbase (and how?), and what would you like to see as output?
As a general remark, refbase currently uses Bibutils to write out BibTeX records. While this is generally a good thing, it gives us less options to customize the Bibutils output. So, depending on your needs, it might be necessary to also ask the Bibutils developer about it. But I'd really need to see some concrete examples.
first, thanks for the very fast reply!
You asked for an example. The following bibtex export was created for the details stated below the citation:
title="Guidelines for blending and handling motor gasoline containing up to 10\% v/v ethanol",
optlocation="Peter Roosen (firstname.lastname@example.org)",
optnote="exported from refbase (http://voro.homeip.net/refbase/show.php?record=1492), last updated on Tue, 17 Feb 2009 13:13:06 +0100",
To produce this output, both organisation and publisher were set to "Concawe". Please note the faulty integration of the "organisation" into the authors' list.
The field "Publikation" (in german, presumably "publication" in general), set to "Concawe Report", is not rendered as a bibtex field. The same holds for a given "volume" entry (which was entered when changing the citation type to "article".
I tinkered around with some other entry fields as well, to get a notion of what is exported and what is not, but do not remember every detail from that phase :-).
My general opinion on the bibtex export is to export everything as exactly as possible, since most of the fields in the refbase entry form coincide with respective bibtex fields. If it would work that way the selected bibtex style would do its usual job in filtering the material appropriately and creating a sensible output for reading.
The dependency on BibUtils might indeed be problematic as far as I did understand the interdependency. I searched quite a while for any lever to pull at and ended up in the (binary) xml2bib utility. But maybe you are more lucky or will definitely have a better savvy on what is possible and what not.
> The field "Publikation" (in german, presumably "publication" in
> general), set to "Concawe Report", is not rendered as a bibtex
The refbase "publication" field is really just for "sub-item" record types (like "Journal Article" or "Book Chapter") where the referenced item is only a part of the whole thing (e.g. a paper in a journal, or a chapter in a book). However, a report is comparable with a book in that it *is* the whole thing, though it may in turn be part of a larger series. So, for books and reports (or theses, maps, manuals, etc), the container info has to be put into the 'series_*' fields. So, if the report is part of a larger series, the series name should go into the 'series_title' field.
Unfortunately, for reports, the MODS series title doesn't seem to get recognized by Bibutils. Is it correct that, for @TechReport, Bibutils should put this information into the BibTeX 'series' field?
> The same holds for a given "volume" entry (which was entered when
> changing the citation type to "article".
If you put the book/report volume number into the 'series_volume' field, it should get outputted with the BibTeX export. Here's an example:
Exporting this record to BibTeX gives me this:
title="Guidelines for blending and handling motor gasoline containing up to 10\% v/v ethanol",
optlocation="refbase User (email@example.com)",
optnote="exported from refbase (http://demo.refbase.net/show.php?record=29789), last updated on Tue, 17 Feb 2009 14:58:38 +0100"
Besides the missing series(?) info, I agree that the contents of the 'corporate_author' field should not get added to the BibTeX author field. Instead, it should probably go into the BibTeX 'institution' field, right?
Btw, w.r.t. the 'corporate_author' field, there was a similar issue with BibTeX output of theses. For theses, the issue has been fixed in the refbase development version. See the second half of this thread:
We'd need to talk to the Bibutils developer and discuss this issue.
To convince Bibutils to output the BibTeX organization (or institution) field for reports, we might need to adopt a MODS name role that is supported by Bibutils, similar to the "degree grantor" role for theses. If the MODS record (which refbase passes to xml2bib) contains this:
<roleTerm authority="marcrelator" type="text">degree grantor</roleTerm>
Bibutils will put the name ("Concawe") into the BibTeX school field. This is correct for theses. However, for reports, Bibutils should probably put this information into the "institution" field, right?
Note to devs: Maybe we should always output the information in the refbase 'corporate_author' field with a MODS role of "degree grantor"? Or should we only do so if the refbase 'author' field is empty?
Hello again, Matthias,
in the meantime I switched back to english as the GUI language, so discussion on fields etc. should be easier. :-)
> So, for books and reports (or theses, maps, manuals, etc),
> the container info has to be put into the 'series_*' fields.
> So, if the report is part of a larger series, the series name
> should go into the 'series_title' field
Hmmm. Just a wild guess, but I expect the bibtex format to be the most detailed and elaborate. I don't think (and for OOo I am pretty sure) that any other format will deal with such a diversity of fields. So why not simply identify the form's entry possibilities with those supported by bibtex and leave the interpretation to its intelligence by exporting them 1:1?
I may understand your explanation for the moment, but for me being mainly concerned with the contents of the citations, it is rather annoying to keep such details in mind. For me, the charm of using latex/bibtex is the intelligence this system is applying by itself to yield a sensible citation formating just from the stereotyped field entries.
Interpretation of the fields as you pointed to creates only unneccessary overhead in the workflow, IMHO.
> To convince Bibutils to output the BibTeX organization
> (or institution) field for reports, we might need to
> adopt a MODS name role ...
Hmm, this gets way to much in the direction of programming for me. Even though I am quite open to some of that I'd rather not dig into it too deeply ... :-)
> Hmmm. Just a wild guess, but I expect the bibtex format to be the
> most detailed and elaborate.
No, this is not true. In fact, it is quite the opposite and BibTeX is today one of the more limiting bibliographic formats. It works well for the hard sciences, but is close to unusable for many other academic fields. This is also the reason why there have been several dedicated initiatives to rethink the BibTeX data model and its citation formatting system. CSL, Biblatex, MODS & Bibo are only a few of them.
There are many other bibliographic web databases which have been modeled very closely after BibTeX. However, with refbase we've always tried to cater to other users as well.
> So why not simply identify the form's entry possibilities with those
> supported by bibtex and leave the interpretation to its intelligence
> by exporting them 1:1?
Many before us have gone this route. I don't think this is the way to go. While this might ease things for BibTeX users, it ties the entire program to BibTeX (and all its limitations).
For sure, a working and full-featured BibTTeX output *is* important, but the data model shouldn't be based on it. In fact, we'd love to go the other direction and adopt a far more capable (hierarchical) data model. See e.g. this thread in the Zotero forums:
This has been discussed at length years ago. We still haven't done anything about it, though, since it is a major undertaking. It's always very hard to correct the mistakes of the beginning.
I understand that the refbase field entry form does not give enough guidance about which information has to go into which field. Other than that I don't think that your judgement is really fair. I've written my thesis with refbase & BibTeX/LaTeX, and it did actually work work out quite well.
refbase also has quite a few options and niceties especially geared towards BibTeX users:
> For me, the charm of using latex/bibtex is the intelligence this
> system is applying by itself to yield a sensible citation formating
> just from the stereotyped field entries.
I may be misunderstanding you, but isn't it similar with BibTeX that different record types have different required fields? The same is true for refbase. And actually I don't think it would pose a problem to you if refbase would give you more clues/guidance upon record entry/edit.
That said, if a 1:1 mapping between BibTeX fields and your web app's data model is truly important for you, then you might need to look somewhere else.
obviously I am not up to date with the developments of bibliographic systems, as you clearly pointed out. The approaches you mentioned all sound rather interesting - from an architectural point of view. As far as I just scanned them shortly, there is no concrete framework available that would i) allow for a practical distributed materials' entry, ii) produces any output directly digestible with common LaTeX systems, iii) would require less personal tinkering and additional maintenance of the "archive" in a more general sense of the word.
Therefore, even if I very well understand your leaning towards a more flexible, hierarchical data model I am rather glad that you got the flat one functional instead.
> I understand that the refbase field entry form does not give enough guidance
> about which information has to go into which field.
Indeed, it would be a great help if there were a mode showing the 1:1 correspondence, as long as it exists, just below the field names in the entry mask. Or, not to bias this mask too much in the direction of BibTeX, is there a written correspondence list that might be glued to the monitor rim? :-) Of course one might try to figure out, just by a trial-and-error approach, but I wouldn't regard that as a sensible approach.
> I've written my thesis with refbase & BibTeX/LaTeX, and it did actually work work
> out quite well.
I would not argue against that. As soon as one gets into this tinkering with the fields a bit, one gets a reasonable result. Which brings me to another question, though, after scanning the documentation for that in vain so far: There are times when I'd like to retrieve e.g. an author's list in exact the way it was entered, and not being modified by some computer scientific intelligence. For BibTeX original, this is achieved by defining such entries by double curly brackets. Is there a method to provoke such a behaviour for the BibTeX-exported items?
> isn't it similar with BibTeX that different record types have different required fields?
Yes, so it is. But entering additional ones does not change the interpretative behaviour for the important ones. Back to refbase this would mean for me that, regardless of the type of the entry the export to the BibTeX file should look the same (depart from the type identifier itself) with respect to any field defined in the mask. But I seem to remember that this is not the case, at least for the exemplaric "report" style exports. I'd just vote for leaving the field interpretation to the post-processing BibTeX. This is IMHO especially important for the cases where the different formatting styles (alpha, plain, ... [whatever you find in TeX's bst hierarchy]) include different fields in the actual output.
> And actually I don't think it would pose a problem to you if refbase would give you
> more clues/guidance upon record entry/edit.
Yes, I think it mainly boils down to this. It might even help to know the fields the BibTeX export is *not* considering and holding back.
Just a small annotation to the possibilities of user-defined adaption: I am quite accustomed to some tinkering and slight additional programming to get things the way I want them. But for refbase and the bibutils I just found no point where to bore my fingers into.
Thanks for the in-depth discussion!
Just another observation w/r/to available fields: I remember a "month" field in the common bibtex field list (even possibly a day field?) At least for Conferences I'd rather see this field to exist.
Is it so unimportant for other exports that it was omitted in refbase? At least the usual OO.o citation structure does administer it as well.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.