Search

A common issue with case-based reasoning (CBR) systems, particularly those that are distributed over a network, is the time required to determine the closest match to the current case. Research has been carried out in this area to try to improve the situation by distributing some of the calculation to the client side thereby reducing the burden on the server. In CBR applications, the case library is stored in some format such as a relational database or flat files that the software interprets in order to perform similarity assessment between the current case and each case in the database. In this paper a novel approach is proposed where the retrieval of the case information and the calculation of the similarity values are performed in one action. This does not incur the same burden upon the server in terms of calculation, as all that is required is a larger database lookup via SQL. As the case base needs to be queried regardless of the CBR technique used to obtain the case information, it is proposed that a combined similarity assessment and case retrieval would provide a fast method of case retrieval.

Scientists have to perform multiple experiments producing qualitative and quantitative data to determine if a compound is able to bind to a given target. Due to the large diversity of the potential ligand chemical space, the possibility of experimentally exploring a lot of compounds on a target rapidly becomes out of reach. Scientists therefore need to use virtual screening methods to determine the putative binding mode of ligands on a protein and then post-process the raw docking experiments with a dedicated scoring function in relation with experimental data. Two of the major difficulties for comparing docking predictions with experiments mostly come from the lack of transferability of experimental data and the lack of standardisation in molecule names. Although large portals like PubChem or ChEMBL are available for general purpose, there is no service allowing a formal expert annotation of both experimental data and docking studies. To address these issues, researchers build their own collection of data in flat files, often in spreadsheets, with limited possibilities of extensive annotations or standardisation of ligand descriptions allowing cross-database retrieval. We have conceived the dockNmine platform to provide a service allowing an expert and authenticated annotation of ligands and targets. First, this portal allows a scientist to incorporate controlled information in the database using reference identifiers for the protein (Uniprot ID) and the ligand (SMILES description), the data and the publication associated to it. Second, it allows the incorporation of docking experiments using forms that automatically parse useful parameters and results. Last, the web interface provides a lot of pre-computed outputs to assess the degree of correlations between docking experiments and experimental data.

In the light of the increasing number of biological databases, their integration is a fundamental prerequisite for answering complex biological questions. Database integration, therefore, is an important area of research in bioinformatics. Since most of the publicly available life science databases are still exclusively exchanged by means of proprietary flat files, database integration requires parsers for very different flat file formats. Unfortunately, the development and maintenance of database specific flat file parsers is a nontrivial and time-consuming task, which takes considerable effort in large-scale integration scenarios. This paper introduces heuristically based concepts for automatic structure extraction from life science database flat files. On the basis of these concepts the FlatEx prototype is developed for the automatic conversion of flat files into XML representations.

ChEBI is a database and ontology of chemical entities of biological interest. It is widely used as a source of identifiers to facilitate unambiguous reference to chemical entities within biological models, databases, ontologies and literature. ChEBI contains a wealth of chemical data, covering over 46,500 distinct chemical entities, and related data such as chemical formula, charge, molecular mass, structure, synonyms and links to external databases. Furthermore, ChEBI is an ontology, and thus provides meaningful links between chemical entities. Unlike many other resources, ChEBI is fully human-curated, providing a reliable, non-redundant collection of chemical entities and related data. While ChEBI is supported by a web service for programmatic access and a number of download files, it does not have an API library to facilitate the use of ChEBI and its data in cheminformatics software. To provide this missing functionality, libChEBI, a comprehensive API library for accessing ChEBI data, is introduced. libChEBI is available in Java, Python and MATLAB versions from http://github.com/libChEBI , and provides full programmatic access to all data held within the ChEBI database through a simple and documented API. libChEBI is reliant upon the (automated) download and regular update of flat files that are held locally. As such, libChEBI can be embedded in both on- and off-line software applications. libChEBI allows better support of ChEBI and its data in the development of new cheminformatics software. Covering three key programming languages, it allows for the entirety of the ChEBI database to be accessed easily and quickly through a simple API. All code is open access and freely available.

