Corporate authors not parsed correctly in RIS import

Yes, I also noticed that none of the available specification information for the RIS format makes mention of this. Since we are upgrading our institutional software from Reference Manager 9 to Reference Manager 12, I've been trying to pin down all the RIS field definitions in order for us to have a single set of consistent fields that will allow moving citation data back and forth between RefMan 12, Biblio, and Zotero, using the RIS format as the medium for exchange.

One thing I've discovered is that the RIS specification file you reference has a couple differences from the specification detailed in the RefMan 12 User Manual available here:
http://www.refman.com/support/rm12man-terms.asp
(The same file is also available here):
http://library.tmu.edu.tw/eng/files/RM12.pdf

Looking at the most significant difference, for example, the file you've identified lists the tags for Custom/User fields as C1, C2, C3, etc. all the way up to C8. There is no U1 tag in this list. By contrast, the RM12 manual has a section about the RIS Format starting on page 581, and it does not include any C1-C8 tags. Its list of custom/user fields uses U1, U2, U3, up to U5. And in RefMan 12 itself, there are only 5 custom fields available. These U1-U5 tags are the ones that are currently used by the RIS import-export in biblio, and they match the ones listed here:
http://www.refman.com/support/risformat_tags_07.asp

Wikipedia uses the list of tags with the C1-C8 tags:
http://en.wikipedia.org/wiki/RIS_%28file_format%29

I think what has happened is that through their incompetence and their failure to keep anything up-to-date, Adept Scientific and Thomson ISI and their various alternate incarnations have left the specification for the RIS format somewhat in a state of disarray. Both versions would appear to be "official" descriptions of the RIS specification, and both are available from the www.refman.com website.

My current theory is that the the Direct Export RIS file you've identified is actually a rewriting of the RIS format based on how one or more versions of Endnote creates it, whereas the other version is the RIS format based on how Reference Manager exports it.

I was actually thinking that it should be possible to rework the RIS import-export file so that it would manage importing according to either version. But dealing with that can wait for another day...

In the immediate present, I just want to deal with the way that RefMan 9-12 exports its corporate authors. The instruction to use of the "=" sign appears on page 117 of the RM12 manual, though there is no mention of this in the RM12 manual's version of the RIS spec that starts on page 581. Regardless of whether it is in the spec, though, RM9 through RM12 all will include the equal sign in the RIS formatted export, and it is easy enough to remove it.

Following up on this issue, I've made some rough edits to both the biblio_contributors.inc and the biblio_ris.module files to get the import of corporate names to work correctly with RIS files produced by Reference Manager 9-12 (and probably earlier).

The general approach was to remove the equal sign as part of the custom parsing done in the biblio_ris.module and then to assign that contributor array a "literal" value of 1. Then over in the biblio_contributors.inc file I've added an extra case to the name parsing which will cause any contributor with a literal value of 1 to be treated as a corporate author.

When I started out, I began to fiddle with the author category and type fields, but I couldn't get these to respond easily the way that I wanted, and the new literal field just made everything easier.

biblio_ris.module in 6.x-2.0-rc2, lines 311-315:

    case 'AU' :
      $node->biblio_contributors[1][] = array(
                'name' => $data,
                'auth_type' => _biblio_get_auth_type(1, $node->biblio_type));
      break;

replace with:

    case 'AU' :
      // If author string starts with equal sign, assign literal value of 1, so it can avoid being parsed later
      if ($data[0] == "=") { 
        $data = substr($data,1);
        $node->biblio_contributors[1][] = array(
                'name' => $data,
                'auth_type' => _biblio_get_auth_type(1, $node->biblio_type),
                'literal' => 1);
      }
      else {
        $node->biblio_contributors[1][] = array(
                'name' => $data,
                'auth_type' => _biblio_get_auth_type(1, $node->biblio_type));
      }
      break;

Then do the same thing for case 'ED' and for case 'A3'.
Then make the following tiny edit to a core biblio file.

biblio.contributors.inc in 6.x-2.0-rc2, lines 502-508:

  if ($category_id == 5) {
    $author_array['firstname'] = '';
    $author_array['initials'] = '';
    $author_array['lastname'] = trim($author_array['name']);
    $author_array['prefix'] = '';
    // @todo: set suffix to empty string?
  }

replace with:

  // If category is 5 or if author_array includes literal field value of 1, treat as corporate author
  if ($category_id == 5 || $author_array['literal'] == 1) {
    $author_array['firstname'] = '';
    $author_array['initials'] = '';
    $author_array['lastname'] = trim($author_array['name']);
    $author_array['prefix'] = '';
    // literal field added here, based on similar inclusion in 7.x-1.0-rc4
    $author_array['literal'] = 1;
    // @todo: set suffix to empty string?
  }

Possibly the check for the literal field should be its own case, but this approach kept the edit of biblio.contributors.inc as small as possible. And it seems possible that this same approach could be used with other formats that use other indicators to record corporate author formatting, since the parsing of such special cases should largely be done in the formatter specific to that style. Any of them could then include the "literal" field to tell the biblio_parse_author script to ignore them.

Phil.