This page lists planned feature additions:
Important: Please note that the items listed below are simply suggestions for improving refbase and that we cannot (and don't want to) speculate on whether or when any of the listed features will be added to refbase.
General
Resource types
Goal: Increase number of supported resource types.
Priority: 6
Status: added types Abstract, Conference Article, Conference Volume, Magazine Article, Manual, Miscellaneous, Newspaper Article, Report, Patent, Software
Progress: 50%
Description: refbase should allow users to choose from a variety of additional resource types including conference proceeding, patent, report, newspaper article, computer program, etc. All these types should invoke appropriate output on citation. In addition, the admin should be allowed to add additional resource types and users should be able to disable any unused types.
Migrate to more common libraries
Goal: To work under a larger number of configurations & to depend on only well-maintained code.
Priority: 3
Status: not started
Progress: 0%
Description: We should consider migrating away from the ActiveLink XML library, as it isn't maintained. refbase should also be able to use MySQLi.
Installation and updates
Redirect from index.php to install.php or update.php
Goal: refbase should direct to install.php or update.php as needed.
Priority: 6
Status: not started
Progress: 0%
Description: If the database doesn't exist, refbase should direct to install.php. A version number or date for refbase could be stored in the database. If it is older than a version variable in index.php, index.php could redirect to the update script.
Improvements to install.php
Goal: The install.php script should verify required server settings and provide more options for installation on different server setups.
Priority: 6
Status: not started
Progress: 0%
Description: 1) install.php should check required server settings prior to installation, and report possible problems in advance. 2) install.php should allow for installation into an existing database by providing an option for a table prefix that will be used for the refbase MySQL tables (currently, this can only be done by editing some configuration files). 3) To allow for web-based installation on shared hosts, install.php could offer an option to use an existing MySQL user (instead of setting up its own MySQL user which requires a MySQL admin user & password). 4) install.php should provide an option to omit the sample data, i.e. install with a blank database.
Allow editing of configuration scripts through a web interface
Goal: Offer a web interface to the settings provided in ini.inc.php, db.inc.php' and other config files.
Priority: 3
Status: not started
Progress: 0%
Description: Upon installation or update, refbase could list the settings in the various configuration files that are now manually edited & allow users to make changes with the web interface.
Searching
Search for duplicates
Goal: Offer the user means for handling duplicate database entries.
Priority: 4
Status: in development
Progress: 40%
Description: The database should offer means to easily spot duplicate entries and mark particular records as original (or duplicate) entry. Search features should allow users to exclude duplicate entries from the results list. It would be preferable if a smart dup detection mechanism such as phonetic matching could be used. See the MySQL string functions SOUNDEX and SOUNDS LIKE.
OR search capabilities
Goal: Allow OR searches via the GUI.
Priority: 3
Status: not started
Progress: 0%
Description: When searching via one of the dedicated search pages, users should be able to specify whether a search on multiple fields will invoke an AND or an OR query (currently, entering search terms in multiple fields will always connect search terms with AND). In addition, the "Search within Results" query form should allow users to expand the current result set, i.e. add found results to the existing list of results.
Simple handling of accented characters or umlauts
Goal: Allow naive users to search for accented characters by using the unaccented character and vice-versa.
Priority: 3
Status: not started
Progress: 0%
Description: If a search query contains no accents, it might be desirable to automatically search for commonly accented characters (especially in the Quick and Simple searches). If a user enters 'Jon', refbase could search for 'J[oÛˆ¯]n'. Similarly, it might be desirable to search for unaccented characters if a query contains an accent. If a user entered in 'JÛn', refbase might search instead for 'J[oÛ]n'. Naturally, there should be a mechanism for "advanced users" to have exact searches (perhaps by requiring a pre or post fix for more precise handling of (un)accented search strings.
Cross-site searches
Goal: Allow users to search and display results from other databases.
Priority: 2
Status: not started
Progress: 0%
Description: refbase should allow for cross-site searches both through other installations of refbase as well as through other bibliographic databases of the Bibliophile initiative. Support for web service protocols such as SRU and OpenSearch will ease communication between different applications.
Adding/Editing of records
Import
Goal: Offer direct data import from MODS XML.
Priority: 6
Status: not started
Progress: 0%
Description: refbase currently offers a number of native import scripts, as well as scripts which use Bibutils to convert formats to something which refbase can read. Long-term plans are to provide native import capabilities for MODS XML. Importing records describes the import functionality available in refbase and future plans on import.
Direct import via arXiv ID
Goal: Use arXiv API to directly fetch and import records & PDFs from arXiv.org.
Priority: 5
Status: import from arXiv.org has been fully implemented, though some aspects (such as parsing of the "Journal Ref" string) might need some further testing and fine-tuning
Progress: 95%
Description: refbase allows to directly fetch and import records from PubMed.gov via their PubMed ID. A similar feature should be added for the arXiv.org e-Print archive. The arXiv API allows for HTTP GET queries by arXiv ID and returns OpenSearch Atom feeds with basic metadata (title, author(s), publication date, abstract, and journal info if given) and any URLs (HTML, PDF, DOI) associated with an article. refbase should parse the OpenSearch response and add new database records for each feed entry. Ideally, associated PDFs would be fetched as well and stored with the record.
Record-type specific forms
Goal: Simplify manual data input by providing record-type specific forms.
Priority: 2
Status: not started
Progress: 0%
Description: Record-type specific forms would guide a user by only showing those fields that are required for a particular record-type (like journal articles, book chapters or whole books). Record-type specific forms might not be necessary if the current "Add/Edit Record" form would be able to dynamically indicate required fields for a given record-type.
Input validation
Goal: refbase should dynamically validate input in the "Add/Edit Record" form.
Priority: 4
Status: not started
Progress: 0%
Description: refbase should provide on-the-fly validation of data while a user inputs or edits data in the "Add/Edit Record" form. This would help users to ensure correct formatting for fields that require a specific string formatting (such as the author field). Dynamic form input validation may be best realized using AJAX style methods.
Auto-filling of fields
Goal: refbase should auto-fill fields if possible.
Priority: 4
Status: not started
Progress: 0%
Description: refbase should be able to auto-fill empty fields based on information available in other fields and/or tables. This is especially useful if a flat database design is maintained. A typical application would be the auto-filling of journal-related fields (e.g. publisher, place, abbrev_journal, language or summary_language) from a journal database if the journal name (or ISSN) can be uniquely matched. If no journal info is available in the refbase journal database, a public service such as http://journalseek.net/ could be used for information retrieval and the fetched journal data could be automatically added to refbase's own journal database. Similarly, refbase could use web services from CrossRef (see HubLog post and links therein), WorldCat (xISSN & xISBN) or LibraryThing (thingISBN) to supplement record metadata.
Auto-completion of field input
Goal: refbase should auto-complete user input in the "Add/Edit Record" form.
Priority: 4
Status: auto-completion has been fully implemented for the "Add/Edit Record" form and search suggestions are provided in some of the search forms (but they're not yet available in the "Advanced Search" and "Library Search" forms)
Progress: 95%
Description: It would be helpful if refbase would offer auto-completion features for fields of the "Add/Edit Record" form. This would allow users to start typing a string, then choose from a list of matching values (such as authors, keywords or journal names) that already exist in the database. Ideally, such a feature would not interfere with browser-specific auto-completion features and would be platform/browser agnostic. One way of implementing this would be a pop-up window where a generic database value browser would be combined with "Search within Results" functionality, and selected values would be written/appended to the field that's currently selected in the "Add/Edit Record" form.
Multiple files per record
Goal: refbase should allow users to upload multiple files per record.
Priority: 5
Status: not started
Progress: 0%
Description: Currently, refbase allows to upload one file per record. It would be useful if multiple files could be attached to a given record. This would allow users to upload different representations, variants or versions of the same publication. Besides the final PDF, users could then attach a Powerpoint presentation or an audio file of an associated talk (though, in a strictly hierarchical design, talks or posters may warrant different but related records). Other use cases could be the upload of supplementary material or different manuscript revisions during collaborative preparation of an article, or the upload of a publicly available Open Access version (such as preprints or postprints). Upon upload, users should be able to specify file info (such as file type, language or a description) and access permissions individually for each file.
Multiple URLs per record
Goal: refbase should allow users to specify multiple URLs per record.
Priority: 5
Status: not started
Progress: 0%
Description: Currently, refbase allows to specify one URL per record. It would be useful if multiple URLs could be added to a given record. While the primary URL could point to the publication's entry at the publisher site, additional URLs could point to, say, further info/news about the publication, any supplementary material, or related discussion located elsewhere. As is true for multiple files, some options to categorize and/or describe the given URLs as well as individual access permissions might be useful.
Support foreign record identifiers
Goal: refbase should support record identifiers from foreign repositories (e.g. from PubMed.gov or arXiv.org) explicitly, and auto-generate links back to these repositories.
Priority: 5
Status: not started
Progress: 0%
Description: Upon import, refbase currently puts foreign record identifiers (such as IDs from arXiv, ISI Web of Science, PubMed, or SciFinder) into the notes field. It would be nice, however, if these record identifiers would be stored in some dedicated field(s). This would allow refbase to auto-generate links back to the corresponding record entries at the foreign repositories.
Sharing
Public groups (tags)
Goal: Allow users to collectively share and categorize groups of records.
Priority: 6
Status: not started
Progress: 0%
Description: We plan to open up the refbase group (aka tagging) mechanism so that groups can be made public, group-specific or private. This will enable users to share their groups with each other and establish a common categorization system.
User comments
Goal: Allow users to comment on particular records and exchange their thoughts with others.
Priority: 3
Status: not started
Progress: 0%
Description: We imagine a comment system where multiple comments would be allowed for a particular record and where comments could be made public, group-specific or private. Comments could be searched and displayed similar to (and in combination with) bibliographic references. Here's an ASCII mockup of how we envision such a system:
+-------------------------------------------------------------------+ | | | Cota GF, Horne EPW (1989) Physical control of Arctic ice algal | | production. Mar Ecol Prog Ser 52(2):111-121 | | | | Matthias Steffens | This is an essential article that provides | | ***** | a good dataset on environmental control of | | 2005-04-27 23:33 | primary production in polar areas. | | | +-------------------------------------------------------------------+ | | | Mock T (2002) In situ primary production in young Antarctic sea | | ice. Hydrobiologia 470(1-3):127-132 | | | | Matthias Steffens | Given the inaccessibility of the location | | *** | it's valuable data nonetheless. In situ | | 2004-12-18 16:05 | measurements are still very rare. | | | | Paul Miller | I didn't get the point of this article. | | * | IMHO, it's based on a weak dataset and | | 2004-12-03 12:19 | the conclusions are fuzzy. | | | | Matthias Steffens | Did anybody read this one? I'd appreciate | | | your opinions on the used method and | | 2004-12-01 11:22 | how this relates to existing methods. | | | +-------------------------------------------------------------------+
According to the above visualization, comments would print below the reference they are referring to. The reference would be displayed as a citation. Multiple citations with multiple comments could be displayed and you could search within results as usual. Note the stars which indicate the users rating. Users could edit/delete their own comments and decide who'll be able to see them (everyone, certain group(s) or private).
Better integration with desktop reference managers
Goal: Provide means for easy download of records to desktop reference managers, and for direct record upload to a refbase database.
Priority: 5
Status: for Bookends, "Upload to refbase" functionality has been added
Progress: 5%
Description: refbase should integrate with desktop reference managers (such as BibDesk, Bookends, JabRef, Papers or Zotero) so that records stored in a refbase database can be easily retrieved from within these applications. Zotero can already extract bibliographic metadata from refbase's web pages via COinS or unAPI, and something similar could work for other apps that feature web views. In addition, it would be desirable if users could search an online refbase database from within their desktop reference managers. The refbase search & retrieve webservices offer standardized APIs for this, such as the SRU/W webservice or OpenSearch in conjunction with the existing unAPI service. Finally, it would be also useful if users of desktop reference managers could upload (and eventually synch) records to a refbase server directly from within their desktop application. In case of Zotero, "upload to refbase" functionality could be developed via an Zotero utility.
Webservices
OpenSearch support
Goal: Allow OpenSearch clients to query refbase and return found results in OpenSearch response format.
Priority: 6
Status: OpenSearch support has been implemented with support for auto-discovery, multiple response formats (HTML, Atom, RSS, SRW_DC XML, SRW_MODS XML), simple CQL searches and support for search suggestions (returned in JSON or HTML); a better CQL parser would be desirable
Progress: 95%
Description: Similar to the refbase SRU/W webservice, refbase should support an OpenSearch webservice. OpenSearch capable clients would be able to query a refbase database and retrieve search results in an OpenSearch response format, e.g. RSS 2.0 or Atom 1.0, plus the OpenSearch response extensions. This would also allow to integrate several refbase servers (or other OpenSearch capable servers) via cross-site searches. When implemented, refbase should support auto-discovery to allow for search plugins. Eventual support for JSON for fetching of search suggestions would be nice.
API
Goal: Provide an API that allows clients to query a refbase database, retrieve results in a structured format and modify any database information.
Priority: 5
Status: not started
Progress: 0%
Description: Opposed to pure search/retrieve webservices (such as SRU/W and OpenSearch), a RESTful API should also allow clients to send requests that alter the database, i.e. add, edit or delete records, meta-data or users. This will allow for easy integration with third-party tools and enable the development of alternative interfaces to a refbase database. It would be desirable to support an existing framework such as Google's GData, SWORD (Simple Web-service Offering Repository Deposit), or the Record Update service that is proposed by the SRU community.
OAI Protocol for Metadata Harvesting
Goal: Provide (yet another) standard way for software to retrieve information from refbase. Eventually provide a mechanism for retrieval from arxiv/dspace/eprints, and other software which is targeted at larger institutions.
Priority: 5
Status: implemented support for the simple/unqualified Dublin Core (OAI_DC) XML format which is a prerequisite for OAI-PMH
Progress: 10%
Description: The Open Archives Initiative Protocol for Metadata Harvesting, which is implemented by EPrints and DSpace uses Dublin Core XML over HTTP. This is harvested by google and yahoo and others.
Citation support
Increase number of available citation styles
Goal: Add most commonly used citation styles and generally increase the number of available styles.
Priority: 6
Status: added styles: AMA, APA, Chicago, Harvard (3 variants), MLA, Vancouver
Progress: 75%
Description: By default, refbase should include at least the most universal styles (i.e. APA, MLA, Chicago, Harvard, Turabian, CB, CGOS, CBE, AMA). Besides that, it would be nice to increase the list of available citation styles substantially.
User-customizable citation styles
Goal: Allow users to create custom citation styles, preferably via the use of a plugin structure.
Priority: 4
Status: not started
Progress: 0%
Description: Currently, citation styles are defined as PHP functions which is very powerful but not very user friendly. We plan to enhance the cite feature by adding support for other (more general) citation formats. We'd like to integrate refbase with other solutions which offer users an easier way of adding or editing any citation styles. Projects such as Mark Grimshaw's OSBib or xbiblio developed by Bruce D'Arcus come to mind. Some implementation of CSL (backed by Bruce and used by Zotero) would be nice.
Export
Access permissions
Record-specific permissions
Goal: Offer fine-grained access control on record-level.
Priority: 6
Status: not started
Progress: 0%
Description: The creator (or the admin) of a record should be able to specify who will be allowed to view a particular record. For each record, an authorized user should be able to set the record visibility to everyone, private or to particular groups of database users. Separate access control settings should be provided for file downloads and edits.
Metadata and Microformats
Embedded RDF
Goal: Embed citation metadata in HTML pages as machine-readable RDF which may be processed by clients.
Priority: 5
Status: not started
Progress: 0%
Description: RDF is less supported than COinS, but is a useful alternative that has some advantages (such as multiple author support). This will allow client-side tools (such as Zotero) to more easily use the data provided by refbase.
Other microformats?
Goal: Other formats may be useful as well
Priority: 1
Status: not started
Progress: 0%
Description: Other citation microformats and a search results microformat might eventually be useful. It seems like COinS is the most useful at this point in time, though.
Wikipedia citations & other UnAPI goodness
Goal: Make it easy for WP contributors to use refbase deployments to add articles
Priority:
Status: not started
Progress: 0%
Description: WP's citation templates are pretty straightforward clips of text, a'la:
{{cite journal | author = Greiner C, Oppenheimer SM, Dunand DC | title = High strength, low stiffness, porous NiTi with superelastic properties. | journal = Acta Biomater | volume = 1 | issue = 6 | pages = 705-16 | year = 2005 | id = PMID 16701851}}
Hubmed has a good example of UnAPIed Wikipedia citation generation. They also have del.icio.us bookmarking (I guess we could add less obtrusive citeulike/connotea/etc. links this way).