Hi,
the code in biblio_bibtex_export is likely from the Drupal 5 version because it switches on $auth['ct_id'] and doesn't honor the more powerful contributor data structure in D6.

The patch tries to correct this. If anyone wants to test you can e.g. create a book entry with a "Series Editor" author and then create the bibtex export. Should have an author and a editor entry.

CommentFileSizeAuthor
biblio_bibtex_export_author_and_editor.patch1.17 KBFrank Steiner

Comments

catdevrandom’s picture

catdevrandom commented

I just checked out the current CVS version, (biblio.import.export.inc 1.7.2.20 2008/11/19 21:54:20), and the exports (bibtex and all others) seem to be working without the patch.

After applying the patch, the exports were not showing the authors or editors fields. I guess Ron's latest changes had fixed the issue.

(I hope this helps, I have never contributed to any project before, and I am not always sure how to proceed. Let me know if there is any thing I should or should not do when doing this tests or bug reports).

Cheers!

Frank Steiner’s picture

Frank Steiner commented

Yes, this is against the version from 2008-09-24 which contains the code 

foreach ($pub->biblio_contributors as $auth) {
      switch ($auth['ct_id']) { 
        case 1 : ...
        case 2 : ...
     }
}

which does not work in 6.x. I guess Ron will mark this as fixed if it's already done in the latest CVS :-)

rjerome’s picture

rjerome commented

Actually, this is one that I didn't commit, since I was a bit suspicious of this ...

+      case 10: // Series Editor
+      case 14: // Editor
+	$e .= (!empty ($e)) ? ' and '. trim($auth['name']) : trim($auth['name']);

I'm not sure that those values (10,14) would be consistent across installations, they might just be an artifact of an "auto-incrementing" DB column, so I was going to investigate a bit further before applying this one.

Ron.

Frank Steiner’s picture

Frank Steiner commented

I must commit that I don't fully understand everything that's going on in biblio.install :-)
Here's how my table looks if that might help to see if it is the default or could have changed:

mysql> select * from biblio_contributor_type_data;
+-------+----------------------+------+
| ctdid | title                | hint |
+-------+----------------------+------+
|     1 | Author               | NULL | 
|     2 | Secondary Author     | NULL | 
|     3 | Tertiary Author      | NULL | 
|     4 | Subsidiary Author    | NULL | 
|    10 | Series Editor        | NULL | 
|    11 | Performers           | NULL | 
|    12 | Sponsor              | NULL | 
|    13 | Translator           | NULL | 
|    14 | Editor               | NULL | 
|    15 | Counsel              | NULL | 
|    16 | Name of File         | NULL | 
|    17 | Series Director      | NULL | 
|    18 | Producer             | NULL | 
|    19 | Department           | NULL | 
|    20 | Issuing Organization | NULL | 
|    21 | International Title  | NULL | 
|    22 | Recipient            | NULL | 
|    23 | Advisor              | NULL | 
+-------+----------------------+------+

Anyway, I guess we could also use some JOIN with this type_data table to compare against the fields title, assuming the "Editor" and "Series Editor" are fixed strings, maybe that's more reliable.

rjerome’s picture

rjerome commented

OK, now I'm really starting to show my age... I completely forgot that that table was being populated to that extent :-0

rjerome’s picture

rjerome commented
Status: Needs review » Fixed

This is now fixed, but I used a different approach. Rather than doing a db lookup for each author when exporting, I went back to where the author information was loaded into the node and added the ctdid at that point. This will eliminate many DB calls on a large export.

Frank Steiner’s picture

Frank Steiner commented
Status: Fixed » Active

Hi Ron,

just checked beta9, let me ask: Do you intentionally still export authors with ctdid 2 (Secondary Author) as Editors? As we have two ctdids especially for editor types (10/14), I think making secondary authors editors, too, could be confusing. I would vote for exporting the first 4 ctdids (Secondary/Tertiary/Subsidirary) as normal authors. What do you think?

rjerome’s picture

rjerome commented

Most of this mess is rooted in EndNote which is where this module started from. In EndNote, editors are put in the "secondary author" field. Endnote basically has 4 different classifications of authors (Primary/Secondary/Tertiary/Subsidirary) and for different types of publications each of those 4 generic author types can be called something more specific.

If you open the biblio.field.type.data.csv file in Excel (or some other csv type editor) you will see the mapping columns 8,9,10 have the non-generic author titles and columns 1 and 2 have the name and type id for the different types. All this mapping is basically straight out of EndNote, which is not to say it's right or good just what they use. So rightly or wrongly, I have subsequently tried to map other formats like bibTex and RIS onto this. Perhaps a more generic starting point would be a better solution.

Comments/suggestions?

deselaers’s picture

deselaers commented

Dear Ron, Dear all,

Personally, I have never heard of EndNote before I started using biblio. ;-)
I use only Bibtex. I believe that it is probably not necessary to go to anything more generic, but instead it would be good to provide a clear view of what is considered what in which format. If the description of the field says "Second Author for Endnote/Editor for Bibtex" I think it is perfectly fine.

Another example, where stuff is handeled differently are dates: In Bibtex you normally only specify the month for journals and "inproceedings" (which is commonly conference papers). ... oh btw. some time ago I put a hacky patch for this somewhere into an issue... and in endnote, you specify the full dates.

Thus, I believe that it is probably fine to keep the stuff in an endnote-alike fashion internally and only change the import/export filter accordingly.

Once I have a bit more time, and am well-networked, I might put some more effort into the Bibtex export.

Cheers,
thomas

Frank Steiner’s picture

Frank Steiner commented

I think if biblio provides two explicit editor types, "Editor" and "Series Editor", no bibtex user would expect secondary authors to become editors, too. I didn't know this was implicit in Endnote.

Another problem is that tertiary or subsidiary authors aren't exported as authors at all in bibtex at the moment. We do have classifications of up to three different author types for a paper, while all of them are indeed authors that should show up in a bibtex entry. We just need those different types for formatting the output (like we currently format primary authors bold and secondarys normal).

So, maybe we could indeed rename "secondary author" into sth. like "Editor (Secondary author)" (and drop author type 10) and keep that special handling for type 2. But it would also be good if we could export author types 3 and 4 as bibtex authors, too (I'm currently doing this via my bibtex hook patch).

And, yes, I also changed all the titles for biblio_date into "Month", too :-)

bekasu’s picture

bekasu commented
Status: Active » Fixed

original issue appears to be fixed.
issue was hijacked for a secondary topic.
I'm marking this fixed.
If you want to pursue the other topic, please start a new issue.

bekasu

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.