How to add a new field to biblio table

marking closed.
bekasu

The documentation states that a new field can be added to a publication type:
http://drupal.org/node/260391

..but I see nothing in the interface that allows for adding additional fields, please help!

This is with 6.x-1.14. If I need to post this elsewhere, please let me know.

I would like to add custom Common fields to Administer › Site configuration › Biblio settings > Fields (common) or be able to edit the common field names to that form. The predetermined fields ("biblio_xxx) are woefully inadequate. The seven "biblio_customX" fields are too few.

Anybody know how to do this?

You state

The predetermined fields ("biblio_xxx) are woefully inadequate...

Which seems rather harsh given that there are over 50 fields. Would you care to elaborate as to what is missing?

In terms of adding "data" fields, you cannot currently do that through the user interface. The fields referred to in comment #2 are publication types, not data fields within a given type.

You could add extra fields with CCK, but they will not be included in any of the bibliographic style functions.

Ron.

First, thanks Ron for the quick reply, it's very appreciated! The biblio module is a very nice tool!

In the documentation link I referred to, it says:

"You can add either additional fields to existing types (for example, Publication Language or Edition to a Journal article)".

This does not seem to be the case from what you stated. If this is accurate, how would you add an edition field, for example, to a Journal Article?

It would be great in future versions to have the ability to add additional fields to the Common or individual Publication Types. If this is technically a bit too difficult based on the database structure, then the next best option would be to have more custom fields, say maybe 30 total.

I looked into editing the database structure directly, but held off because of possible future upgrade issues.

Thanks,
Brent

The journal article type already has an addition field associated with it, and the actual data is stored in the biblio_edition field.

If you go to the 'admin/settings/biblio/fields/type/edit/102' page you will see a complete list of all the fields.

In terms of users adding fields, it gets complicated, not so much from a database point of view, but a citation formatting point of view since the citation processor needs to be aware of these fields and where they fit into the citation.

I would hazard a guess that the 7.x version will eventually reach these goals when it has been converted to use the Fields API.

Ron.

Yes, I would like to explain, thank you.
They are inadequate due to their fixed pre-determined nature. It would be nice to be able to change the pre-determined Drupal field name in some cases. We have a bibliography (NLS Bibliography: http://www.nlsbibliography.org/) whose fields cannot be compressed into the Drupal structure. For example: we use nine different Cohorts to organize the citations in our bibliography for our users because users only want articles on their cohort of interest. Drupal does not allow me to change, for example, "biblio_custom1" to mneumonically correspond to "cohorts". I can label "biblio_custom1" to "Cohorts" thus mapping it for import, but it appears to me I have to keep a list of which Drupal fields (biblio_xxx) are mapped to our fields.

We publish abstracts in our bib., whenever possible, and some abstracts are copyrighted. We, therefore, keep a detailed table of publisher's addresses (Drupal provides 1 field for "address" consisting of mostly City, State). We need to contact publishers to ask permission to print their abstract so we have email, fax, street, city, state, country, permission to publish, etc. for each and every publisher. In addition, we provide a URL link to the publishers' web sites.

Because commercial publishers publish multiple journals and other media like books, reports, working papers, etc., an individual cannot remember who publishes what journal, so when a journal article is added to the db, we keep a list of links from the journal to the publisher so that the publisher's name is filled in after the journal is entered. Why do I want to map (label) biblio_call_number (or some such Drupal field) to "journal_publisher_links"? We don't use many of the common pre-determined fields Drupal uses.

When all is imported, and for maintenance and coding purposes, how does one keep track of which Drupal field name corresponds to "our_field_name"? It seems to me one has to keep a list of all fifty Drupal fields and what they map to.

In addition, I have found that "biblio_lang" cannot be mapped. If "biblio_lang" appears in PARSEENTRIES.php it always auto-fills to 'eng'. We have about 45-50 fields that need to be mapped and we only use one of the biblio_xxx_authors fields.

There are more examples, but this should be enough. Thank you for your time.

You obviously have an extensive database built already, are you looking to convert this to a Drupal based system?

I think that you could handle your cohort issue using taxonomy tags and filtering on those tags, but you are quite right there are some other areas which couldn't immediately be handled. If your organization is interested in funding some development toward that end, I would be happy to entertain this dialog out of the issue queue via email.

Best regards,

Ron.

Thanks, Ron, for the quick response.

As for conversion, yes, we are beginning the process of converting to a Drupal based system. After your comments we have made a few compromises on what we input and are proceeding with the tests. We had hoped that we could make Cohorts an indexed search like Author, Title, Type, Keywords.

I am thinking (and hoping) that we can add the Cohorts to the keywords and filter them in some way to be a search unto themselves. Thanks for the "taxonomy tags and filtering on those tags" suggestion. We will have to explore it when we have reached that state in the process.

Your help is much appreciated.

Using taxonomy for cohorts, you are effectively making it an indexed search, there would just be a little plumbing required to make it happen.

It just occurred to me that rather than using the default biblio displays, you could use the Views module to generate your output, and Views has the concept of "Jump" menus which could be populated with your taxonomy "cohort" list and used to filter the output.

Regards,

Ron.

This version is no longer maintained. If this issue is still relevant to the Drupal 7 version, please re-open and provide details.