WikiSysop: Fix incorrect display of accented characters & umlauts

2023-11-07T13:08:07Z

Fix incorrect display of accented characters & umlauts

← Older revision		Revision as of 15:08, 7 November 2023
Line 103:		Line 103:
	Progress: 0%		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.		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 ===		=== Cross-site searches ===

WikiSysop: Original page content from 22-Nov-2008

2023-10-25T08:41:54Z

Original page content from 22-Nov-2008

New page

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 [http://dev.mysql.com/doc/refman/4.1/en/string-functions.html MySQL string functions] <code>SOUNDEX</code> and <code>SOUNDS LIKE</code>.

=== ''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 [http://bibliophile.sourceforge.net/ Bibliophile initiative]. Support for web service protocols such as [[Search/Retrieve_web_services|SRU]] and [[#OpenSearch support|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 [http://www.loc.gov/standards/mods/ 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 [http://www.pubmed.gov PubMed.gov] via their PubMed ID. A similar feature should be added for the [http://www.arxiv.org/ arXiv.org] e-Print archive. The [http://export.arxiv.org/api_help/docs/user-manual.html 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 [http://en.wikipedia.org/wiki/AJAX 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 [http://hublog.hubmed.org/archives/001624.html HubLog post] and links therein), WorldCat ([http://xissn.worldcat.org/xissnadmin/index.htm xISSN] & [http://www.worldcat.org/affiliate/webservices/xisbn/app.jsp xISBN]) or LibraryThing ([http://www.librarything.com/thingology/2006/06/introducing-thingisbn_14.php 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 [http://www.pubmed.gov PubMed.gov] or [http://www.arxiv.org/ 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 [http://www.sonnysoftware.com/ Bookends], "Upload to refbase" functionality has been added

Progress: 5%

Description: refbase should integrate with desktop reference managers (such as [http://bibdesk.sourceforge.net/ BibDesk], [http://www.sonnysoftware.com/ Bookends], [http://jabref.sourceforge.net/ JabRef], [http://mekentosj.com/papers/ Papers] or [http://www.zotero.org/ 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 service|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 [[Search/Retrieve_web_services|SRU/W webservice]] or [[#OpenSearch support|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 [http://dev.zotero.org/docs/sample_utility 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 [[Search/Retrieve_web_services|SRU/W webservice]], refbase should support an [[OpenSearch service|OpenSearch]] webservice. OpenSearch capable clients would be able to [http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_Query_element query] a refbase database and retrieve search results in an OpenSearch [http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_response_elements 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 [[Planned_feature_additions#Cross-site_searches|cross-site searches]]. When implemented, refbase should support auto-discovery to allow for [http://developer.mozilla.org/en/docs/Creating_OpenSearch_plugins_for_Firefox 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 [[Search/Retrieve_web_services|SRU/W]] and [[OpenSearch service|OpenSearch]]), a [http://en.wikipedia.org/wiki/Representational_State_Transfer 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 [http://code.google.com/apis/gdata/index.html GData], [http://www.ukoln.ac.uk/repositories/digirep/index/SWORD SWORD] (Simple Web-service Offering Repository Deposit), or the [http://www.loc.gov/standards/sru/record-update/ 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: [http://www.openarchives.org/OAI/openarchivesprotocol.html The Open Archives Initiative Protocol for Metadata Harvesting], which is implemented by [http://software.eprints.org/ EPrints] and [http://www.dspace.org/ 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 [http://sourceforge.net/project/showfiles.php?group_id=113285&package_id=150961 OSBib] or [http://xbiblio.sourceforge.net/ 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: [http://en.wikipedia.org/wiki/Resource_Description_Framework 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 [http://www.zotero.org/ 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: [http://microformats.org/wiki/citation Other citation microformats] and a [http://microformats.org/wiki/search-results-example 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:
<nowiki>{{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}}</nowiki>
[http://www.hubmed.org/ 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).

[[Category:General]]

← Older revision		Revision as of 10:42, 25 October 2023
Line 417:		Line 417:

	[[Category:General]]		[[Category:General]]
			__NOEDITSECTION__

Planned feature additions - Revision history

WikiSysop: Fix incorrect display of accented characters & umlauts

WikiSysop: Hide section edit links

WikiSysop: Original page content from 22-Nov-2008