3. Comparison Grid
          3.2. General
 3.2.1. Database and record structure 

Database and record structure

Bibus EndNoteWeb (web based) RefWorks (web based) Procite EndNote Reference Manager
Database and record structure Database and record structure  Database and record structure  Database and record structure  Database and record structure  Database and record structure 

1 -  Subfields available other than "Last name, First name, prefix"

Bibus: no EW: no RW: no Pr: yes, portion of date, call number fields En: no RM: no

2 - Horizontal links: between databases, between records (1:1, 1:n), between list entries

Bibus: no EW: no links between databases; can navigate from one record to another set -only- via authors.
If the record comes from ISI Web of Knowledge can navigate towards the source record and related records
RW: not between databases; not x-refs between list entries; you can navigate from one record to another set via the list terms (authors, keywords, journal titles etc.) Pr: no

En: no

RM: only term synonyms in the 3 indexes (authors, kw, periodicals): searching for one synonym is searching for all the connected terms

3 - Database subsets 
    1.     marked records
    2.     virtual sets (groups, folders: pointers to records without physical duplication)
    2.1   nested (hierarchical) groups
    2.2   live/smart groups

Bibus: 1 (stay across sessions), 2, 2.1, 2.2 EW: 1: Quick list (on-the-fly group); 2: named groups/folders that can be shared in R/W mode; groups are not hierarchical, groups are not live RW:
1: only on the fly (do not stay across sessions)
2: named folders, last imported, and My list: they cannot be hierarchically nested; alphabetical sequence
Pr: 1 yes (stay across sessions) ; 2 yes: "groups" of virtual records: they cannot be hierarchically nested; can create up to 50; alphabetical sequence

En: 1: no marked records
2: sets and their subordinate groups of virtual records (up to 500);
2.1:  they cannot be hierarchically nested; apart from Automatic (online search results, trash, imported, duplicates...) 
2.2 yes they can be smart/live, i.e. acting as a query which points to the records that match it, the query can be the same as a normal one 

RM 1 only on the fly (do not stay marked across sessions)
2 "reference index": each is a named saved search result,  kind of a group, pointer to records; must be first selected as a field and searched as such via its name to display as 'retrieved' the records they point to. Retrieved records can then be the scope of various operations

5 -  Hierarchical links (es. thesaurus, mother/sons records, records and attached text-notecards-ideas)

Bibus: no EW: no RW: no Pr: no

some fields generate indexes which are entirely derived (automatically created and updated), cannot be directly edited. Field data and list contents (sort of look-up) can be "crossed" in output to replace text: string + alternate.txt; journal field + any journal.lst

En: no

Term Lists can be regarded as autonomous (see dedicated section: Term/Entry lists)

RM: no

some fields generate 3 lists the contents of which is not only derived (i.e. automatically created and updated from record contents), for they can have independent entries and synonyms and can be directly edited; (see dedicated section: Term/Entry lists)

6 - Ready, predefined, record structure: features of reference types

Bibus: yes, RT + fields (according to OO bibliographic structure); Several Preferences by default.
Fields do not change name across different RT. Fields attributes cannot be changed or transferred to other fields, included custom fields.
The link between a field and a term list (shortcut) is customizable. Fields cannot be deleted from a RT but only displaced to one or another tab: Main, Supplementary, Other fields
EW: yes: nothing can be changed; records contain data not input by users like: times cited; added date, last updated date ... RW: yes. Actually the input workform is only one, containing all the 51 fields and when it is opened, it may include an output style. In this case fields are ticked and grouped by the Accucite feature (accurate citing) to show which ones will be considered and displayed by the output style being used Pr: yes according to RT as input workform: individual files that can be shared among different databases (or you might keep them in different folders), if you move the database, you should also copy the workform files.
Fields bear "step" displayed name; fields are identified by a number which determinates their position: number is fixed across all the workforms; some fields (names, titles, dates, pages, URL, keywords, call number) have, to a different extent, properties -such as internal coding, indexing, output formatting, sort, searching...- that cannot lose or transfer to other fields;
2: yes, given abovementioned constraints, can add, delete, move, rename fields; attributes cannot be changed 

