Multiple files per record possible?

Help
2008-01-04
2013-05-28
  • Hi all,

    I am starting to use Refbase on a regular basis. Thanks for you work! The svn code offers almost everything I need. There still are a few features that I need though:
    1) Being able to upload several files per record (e.g. for one conference publication I would like to upload the pdf of the article and a powerpoint presentation of the associated talk or poster). It would be great to have at least two files per record: one for the main file and one for a zip file containing additional resources.
    2) Being able to use public groups rather than only private ones
    3) Being able to associate one user with several Institutions

    I have seen the two last ones being discussed already. So my question is about the first one:
    - Is there a way to work around feature 1? Using a unique zip file is not really an option as I love the direct pdf link.

    Thanks for your attention,
    Tom

     
    • Hi Tom,

      thanks for the heads up!

      > 1) Being able to upload several files per record

      I agree that this would be very useful. Upload of multiple files per record has been requested previously and has also been discussed previously among developers. Nothing has been done about it, though, since a good implementation of this feature will require greater changes to the refbase core (probably a dedicated "files" MySQL table, and changes to many SQL queries in the core functions), and thorough testing. It's certainly doable, and I'd like to see it implemented, but it will need some good amount of development time (which is currently rare).

      > (e.g. for one conference publication I would like to upload the
      > pdf of the article and a powerpoint presentation of the associated
      > talk or poster).

      Besides the final PDF or Powerpoint presentation, other useful formats spring to mind, such as manuscript versions (used for collaborative writing), a publicly available open access version (i.e. the final text of the publication without the publisher's layout), or an audio stream of an oral presentation (podcast).

      > It would be great to have at least two files per record: one for
      > the main file and one for a zip file containing additional
      > resources.

      That could be a short-time solution, though I'd prefer the upload of an unlimited number of files, whith clear indication of the file type/category via the GUI.

      > 2) Being able to use public groups rather than only private ones

      Yes, this feature has been requested since quite a long time, and it's high up on the ToDo list.

      http://wiki.refbase.net/index.php/Planned_feature_additions#Public_groups_.28tags.29

      Implementation of public groups is a big feature, which likely requires quite some work. ATM, I simply don't have enough time to do this, sorry. But rest assured that it won't be forgotten.

      > 3) Being able to associate one user with several Institutions

      Same issues here: I'd like to support this in refbase, but the feature probably requires a fundamental change to the current logic/magic of how the 'call_number' and 'location' fields work.

      As a current workaround, you could specify a compound string for the "Institutional Abbreviation" in 'user_details.php'. As an example, if a user belongs to the AWI *and* the IPO institution, you could e.g. use "AWI-IPO" as institutional abbreviation. This will allow to match publications of this user with both institutions.

      > - Is there a way to work around feature 1? Using a unique zip file
      > is not really an option as I love the direct pdf link.

      I agree that upload of zip files (instead of PDFs) isn't ideal.

      As an alternative, if further ressources are available somewhere else online, you could point to these ressources via a web link. But, of course, the same issue applies here: it would be nice if multiple web links could be added as well. Btw, the same is true for foreign record identifiers (such as IDs from PubMed, ISI WoS, CSA Illumina, arXiv, etc).

      As a current workaround, to allow multiple files per record with the current database design, the 'file' field in table 'refs' could be hacked to hold multiple file paths (or URLs). But this may get ugly, and would still require quite some coding. It might also pose new problems. We'll have to further discuss this topic among developers.

      I wish I could serve you better with regard to these issues. In any case, it's very important to let us know what (missing) features you consider essential, so we can set priorities for future development accordingly.

      Thanks, Matthias

       
      • Hi Matthias,

        Thanks for the lightning fast answer!

        > Besides the final PDF or Powerpoint presentation, other useful formats spring
        > to mind, such as manuscript versions (used for collaborative writing), a publicly
        > available open access version (i.e. the final text of the publication without
        > the publisher's layout), or an audio stream of an oral presentation (podcast).
        >
        > > It would be great to have at least two files per record: one for
        > > the main file and one for a zip file containing additional
        > > resources.
        >
        > That could be a short-time solution, though I'd prefer the upload of an unlimited
        > number of files, whith clear indication of the file type/category via the GUI.

        I certainly agree with that.

        > > 3) Being able to associate one user with several Institutions
        >
        > Same issues here: I'd like to support this in refbase, but the feature probably
        > requires a fundamental change to the current logic/magic of how the 'call_number'
        > and 'location' fields work.
        >
        > As a current workaround, you could specify a compound string for the "Institutional
        > Abbreviation" in 'user_details.php'. As an example, if a user belongs to the
        > AWI *and* the IPO institution, you could e.g. use "AWI-IPO" as institutional
        > abbreviation. This will allow to match publications of this user with both
        > institutions.

        Thanks for the tip, I'll see if I can use it.

        BTW, I mostly use the institution field to generate reference lists. If the public grouping system gets released, I could use the public groups to generate these lists. The need for multiple institutions will then not be so strong.

        > > - Is there a way to work around feature 1? Using a unique zip file
        > > is not really an option as I love the direct pdf link.
        >
        > I agree that upload of zip files (instead of PDFs) isn't ideal.
        >
        > As an alternative, if further ressources are available somewhere else online,
        > you could point to these ressources via a web link. But, of course, the same
        > issue applies here: it would be nice if multiple web links could be added as
        > well. Btw, the same is true for foreign record identifiers (such as IDs from
        > PubMed, ISI WoS, CSA Illumina, arXiv, etc).

        A true field for PubMed IDs and similar would indeed be nice but I can live seeing them in the comments field :)

        > I wish I could serve you better with regard to these issues. In any case, it's
        > very important to let us know what (missing) features you consider essential,
        > so we can set priorities for future development accordingly.

        It's great to hear that feature requests are taken into account :)

        Best,
        Tom

         
    • Hi Tom,

      > > > It would be great to have at least two files per record: one for
      > > > the main file and one for a zip file containing additional
      > > > resources.
      > >
      > > That could be a short-time solution, though I'd prefer the upload of
      > > an unlimited number of files, whith clear indication of the file
      > > type/category via the GUI.
      >
      > I certainly agree with that.

      Dedicated MySQL tables for files and links would also allow to specify access permissions for each file or link individually - which would be a great step towards record-specific permissions (another long-awaited feature addition).

      http://wiki.refbase.net/index.php/Planned_feature_additions#Record-specific_permissions

      > > As a current workaround, you could specify a compound string for the
      > > "Institutional Abbreviation" in 'user_details.php'.
      >
      > Thanks for the tip, I'll see if I can use it.
      >
      > BTW, I mostly use the institution field to generate reference lists. If the
      > public grouping system gets released, I could use the public groups to
      > generate these lists. The need for multiple institutions will then not be so
      > strong.

      I see. While again being a workaround, you could also use any other global field to indicate reference groups, such as the 'keywords', 'notes' or 'area' fields. These three fields are supported by the 'show.php' API and can thus be used to generate reference lists.

      http://linking.refbase.net/
      http://bibliographies.refbase.net/

      The 'area' field would be a good candidate if it's not used otherwise in your database.

      > > it would be nice if multiple web links could be added as well. Btw, the same
      > > is true for foreign record identifiers (such as IDs from PubMed, ISI WoS, CSA
      > > Illumina, arXiv, etc).
      >
      > A true field for PubMed IDs and similar would indeed be nice but I can live
      > seeing them in the comments field :)

      Having dedicated fields (or a dedicated MySQL table) for foreign record identifiers would also allow refbase to auto-generate links that point back to the ressource at the source repository (PubMed, ISI Web of Science, arXiv, etc), which would be quite useful IMHO.

      Btw, all of the features discussed here would require deeper changes to the refbase database schema. We've been playing with the idea of a mixed design that would use relational tables in the background, but, at the same time, would merge info from these separate tables into a flat table that could be accessed with less performance constraints for many of the display tasks. This would also allow for much simpler database queries (avoiding a lot of table JOINs). Anyways, this is something that warrants more thought and testing.

      > It's great to hear that feature requests are taken into account :)

      They are! In fact, many features and refinements in refbase did originate from user requests. User feedback can also greatly influence the priorities on our ToDo list. So, please keep it coming!

      Matthias

       
    • FYI, based on the discussion in this thread I've added three new items to the "Planned features" page in our wiki:

      http://wiki.refbase.net/index.php/Planned_feature_additions#Multiple_files_per_record
      http://wiki.refbase.net/index.php/Planned_feature_additions#Multiple_URLs_per_record
      http://wiki.refbase.net/index.php/Planned_feature_additions#Support_foreign_record_identifiers

      In addition to the database design issues (mentioned earlier in this thread), these features would also require a rethinking/redesign of the details & edit views in the refbase GUI, so it may take some time until they get implemented.

      Best, Matthias

       
      • Great! Thanks.
        Tom