Command-line annotation software tools have continuously gained popularity compared to centralized online services due to the worldwide increase of sequenced bacterial genomes. However, results of existing command-line software pipelines heavily depend on taxon-specific databases or sufficiently well annotated reference genomes. Here, we introduce Bakta, a new command-line software tool for the robust, taxon-independent, thorough and, nonetheless, fast annotation of bacterial genomes. Bakta conducts a comprehensive annotation workflow including the detection of small proteins taking into account replicon metadata. The annotation of coding sequences is accelerated via an alignment-free sequence identification approach that in addition facilitates the precise assignment of public database cross-references. Annotation results are exported in GFF3 and International Nucleotide Sequence Database Collaboration (INSDC)-compliant flat files, as well as comprehensive JSON files, facilitating automated downstream analysis. We compared Bakta to other rapid contemporary command-line annotation software tools in both targeted and taxonomically broad benchmarks including isolates and metagenomic-assembled genomes. We demonstrated that Bakta outperforms other tools in terms of functional annotations, the assignment of functional categories and database cross-references, whilst providing comparable wall-clock runtimes. Bakta is implemented in Python 3 and runs on MacOS and Linux systems. It is freely available under a GPLv3 license at https://github.com/oschwengers/bakta. An accompanying web version is available at https://bakta.computational.bio.

An existing highly functional relay settings card file containing a vast amount of technical data for a large variety of relaying terminals was computerized. The primary goal was to retain the transparency of the existing manual file while benefiting from computerization's handling capabilities. The computer's limited ability to use preprinted output forms was overcome by programming it to create its own forms. Efficient programming and data organization resulted in the computer displaying and printing forms similar to those used in the manual file. This made the new file as convenient as the old and compatible with it over the 2 year transition period. The programming provides fast, interactive access to all records in the file and allows displaying and printing of a large variety of card forms and useful reports.

A determination is made of the optimum ratio of records to file guides to minimize searching time in an ordered two-level file such as a library card catalog. The solution is proportional to the square root of the number of records in the file container (card drawer). When scanning rates for cards and for file guides are equal, the solution is exactly the square root of file size. Simplifying assumptions employed in this determination are discussed. It is asserted that most library card catalogs contain far fewer file guides than would be justified in order to minimize searching time for users.

Xerox' Star Professional Workstation is distinguished by a graphic user interface committed to the What-you-see-is-what-you-get design philosophy. The system promotes a see / point / push-a-button style of interaction with immediate feedback, in marked contrast to more familiar programming or command-language interfaces. Star's Records Processing feature integrates traditional data processing functionality into this user model. Normal Star documents may contain fields and tables. Star record files have their structure defined by copying the field structure of a regular document. Multiple output formats are provided for a record file by giving it a document with each desired format. Such a document may format multiple records in a tabular array, or present each record's data in a new copy of the formatting document. Data is transferred between documents and records wherever fields have matching names (“field lading”); non-matching fields may be given a fill-in rule which allows summary data to be computed. Queries are expressed in an exemplary fashion, by entering desired values and ranges of values into a copy of a record (a “filter”). Common uses of the data in a record file are encapsulated in a “view”, which specifies the subset of the file's records to be considered, the order in which they are to be presented, and the document to be used to format them. An arbitrary number of views may be associated with a record file; each may have its own index, but the underlying records are stored only once. Common records processing functions are provided at a high-level user interface: Moving a document, a folder of documents, or another record file to a record file adds records to the file. Moving a record file to a printer causes the current view of the record file to be printed. Benefits include an economy of concepts and effort for user and implementor alike, along with the synergy of a unified environment. The approach seems to extend easily to a number of new domains. However, increased efforts are required to produce a coordinated design and implementation throughout the whole system, and acceptable performance may be harder to achieve.