e.g. '5' is either "data file" or "medium designator" or "map type" in 3 different workforms: Data file, Newspaper, Map; if RT "Newspaper" -whereby 5 is "medium designator"- gets changed to "Journal Short form" which lacks 5, then 5 stays there with its content but no name, just number and can be edited;
no numeric fields apart from RN for sorting; internal pub. date format, Call number for sorting; if fields names are changed in workforms, styles are affected and must be manually fixed, though searching and global editing are not affected

En: yes, according to RT-reference types + other default preferences; Preferences are all automatically shared among different databases on the same computer, separately for each PC user.
Fields bear "step" displayed name and are identified by the position/role they hold in the Generic RT, which is fixed across all reference types. Some fields (e.g. names, journal titles, pages, URL, keywords, figure, caption) have attributes (internal coding, indexing for fast search, output formatting, sort...) that cannot loose or lend to other fields; but the link between a term list and a field is customizable 

when a field is deleted from RT (or mismatched), existing content is put to the corresponding Generic RT field; no numeric fields available, apart from RN for sorting; if fields names are changed in RT, styles are automatically updated, searching and global editing are not affected 

RM: yes, according to RT reference types which  belong to each individual database.
Fields bear a label as "step" displayed name; fields are identified by a number which does not imply a fixed position: number is fixed across all the RT; some fields (names, journal/periodical titles, dates, pages, link to URL etc., kw) have -to a different extent- properties (internal coding, indexing, output formatting, sort, searching, launch application...) that cannot lose or transfer to other fields  

6 - Number of RT record types

Bibus : 22 (17 + 5 custom) EW: 45 + 1 Generic RW: 30 + 1 generic1 Pr: 39 En: 45 + 1 Generic + 2 Unused customizable RM: 35 (1 Generic included)

7 - Can modify the exisiting RT record types (apart from changing name to RT or fields) and create extra

Bibus : no EW: no RW not really, modifications are only related to the output style being used: include/exclude fields and comments that can be added to any field; cannot create extra field, cannot change their names, can use all of them Pr:  yes ( n, each is a file): yet can only use existing fields with their fixed attributes Enone can only add, delete, rename fields to a RT within the existing family; but attributes cannot be changed --apart from linking a field to a term list; cannot create extra RT RM: can add, delete, move (by dragging on the "RT and fields edit" window) and rename fields within the existing family; their attributes cannot be changed; cannot create extra RT

8 - Number of fields per record

Bibus : 31 (26 + 5 custom) EW: 43 (empirically split into: most often required, optional) RW: 46 + 5 user defined that can be renamed) + 2 (RefID, RT) + attachments Pr: 45 En: max 44 + 8 'Custom' user definable + record number + record type + Date added to library + Date last updated RM: 31 + 5 called user defined + 3 miscellaneous, sometimes already used by certain RT; any user-defined field is URL and file path compatible

9 - Can create extra fields

Bibus : no EW : no RW no Pr no En: no RM: no

10 - Fields attributes can be changed; can be applied to other fields

Bibus : no EW: no RW: no Pr: no En: no

the attribute 'field linked to a term list' is customizable insofar as a field can be included in only one list, while a list can stem from a cluster of fields

RM: no

but can decide whether input in a given field is mandatory or not

11 -  Multi-value fields allowed

Bibus : authors; any field for entry list purpose: must specify occurrences' separator EW: authors; keywords; URLs RW: several (among which authors, translators, descriptors ...) Pr: Output display recognizes names and kw; automatic indexes recognize only names and kw (not the titles); sort in subject bibliography recognizes any field, provided separators are present
En: yes, names (authors, translators etc.), and kw are recognized as such in: indexing, sorting the first author, output including subject bibliographies; lists can recognize different separators in every single field (<CR> is always accepted) RM: names, kw, fields for URLs and other external resources
Bibus EndNoteWeb (web based) RefWorks (web based) Procite EndNote Reference Manager
Database and record structure Database and record structure  Database and record structure  Database and record structure  Database and record structure  Database and record structure 
Keywords:  Accucite ; Database structure ; Field attribute ; Fields - quantity available ; Groups of virtual records ; Indexed fields ; Input worksheets ; Links ; Multi-value fields ; Notes ; Record number ; Record structure ; RT ; Set

Table of contents  | Index