custom fields in db

roberto
2011-11-20
2013-05-28
  • roberto
    roberto
    2011-11-20

    Hi all.
    I'd like to insert custom fields into DB, and in search and display forms, too. I have to manage customized search in language fields, allowing users to operate custom search over non standard language variants. This language variants have to be inserted by the cataloguer before, and must allow multilevel search. e.g. Language ABC, could have more subtypes like ABCD, ABCF, ABDE and so on.
    best regards

     
  • Integrating custom fields is fairly tricky & it will be even trickier to get the sort of complex interface you desire.  But please keep us informed of your progress & let us know if you have any specific questions that we can answer.

     
  • roberto
    roberto
    2011-11-29

    Yes it was already clear it would not be quite easy, but I can't find any further information about how I can manage my request. Do you know some useful links helping me in solving my issues? I really need to insert custom fields into DB; I'm not looking for help regarding MySQL matters but for integration with Refbase.

     
  • There is no documentation on adding custom fields, as it is very advanced.  The few users who have done this have all done it themselves.  Matthias did an outstanding job in documenting the codebase, so this will be the only real cue as to what needs to be changed to integrate your new field into refbase.  If you search the source for fieldnames that are already in refbase, you will start to get a better idea of what needs to be changed.

     
  • Hi robmor,

    as Rick mentions, adding custom fields & making appropriate GUI changes will be quite tricky. I'd be willing to help you with this, but it'd probably be a pretty time-consuming process on both sides. Thus I'd first like to better understand your use case.

    I must say that I haven't really understood what you're ultimately trying to achieve. Could you give us a more detailed description and some examples about your envisioned application workflow? We may then be able to give you better advise. It may be also possible to repurpose some of the existing fields (which would probably be *much* easier to implement).

    So, here are some questions:

    - How many (or what kind of) language fields do you need? And what are they supposed to contain?

    - What is a "custom search"? I.e. what are your specific search requirements?

    - Similarly, what is a "multilevel search"?

    Could you give us some concrete examples of the required data and searches?

    Thanks, Matthias

     
  • roberto
    roberto
    2011-11-29

    Hi all, really thank you for helping me.
    the following is an extract of the XML file I'm using to export data from actual Oracle DB, generate Bibtex file and finally import it into MySQL.
    <SW4>Cazet idiom</SW4>
    <SW4>Talian</SW4>
    <SW5>Cazet Mundart</SW5>
    <SW5>Italienisch</SW5>
    In this section there are 4 custom defined fields, simulating languages (Cazet idiom ; Talian ; Cazet Mundart ; Italienisch), they do belong to 2 different groups (SW4 ; SW5).
    It could be that a single entry in DB has one, two or more groups like this. For each group there could be one or more languages.
    'Cazet idiom' <- could represent the so called "mother group"
    'Talian' <- is "child" of 'Cazet idiom', but not of  'Cazet Mundart'.
    A user visiting the bibliographic system, could whish to sort data selecting all records belonging to group SW4 , but also going further could ask the system to filter only records belonging to the group 'Talian'. This is what I mean for multilevel search.
    Regards

     
  • roberto
    roberto
    2011-11-29

    Another example could be the following:
    a user could search into the system for all entries in german language, but could also whish to apply a further selection in order to retrieve only all entries related with a specific german dialect

     
  • Hi robmor,

    unless I'm (still) misunderstanding your use case, I believe that many of your goals could be achieved with refbase without modification. Depending on your users and your requirements, this might not be the best solution from a usability point of view, but you'd save yourself a ton of work.

    My suggestion would be to start with a simple string-based compound field that would list all your language data as a compound string. Multiple language groups would be separated from with each other with a special character. And within each language group, individual languages would again be separated with a (different) special character. Example:

    Cazet idiom: Talian; Cazet Mundart: Italienisch

    This would then be very similar to how refbase handles other "multi-item" fields, such as the 'author' and 'keywords' fields.

    My suggested workaround won't work for clever sorting, but (multi-level) filtering and autocompletion of existing languages (mother group or child names) on search & edit would work just fine.

    You could use refbase's 'language' field for this but I'd suggest to start your tests with the 'area' field since (among other things) this field can be easily made available in the "Quick Search" form. Whichever field you'll use, you can rename that field in the interface to something more appropriate.

    To test whether refbase's default (multi-level) filtering and autocompletion features would work for you, you could:

    1. Log into http://beta.refbase.net/

    2. Click on the "Options" link (in the upper right of the screen), then on the "edit options" icon next to the "Display Options" label.

    3. In your Display options, under "'Main fields' searches", make sure that the "area" field is selected in the multi-select box, and press the "Submit" button (if you've changed anything).

    4. Now, choose the "area" field from the dropdown in the "Quick Search" form (which is available at the upper right in the page header on every refbase page), and enter some text (e.g. "sea"). Notice how refbase offers search suggestions. Click the "Search" button (without selecting any of the provided suggestions).

    5. Notice that (when searching in "List View") refbase has automatically added the "Area" column to the list of displayed columns. So it's easy to sea your search results.

    6. Now click on the the "Search & Display Options" link (above the search results). Among other forms, this will display the "Search within Results" form. The "area" field should already be selected in the dropdown. Enter some text in the text entry field of the "Search within Results" form (e.g. "Finland") and click the "Search" button.

    This last step shows you how you can effectively filter the results list multiple times (and using multiple fields if desired). It's also possible to exclude the matched records from the list of results.

    Btw, the contents of the "area" field could be also displayed in Citation view (in the additional info that can be displayed by clicking the triangle widget underneath each citation).

    Do you think that such a workflow could work for you?

    Matthias

     
  • roberto
    roberto
    2011-12-05

    Hi Matthias
    I tried following all the steps and it works greatly; at worst it could be the last solution.
    If I'm not wrong, Refbase allows me to manage data using the so called string-based compound field in specific search fileds like  'author' and 'keywords', but also in 'language' field. This would not be the case of other fields like 'area' in the above example?
    In addition to the previous solution, do you think I could work in the following manner:
    1. rename one of the existing fields; like 'Expedition', it could become 'dialect'
    2. work with field settings in order to enable the deepest level of searching as possible
    3. publish it in the 'simple_search.php' page with its appropriate dropdown menu
    Regards
    rm

     
  • Hi robmor,

    by default, the 'area' and 'expedition' fields do also accept "multiple elements" (separated by a semicolon character), similar to the 'author', 'keywords' and 'language' fields. I.e., the 'area' and/or 'expedition' fields should work fine for your case out of the box.

    By default, search suggestions are generated from the contents of the 'language', 'area' and 'expedition' fields by splitting its contents on these characters:

    ,;()/

    This split pattern could be modified in variable '$splitPattern' (in file 'opensearch.php').

    Taking your previous example, the following formatting should work out of the box in conjunction with the refbase search suggestions:

    Cazet idiom (Talian); Cazet Mundart (Italienisch)

    I.e. the search suggestions feature would split this string into these subelements:

    Cazet idiom
    Talian
    Cazet Mundart
    Italienisch

    > 1. rename one of the existing fields; like 'Expedition', it could become 'dialect'

    W.r.t. renaming: To rename the 'area' or 'expedition' field in the interface, search for "area" or "expedition" in the 'common*.inc' files in the refbase 'locales' subdirectory and rename all occurrences to suit your taste.

    That said, I'm a bit confused: Wouldn't splitting your data across two fields lose the relationship between mother groups and children? I.e. it's not clear anymore which child belongs to which group. Example:

    A. Language information provided in a single field:
        Cazet idiom (Talian); Cazet Mundart (Italienisch)

    B. Language information provided in two separate fields:
        Cazet idiom; Cazet Mundart
        Talian; Italienisch

    Or did you mean to distribute the data differently across the two fields?

    > 2. work with field settings in order to enable the deepest level of searching as possible

    I'm not sure what you mean by this. There's no "deepest level of searching" in refbase. You can drill down as much as you like, i.e. theoretically your query can be refined endlessly, filtering your results (using the "Search within Results" feature) again and again and again… There may be a practical limit to this (due to the length of the query URLs) but I'd ignore this for now.

    > 3. publish it in the 'simple_search.php' page with its appropriate dropdown menu

    I'm not sure whether "Simple Search" is your best search entry point. As described previously, I think that Quick Search (followed by a "Search within Results") is far easier and much more powerful. And it works for your case right out of the box.

    That said, you could see how things are done in the 'advanced_search.php' script, and adopt 'simple_search.php' (and function 'extractFormElementsSimple()' in file 'search.php') accordingly. On the "Advanced Search" page, the 'area' field does already have a dropdown menu which lists all unique existing values. You could provide something similar on the "Simple Search" page, or even a dedicated "Language Search" form on the main page.

    Hope this helps,

    Matthias

     
  • roberto
    roberto
    2011-12-06

    Hi Matthias
    your contribute really helps me.
    The solution of splitting contents using special chars could be suitable; even if I'm facing now with another issue: I need to import data into MySQL DB via a bibtex file, in order to know the exact names of each field I operated some bibtex export starting from http://beta.refbase.net/ and used the fields to write my bibtex file.
    Firstly: do you know some online links for complete whole fields mapping?
    Secondly: an export of an actually present record is the following:

    @Article{Aimetti_etal2005,
    author="Aimetti, M.
    and Romano, F.
    and Priotto, P.
    and Debernardi, C.",
    title="Non-surgical periodontal therapy of cyclosporin A gingival overgrowth in organ transplant patients. Clinical results at 12 months",
    journal="Minerva Stomatologica",
    year="2005",
    volume="54",
    number="5",
    pages="311--319",
    optkeywords="Adult",
    optkeywords="Aged",
    optkeywords="Cohort Studies",
    optkeywords="Cyclosporine/*adverse effects/therapeutic use",
    optkeywords="*Dental Scaling",
    optkeywords="Female",
    optkeywords="Follow-Up Studies",
    optkeywords="Gingival Hyperplasia/chemically induced/*therapy",
    optkeywords="Heart Transplantation",
    optkeywords="Humans",
    optkeywords="Immunosuppressive Agents/*adverse effects/therapeutic use",
    optkeywords="Kidney Transplantation",
    optkeywords="Liver Transplantation",
    optkeywords="Male",
    optkeywords="Middle Aged",
    optkeywords="Oral Hygiene",
    optkeywords="*Organ Transplantation",
    optkeywords="Periodontal Index",
    optkeywords="Postoperative Complications/chemically induced/*therapy",
    optkeywords="Self Care",
    abstract="AIM: The aim of the present study was to evaluate the clinical 
    
    improvements for prolonged time period.",
    optnote="PMID:15985985",
    optnote="exported from refbase (http://beta.refbase.net/show.php?record=7572), last updated on Sat, 23 Jan 2010 09:15:08 +0100",
    issn="0026-4970",
    opturl="http://www.ncbi.nlm.nih.gov/pubmed/15985985"
    }
    

    Even if in refbase the field language is present, in the export is missing. How could I work on the contrary? Which is the coded 'language' entry where I should put my special-chars  formatted language string?

    According to solution 1 (rename one of the existing fields) loosing mother-child relationship is not suitable for my purpose, except if distributing data differently accross two fileds accomplish my request…. Do you think it could work? 'Cazet idiom' and 'Cazet Mundart' should be writen into 'dialect' field and 'Talian' and 'Italienisch' should be written into 'language' field. or?

    W.r.t solution 2 for deepest level of searching, I mean that once the user operates first search restrinction by applying 'Cazet Mundart' filter,  he/she goes on by selecting only records referred to 'Italienisch'

    The idea to publish it in the 'simple_search.php' page with its appropriate dropdown menu is related with user searching habits, if someone is used to manage researchs using the 'simple_search.php' page he/she would miss the oportunity to operates researchs on languages

     
  • Hi robmor,

    the following pages in the refbase online documentation contain links to sample import/export files:

    http://import.refbase.net/
    http://export.refbase.net/

    By default, refbase supports import of language information for these formats: ISI, Medline, RefWorks, SciFinder. Import of BibTeX and MODS XML is provided by the bibutils tool, which is thus harder to customize. Also, I could be wrong but I don't think that the standard BibTeX format offers a language field.

    refbase has good (native) support for the RIS format, and in most cases, it's easiest to go with RIS. I'm not sure how much effort you've already put into converting your data to BibTeX. If you're just at the beginning, I'd advice you to try the RIS format instead.

    Although the refbase RIS importer doesn't support the RIS "LA" field for "language" (I don't think that the RIS spec did list this field when the refbase RIS formater was build), it's very easy to add: Open file 'includes/import.inc.php' and search for the first occurrence of variable '$tagsToRefbaseFieldsArray'. Inside that field mapping array, search for the line that ends with "language", enter LA between the first two quotation marks, and remove the two slashes at the beginning of the line. The line should then look like this (leading tabs omitted):

    "LA"  =>  "language",
    

    Then, in your RIS records, add a line for the language info, prefixing the language name with "LA", then two spaces, a hyphen and another space. Example:

    LA  - French
    

    The imported data should now include the language information.

    According to solution 1 (rename one of the existing fields) loosing mother-child relationship is not suitable for my purpose, except if distributing data differently accross two fileds accomplish my request…. Do you think it could work? 'Cazet idiom' and 'Cazet Mundart' should be writen into 'dialect' field and 'Talian' and 'Italienisch' should be written into 'language' field. or?

    I must admit that I still don't really understand your ideal solution and your question. Could you please try again to describe your ideal solution? To me it looks as if you'd like to split your language information between two separate fields, but I don't see how you'd then be able to maintain the relationships between the language elements in these two fields. Also, I don't understand why a single field wouldn't work for your use case. Can you clarify?

    W.r.t solution 2 for deepest level of searching, I mean that once the user operates first search restrinction by applying 'Cazet Mundart' filter,  he/she goes on by selecting only records referred to 'Italienisch'

    This is exactly how the refbase "Search within Results" feature works, so I'm again not sure what you mean. You can refine your search results (using the "Search within Results" feature) as often as you like. Unless I'm misunderstanding you this should be a perfect match for your use case.

    W.r.t. the customization of 'simple_search.php', I'd suggest to use the Quick Search form for now, and get everything else implemented first.

    HTH, Matthias

     
  • roberto
    roberto
    2011-12-08

    Hy Matthias
    I'm following your suggestions and everything works fine. Importing via RIS format allows me to specify languages  "multiple elements" (separated by a semicolon character). I have noticed that the

    2. Click on the "Options" link (in the upper right of the screen), then on the "edit options" icon next to the "Display Options" label.
    3. In your Display options, under "'Main fields' searches", make sure that the "area" field is selected in the multi-select box, and press the "Submit" button (if you've changed anything).

    is bound to the user profile, this means that each new user should follow the procedure to enable the "Display options". Or? I si possible to enable this setting by default for every new incoming user?
    Moreover I have noticed that in the ' "Main fields" searches ' list the 'Language' field is not listed,

    3. In your Display options, under "'Main fields' searches", make sure that the "area" field is selected in the multi-select box, and press the "Submit" button (if you've changed anything).

    as you suggested:

    You could use refbase's 'language' field for this but I'd suggest to start your tests with the 'area' field since (among other things) this field can be easily made available in the "Quick Search" form.

    is it possible to insert it into the view?
    And also to enable it as default for everyone?
    Regards
    RM

     
  • roberto
    roberto
    2011-12-08

    Hi Matthias, once again…
    I'm now considering RIS import. As you mentioned for the  "LA" field for "language" I have to edit the '$tagsToRefbaseFieldsArray'.
    I'm trying to import also filds like :

    "DO"  =>  "doi", // Digital Object Identifier
    "AN"  =>  "Accession Number", // Accession Number
    

    but Refbase seems to ignore them, the import operation ends but no result is displayed.
    Do you know some good RIS documentation? I'm reading that available on: http://www.refman.com/support/risformat_intro.asp but not all fileds are covered in deep.
    Regards
    RM

     
  • is bound to the user profile, this means that each new user should follow the procedure to enable the "Display options". Or? I si possible to enable this setting by default for every new incoming user?

    You can use SQL to batch update all current users.  You can edit $defaultMainFields in 'initialize/ini.inc.php' to apply to new users. 

    Moreover I have noticed that in the ' "Main fields" searches ' list the 'Language' field is not listed,

    Edit $availableMainFields in 'initialize/ini.inc.php' accordingly.

    is it possible to insert it into the view? And also to enable it as default for everyone?

    The two variable, given above, are all that you'll need to edit.

    -Rick

     
  • refbase has no "Accession Number" field.  Your code should lead to a SQL error.  If you have full error logging enabled (which you really should for development), you should be able to see that this fails.  The line for the DOI looks fine.  Note that the RIS specification has only recently formalized these new fields.  refbase should, perhaps, be modified to accept the DOI field.

     
  • roberto
    roberto
    2011-12-09

    Hi Rick, thanks for all the suggestions related with PHP variables.
    At this point I have following problems:
    1) data format for import:
    Bibtex is not suitable because of the missing 'Language' field and in RIS format I don't know where to store ID numbers.
    I was working around the MODS XML because it seems more complete, in the tags <mods version="3.2" ID="ref99999999"> and <identifier type="citekey">ref99999999</identifier> I can insert the requested data. The ID!
    This because I have to manage cross-referencing among records, where there is a mother-child relation for volumes series publications. Even if it seems once records are imported into Refbase they are not browsable via internal link. There is only a reference to the main, or sub, title.
    2) inserting user defined fields into DB
    lastly I think I should create new fields, as mentioned in original message, because I have to manage something that is really not related with a stadard litterature database: the subjects. I have to relate each record to its own specific subject, and the subject must be inserted into a DB field. This is really a mess because I could not avoid this feature, the bibliography I'm going to create must respect this constrain. I have to create also a form to insert, edit and delete subjects, because they also have to be inserted and displayed in the language of the user.

    Really thanks for helping me.
    Regards
    RM

     
  • Hi robmor,

    in RIS format I don't know where to store ID numbers.

    The RIS format offers an 'ID' field, which is mapped by refbase to the refbase 'call_number' field (note that, if no other RIS field gets mapped to the refbase 'cite_key' field, the contents of the 'call_number' field will also be copied to the 'cite_key' field of the currently logged-in user).

    The 'call_number' field is meant to store a user's personal reference number that uniquely identifies this record for the user. So it seems like a good fit to me.

    I have to manage cross-referencing among records, where there is a mother-child relation for volumes series publications.

    While refbase doesn't generate links for cross-references automatically, refbase offers a user-specific 'related' field that allows you to link records with each other. More info here:

    http://www.refbase.net/index.php/Relating_records_to_each_other

    After successful import, it might be possible to perform a batch SQL update query in order to generate these cross-links (semi-)automatically.

    I have to relate each record to its own specific subject

    IMHO, this wouldn't really require you to create a new database field. Unless I'm misunderstanding you, subjects are just like special keywords, right? The 'area' field is meant exactly for that purpose.

    I have to create also a form to insert, edit and delete subjects, because they also have to be inserted and displayed in the language of the user.

    Now, this might be a bit trickier to achieve with the current setup, but it might not be impossible.

    Do I understand you correctly that every "subject" should be displayed in the user's preferred language, but that these different translations effectively point to the same subject? In that case, it would make sense to let the user add, edit or remove the translated subject headings, but convert these to their internal standard representation (e.g. the appropriate english subject heading, or a subject ID) upon submit. So the database would only store the internal standard representation, but convert these on the fly for display & editing purposes. If so, this should all be feasible with a single existing field, e.g. the 'area' field.

    I'm still not convinced that you'd really must need to add new database fields, and if possible I'd strongly advise against that, since (as mentioned previously) you'd need a sound understanding of refbase's internals to get things right.

    HTH, Matthias

     
  • roberto
    roberto
    2011-12-09

    Hi Matthias
    thank you.
    regarding following point:

    The 'area' field is meant exactly for that purpose.

    do you mean by using the already seen multiple elements (separated by a semicolon character)?

    I've seen that in MODS XML the keyword field is exported as following:

        <subject>
                <topic>Deep-sea</topic>
            </subject>
            <subject>
                <topic>Pulse-chase experiment</topic>
            </subject>
            <subject>
                <topic>[delta][super:13]C</topic>
            </subject>
    

    subjects are just like special keywords

    Yes right. An example could be :

    Übersetzung ; Leben ; Heiliger

    all these 3 german words describe a single record, there could be only one word, two or at maximum three. Not only those in the above example, for sure!
    The idea to separate them through a semicolon could be a sort of escape, but it would be better to use something like a scrolling menu; for this reason I meant to create a form for editing the subjects

    it would make sense to let the user add, edit or remove the translated subject headings, but convert these to their internal standard representation

    in the case that a user is browsing the literature database in english, the above subjects should be displayed as :
    Translations ; life ; saints
    To convert them on the fly could be suitable, but how does it work? where does Refbase stores the translations? how to insert them? In the case that the solution would be to store them in an external file like the common_utf8.inc it would not be unfortunately acceptable.
    Really thank you
    RM

     
  • Hi robmor,

    w.r.t. the 'area' field being suitable for your purpose you asked:

    do you mean by using the already seen multiple elements (separated by a semicolon character)?

    Yes, the 'area' field works similar to the 'keywords' field and should thus work fine for multiple "subject keywords".

    The idea to separate them through a semicolon could be a sort of escape, but it would be better to use something like a scrolling menu; for this reason I meant to create a form for editing the subjects

    I agree that a dropdown menu (for *adding* of subjects) could help your users to discover the available subject headings. But, as is the case for keywords, a field containing a textual representation (like: "Übersetzung; Leben; Heiliger") would still be beneficial, since the user could easily copy and paste multiple subjects at once. And, of course, there's also autocompletion to help with data entry. So, IMHO it might be best to combine these two approaches, i.e. have a string-based field for your subject headings and (in addition) offer a popup menu (via Javascript or the like) which lists all the available subject headings. The latter would need to be programmed by yourself.

    Speaking of translations:

    To convert them on the fly could be suitable, but how does it work?

    I didn't mean to imply that the translations would be stored in refbase's 'common*.inc' files. Instead, you'd need to program this yourself. E.g. you could add an additional script which lets a user (or admin) manage the subject headings. Then, on edit dynamically query this list of subject headings and present the list inside a popup menu for the user to choose from. The chosen subject headings would get inserted into the (string-based) field. Of course, this is just an example, there are many ways how to do that. It's up to you. :-)

    Matthias

     
  • roberto
    roberto
    2011-12-10

    Hi Matthias, some finally questions.

    Yes, the 'area' field works similar to the 'keywords' field and should thus work fine for multiple "subject keywords".

    why not to use only the 'keywords' field ? At this point there seems not to be a great difference between two, or ther's something missing in my understanding?

    have a string-based field for your subject headings and (in addition) offer a popup menu (via Javascript or the like) which lists all the available subject headings

    do there are some examples somewhere, from which I could start ? or some suggestions how and where to include external scripts into Refbase?

    you could add an additional script which lets a user (or admin) manage the subject headings. Then, on edit dynamically query this list of subject headings and present the list inside a popup menu for the user to choose from

    same as above, do you have some experience with something similar? I gave a look to the forum discussions but did not find something usefull.

    Lastly, regarding RIS inport/export format: I tryed exporting one ex the recrods in Refbase online demo, the "Deep-sea macrofauna exposed to a simulated sedimentation event…", the exported RIS file contains

    ID  - Aberle+Witte2003
    

    while expected was something like:

    Call Number refbase @ user @ 706
    

    or probably simply 706
    On the contrary while importing from RIS file the field ID is properly recognized

    Instead  the 'area' field is not mentioned in the RIS export

    Area    NE Atlantic
    

    simply disappear.
    I looked into http://en.wikipedia.org/wiki/RIS_(file_format) but there's no mapping of the field 'area', the same in http://www.refman.com/support/risformat_intro.asp

    Regards
    RM

     
  • roberto
    roberto
    2011-12-10

    Hi

    refbase offers a user-specific 'related' field that allows you to link records with each other. More info here:
    http://www.refbase.net/index.php/Relating_records_to_each_other

    it works fine, but which is the RIS field that I have to fill in order to manage the relations? I tryed to export a record containing a link to another one but no RIS field appears in the file, just as for 'Area' field

    thanks

     
  • Hi robmor,

    w.r.t. the 'area' field you asked:

    why not to use only the 'keywords' field ?

    You could, of course, also use the 'keywords' field for your purposes. However, normally, the 'keywords' field is already used for regular keywords (i.e. keywords supplied by the publication's authors or the database vendor, or general/public keywords provided by the refbase user). If you have no other use for the 'keywords' field, then, yes, it would be an even better match. This is especially, since the 'keywords' field is included with many export formats.

    W.r.t. any required custom programming you asked:

    do there are some examples somewhere, from which I could start ?

    Not that I'm aware of. If I were you I'd start without these customizations and see how things go (i.e. gather some user feedback first). But these seem to be important to you. Since this is generic web programming, you could have a look at some examples for the jquery or prototype JavaScript libraries, or some web programming tutorials that handle forms & database I/O.

    When you have the basics working, we are, of course, happy to help you with integrating these modifications into the refbase edit form. But the basics are really independent of refbase. You need a script to enter & store your subject data, and have another function (JavaScript or PHP) that queries your subject data, builds the subject list and finally creates the popup menu.

    To see an example on how to gain the look of refbase's script pages, look at e.g. 'duplicate_manager.php' script. This script has only few custom parts and shows you the general structure of a refbase script with a form interface.

    W.r.t. the export to RIS (or other bibliographic formats), you should be aware that these are *standard* formats, i.e. we haven't invented these formats (many of them were designed a looong time ago) and thus there's no perfect field mapping between refbase fields and, say, RIS fields. There isn't a standard bibliographic format that supports all of refbase's fields. MODS XML may come close, but still not all data can be exported (or imported) exactly.

    Many of the old standard formats (like RIS, Endnote tagged or BibTeX) have only one ID field, but refbase has several kind of ID's (it's internal database 'serial' number, the user's 'call_number', and the user's 'cite_key'). So, on export refbase has to decide which IDs are most important to the user and thus should get exported. Usually, this is the user's cite key since this is used for citation purposes. Thus, the exported RIS ID field contains the refbase cite key.

    Btw, the MODS XML format has the possibility to include several record identifiers, and the contents of the 'call_number' field are exported to MODS XML in the '<identifier type="local">' field.

    W.r.t the 'area' field: this is a refbase-specific field and thus (for the reasons explained above) doesn't occur in the exported formats by default. However, it may be possible to modify the export routines, so that this field gets exported as well (to, say, the RIS keywords field). If you put your subject headings into refbase's regular 'keywords' field, then export of these data should work out of the box.

    which is the RIS field that I have to fill in order to manage the relations?

    Unfortunately, there is no RIS field for this. Therefore, I wrote previously:

    After successful import, it might be possible to perform a batch SQL update query in order to generate these cross-links (semi-)automatically.

    I.e. the relationships would need to be established from another field (e.g. the 'call_number' field) after import using a batch SQL query. Depending on your requirements, this could be easy, or pretty tricky. I'd need to have an concrete example, to give you more advice.

    HTH, Matthias

     
  • roberto
    roberto
    2011-12-15

    Hi Matthias, as agreed the example follows in two formats, MODS XML and Bibtex:

    The mother (bibtex):

    @book{324225252,
    Author = {Knuth, Donald E.},
    Note = {Seven volumes planned (this is a cross-referenced set of BOOKs)},
    Publisher = {Addison-Wesley},
    Series = {Four volumes},
    Title = {The Art of Computer Programming},
    Year = {1968}
    }

    The child (bibtex):

    @book{book-crossref,
    Crossref = {324225252},
    Edition = {Second},
    Note = {This is a cross-referencing BOOK},
    Series = {The Art of Computer Programming},
    Title = {Seminumerical Algorithms},
    Volume = 2,
    Year = {1981}
    }

    The mother(MODS XML):

    <?xml version="1.0" encoding="UTF-8" ?>

    <modsCollection xmlns="http://www.loc.gov/mods/v3">
    <mods version="3.2" ID="ref324225252">
    <titleInfo>
    <title>The Art of Computer Programming</title>
    </titleInfo>
    <name type="personal">
    <namePart type="family">Knuth</namePart>
    <namePart type="given">D.E.</namePart>
    <role>
    <roleTerm authority="marcrelator" type="text">author</roleTerm>
    </role>
    </name>
    <originInfo>
    <dateIssued>1968</dateIssued>
    <publisher>Addison-Wesley</publisher>
    <issuance>monographic</issuance>
    </originInfo>
    <language>English ; German</language>
    <note>Seven volumes planned (this is a cross-referenced set of BOOKs)</note>
    <typeOfResource>text</typeOfResource>
    <identifier type="citekey">ref324225252</identifier>
    <genre authority="marcgt">book</genre>
    <relatedItem type="series">
    <titleInfo>
    <title>Four volumes</title>
    </titleInfo>
    </relatedItem>
    </mods>
    </modsCollection>

    The child (MODS XML):

    <?xml version="1.0" encoding="UTF-8" ?>

    <modsCollection xmlns="http://www.loc.gov/mods/v3">
    <mods version="3.2" ID="book-crossref">
    <titleInfo>
    <title>Seminumerical Algorithms</title>
    </titleInfo>
    <language>English ; German</language>
    <name type="personal">
    <namePart type="family">Knuth</namePart>
    <namePart type="given">D.E.</namePart>
    <role>
    <roleTerm authority="marcrelator" type="text">author</roleTerm>
    </role>
    </name>
    <originInfo>
    <dateIssued>1981</dateIssued>
    <publisher>Addison-Wesley</publisher>
    <issuance>monographic</issuance>
    </originInfo>
    <language>English ; German</language>
    <note>This is a cross-referencing BOOK</note>
    <typeOfResource>text</typeOfResource>
    <identifier type="citekey">book-crossref</identifier>
    <genre authority="marcgt">book</genre>
    <relatedItem type="series">
    <titleInfo>
    <title>The Art of Computer Programming</title>
    </titleInfo>
    <part>
    <detail type="volume">
    <number>2</number>
    </detail>
    </part>
    </relatedItem>
    </mods>
    </modsCollection>

    Thank you
    RM