Database and record structure

3.4. Database and record structure

Database and record structure

RefWorks (web based) Biblioscape Bookends Library Master Procite EndNote Reference Manager Papyrus †

1 Files

RW: completely hidden (transparent) to the user: SQL-based database Bscp: relational database: dozens of files BK: not reviewed LM: 3 files: dbn.LMD dbn.LMI, dbn.LMS (respectively: data, indexes, subsets) Pr: 2 files: dbn.PDT dbn.PDX (respectively: data and indexes)
En: 1 file: dbn.ENL (+ dbn-Dupl.enl for duplicates + automatic \dbn.Data folder for storing images, text and chart files, optionally dedicated subfolders to save copy of anything stored as a relative link within the PDF field + dbn.enlx as an optional compressed version of bibliographic data + subfolders and any relevant attachments: PDF, images etc.)
Modified record types and general user preferences are stored for each user in [C]:\Documents and Settings \[user_name]\ Application Data\EndNote\RefTypeTable.xml: to entirely move libraries to another machine, this file has to be copied into the equivalent folder.
In Mac they are stored in: Users\[your folder]\Library\ Preferences\EndNote folder

RM: 2 files dbn.RMD dbn.RMX (respectively: data and indexes) Papyrus: 2 files: db db.IDX (respectively: data and indexes)

2 Internal database and record structure

RW: completely hidden (transparent) to the user Bscp: unlike all the other packages analyzed here Biblioscape is a completely relational database.
The Reference (Bibliographic) module has got main tables for bib. records, authors, keywords, journal titles. (Any single database is made up of some 40 files: since
Notes (Free text), Tasks, Charts (graphs) are separate modules, each has got its own table. Horizontal and vertical links are possible, see below.
No subfields.
(Library module is not reviewed here) BK: only vertical: Database -> Record -> Fields (-> Subfields for first names and qualifications; can extract just the four digits year in a date like: September, 20, 2002) LM: only vertical: Database -> Record -> Fields -> Subfields (where available: automatic and limited: names, dates) Pr: only vertical: Database -> Record -> Fields -> Subfields (where available: automatic and limited: names, dates, call numbers) En: only vertical: Database -> Record -> Fields -> Subfields (in personal names only: surname, name, suffix) RM: only vertical: Database -> Record -> Fields -> Subfields only in personal names (surname, the rest of the name) Papyrus: vertical: Database -> Record -> Fields -> Subfields in names
Relational: record(s) to (record(s); keyword(s) to keyword(s); record(s) to journal titles and keywords

3 Horizontal links: between databases, between records, between list entries

RW: no (folders are virtual sets, pointers to records without physical duplication) Bscp: yes (not between different Bibliographic databases) between bibliographic records, Notes, Tasks, Charts BK:no (but "groups", and marked records are pointers to records without physical duplication) LM: no (but "subsets", and marked records are pointer to records without physical duplication) Pr: no (but "groups", and marked records are pointer to records without physical duplication) En: no RM: only term synonyms in the 3 indexes (authors, kw, periodicals) : searching for one synonym is searching for all the connected terms (but "reference indexes" and marked records are pointers to records without physical duplication) Papyrus: yes, between records; between keywords; various types of links: some built-in, others can be added; Search, Print/Export recognize links for records on the basis of their type; Search recognizes links for keywords on the basis of their type

4 Hierarchical links (es. thesaurus, mother/sons records, text/notecards)

RW: no Bscp: bib. records can be linked in uni-bidrectional way via 4 types of relationship + n custom (and comment) not in a hierarchical way; list terms cannot be interlinked in a thesaurus-like manner; Notes (free text) can be linked to any other resource (bib. record, task, chart, URL, file) and viceversa, and can have hierarchical tree among notes BK: no LM: no

fields can generate indexes which are exclusive to the generator field, entirely derived from it (i.e. automatically created and updated); cannot be directly edited. Any field data and term list contents (sort of look-up) can be "crossed" in output to replace text: string + abbreviation(s)
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): their content can be imported from external text lists, updated from records, derived from different fields, directly edited. Field data and periodical title list can be crossed in output: e.g. secondary journal title (with up to three abbreviations) can replace text entered in records Journal field
RM: no

some fields generate lists which are 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
Papyrus: yes, between records; between keywords; various types of links: some built-in, others can be added; Search, Print/Export recognize links for records on the basis of their type; Search recognizes links for keywords on the basis of their type and depth

see also dedicated sections: 8 Thesaurus and 14 Term/Entry lists, authority files

5 Ready, predefined record structure

RW: yes Bscp: yes BK: yes LM: yes
they belong to each database.
Also Database templates are supplied for bibliographic research databases, library catalogs, mail lists, note taking databases, etc. and can be custom designed
Pr: yes (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

En: yes (reference types with other default preferences)

they are all automatically shared among different databases on the same computer, separately for each PC user, see above "Files"
RM: yes (reference type)
the reference types belong to each database
Papyrus: yes (reference type)
they belong to each database

6 Input worksheets for different Record types
    1. features
    2. can be modified
    3. can create others

RW: 1: actually the workform is only one, containing all the ... fields and when it is opened it includes an output style. Fields are ticked (by the Accucite feature: accurate citing) to show which ones will be considered by the output style being used 2: modifications are related to the output style being used: include/exclude fields and help i.e. fields comments that can be added to any field; 3: no, and cannot create others Bscp: 1: 27 RT. Fields are identified by number and name in the db structure (and described in each RT by appropriate document type name); fields have got attributes, e.g.: data type (numeric, alphabetic, date, memo etc.), size, required, primary or secondary index ... ;
2 yes, attributes can be changed via external DBSys.exe utility; 3 yes.
Two edit modes-windows: 1 User defined fields, 2 All fields. In User defined only fields related to the particular RT are displayed (no more than one scrolling line per field); in All fields, any field is displayed and available for input, though dimmed if not included in the RT, Memo fields can have a large window for inputting data BK:
1: 17 workforms/RT -all with the same fields- for books, articles, thesis, reviews, videos etc.; fields are identified by code: total number is fixed 16; fields may have got properties such as : repeatable (multiple: authors, keywords), linked to a term table, to the journals glossary, allowing specific formatting options;
2 may change name but not code or position within the entry/display workform LM:
1: 50 workforms/RT -with varying fields- for books, articles, thesis, reviews, videos etc.; fields are identified by name: total number is fixed max 65; fields are identified by name; any field has got properties such as : content type (text, number, name, date, call number, literature reference sources); features : repeatable (multiple), required, unique, validate new entry, ignore leading words in searching and sorting, linked to a term table (plus : only tables terms allowed, expand abbreviations if contained), indexed for faster search; fields come with predefined properties but user can change, add, port to other fields; field properties are automatically the same in all RTs (i.e. if subjects field is required, it will so through articles, thesis, computer programs etc.) 2: yes, very deeply
3: yes n,

if a field is deleted from RT, or RT is changed to a non-matching type, existing field content is lost;
as fields are identified by name, when fields names are changed in RT, styles are affected and must be manually fixed; also searching and global replace must take into account new names
Pr:
1: 39 workforms -with varying fields- for books, articles, e-mail, thesis etc.; fields bear "step" displayed name: total number is fixed max 45; 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
3: yes n, each is a file

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, searching and global editing are not
En:
1: 42 workforms / reference types -with varying fields- for book, articles, e-sources, case, bill, thesis etc. (not for journal as a whole serial);
fields bear "step" displayed name:  max 52 fields allowed; fields are identified by the position they hold in the Generic RT, fixed across all reference types; some fields (e.g. names, journal titles, pages, URL, keywords, figure, caption) have peculiarities (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
2: given the abovementioned constraints, one can add, delete, rename fields; but attributes cannot be changed --apart from linking a field to a term list 3: one can use the 7 undefined custom fields
when a field is deleted from RT (or mismatched), existing content is put to the corresponding Generic RT field; no numeric fields apart from RN for sorting; if fields names are changed in RT, styles are automatically updated, searching and global editing are not affected

RM:
1: 35 predefined forms: Reference Types -with varying fields- for books, articles, e-mail, thesis, video, electronic citation etc.; fields bear a label as "step" displayed name: max 37 fields allowed (of which: 5 user defined + 3 miscellaneous; all user-defined fields are URL and file path compatible); 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;
2: yes, given the abovementioned constraints, can add, delete, move (by dragging on the RT and fields edit window), rename fields; their attributes cannot be changed
3: no Papyrus:
1: 16 predefined forms: Reference Types -with varying fields for books, articles, internet resources, thesis etc.; fields bear a base name which identifies them plus a RT specific name; total number of built-in fields is 59;
Any field has got attributes as far as: type (more than 15 types: name, year, number...), quantity (multiple occurrences), indexing (word, phrase ... + n. of chars per indexed word), spell-checking, position within RT and mandatory/optional input
2: modify built-in reference types by adding user-created fields, and changing: name, position, mandatory/optional input of fields; user created RTs are under user's control
3: yes, can create (up to 100) new RTs and (up to 100) new fields [which can be added to built-in RTs]

7 Fields attributes can be changed; can be applied to other fields

RW: no Bscp: yes, some within Biblioscape, some via external DBSys utility (with a few limitations: e.g. length can be modified only for "chars" fields, lookup list for data input are available only for certain fields and this cannot be modified, real multi-value fields are only authors and keywords ...) BK: no LM: yes 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 to be chosen, while a list can include more fields
RM: no
but can always decide whether input in a given field is mandatory or not
Papyrus: built-in fields attributes cannot be changed (apart from: no of chars per indexed word; spell-checking and position within RT); attributes for new fields are entirely under user's control until a field is created, then it cannot be altered

8 Multi-value fields
    1. present/absent
    2. specific input rules

RW: 1 several (among which authors, translators, descriptors ...) 2 separator ";" Bscp: 1: authors, keywords 2: separator is " ; " BK: 1: authors/editors, keywords (output display can recognize first name and other occurrences); 2 each entry on a new line (if you select entries from the list, it is up to you not to leave them on the same line) LM: 1: present (output display can recognize also first last and all other occurrences); 2 each entry on a new line (if you select entries from the list, it is up to you not to leave them on the same line) Pr: 1: Output display recognizes names and kw; automatic indexes recognize only names and kw; sort in subject bibliography recognizes any field, provided occurrences are separated by: slash(es), <CR> Line Feed or semi-colon (;) in author field
2: separators for names and kw and see 1 En: names (authors, translators etc.), and kw in: indexing, sorting the first author, output including subject bibliographies; lists can recognize different separators in every single field (<CR> is always accepted)
2: each occurrence on a new line or properly separated via punctuation RM: 1 names, kw, fields for URLs and other external resources; 2 each value is separated by a semi-colon (;) Papyrus: 1 authors, editors -and their roles, publishers, places, several patents fields, keywords, pictures ... are built-in fields defined as multiple; any newly created field can be multiple and input, indexing, output will recognize this property;
2: each occurrence on a new line

9 Indexed fields for searching

RW: all the fields can be searched though differently indexed Bscp: all (some have got secondary indexes for sorting, authors, kw and journal have faster indexes), almost all generate lookup lists BK: all LM: all fields content is automatically indexed, out of user's control (apart from one general option : whole or beginning of field is the default searchable string); each character (right/left truncation), word, phrase, is indexed, with user defined stopwords only if in leading position; user can define fields as "indexed" for faster search Pr: all fields content is automatically indexed, out of user's control; each character (right/left truncation), word, phrase, is indexed, without stopwords, and thus retrievable
En: generally speaking, all fields content is automatically indexed, out of user's control; each character (right/left truncation, word, phrase), is indexed, without stopwords, and thus retrievable

(to take full advantage of this feature it used to exist "Use Full Text Index" while searching: suppressed since v. X)
RM: all fields are indexed for searching purposes: Authors, Dates, Periodical titles, kw, have special -faster- indexes.
fields number: 2 Ref ID, 4 author, 5 Date primary, 7 Keywords, 11 Periodical, 14 Secondary author, are called 'Indexed fields': they build up a special internal index with separate entries pointing to the records that contain them, searching should be faster and different from a full-text indexing (the Guide states) Papyrus: all fields content is automatically made searchable; many built-in fields are indexed to improve reterieval speed: RN, RefID, names, dates, titles, journals, medium, publishers and places, abstract, comment, kw; indexing for user created fields is under user's control

10 Record number
   1. system assigned
   2. reserved, cannot be altered
   3. user assigned
   4. allows duplicate numbers
   5. renumbering
   6. is a sortable field
   7. is a searchable field
   8. can be displayed in printed output
   9. reuse deleted numbers
   10. can be alphanumeric

RW: 1 2 6 7 8 Bscp: it acts as Ref Id, numeric primary index. Cannot be modified or reused if a record is deleted BK: two record numbers. First automatically assigned, can decrease if one deletes references. Second automatically randomly assigned (and will change when copied to another database if it conflict against existng one), can be modified by user. The second identifies the record LM: system assigned, reserved can't be modified, renumbering is possible; can be used for sort, search and display; can reuse deleted ones Pr: system assigned or user assigned if wanted; allows for duplicates; renumbering is possible; can be used for sort, search and display; reuse deleted; can be alphanumeric when manually created En: 1; 2; 5 record numbers change to avoid duplicates when records are added or copied; 6 the same for output and for sorting the database list; 7; 8

RM: 1 system and 3 user, both: either a) numeric, or b) author-date (more records of same author/same year automatically get alphabetic identifiers); 5 renumbered when copied to another database with records bearing same numbers; 6; 7; 8; 10, as 1 b) author-date Papyrus: 1; 3; 5 (only if copied to another database with records) 6; 7; 8; 9 (must manually enter); 10 as RefID

Database and record structure

RefWorks (web based)	Biblioscape	Bookends	Library Master	Procite	EndNote	Reference Manager	Papyrus †
1 Files
RW: completely hidden (transparent) to the user: SQL-based database	Bscp: relational database: dozens of files	BK: not reviewed	LM: 3 files: dbn.LMD dbn.LMI, dbn.LMS (respectively: data, indexes, subsets)	Pr: 2 files: dbn.PDT dbn.PDX (respectively: data and indexes)	En: 1 file: dbn.ENL (+ dbn-Dupl.enl for duplicates + automatic \dbn.Data folder for storing images, text and chart files, optionally dedicated subfolders to save copy of anything stored as a relative link within the PDF field + dbn.enlx as an optional compressed version of bibliographic data + subfolders and any relevant attachments: PDF, images etc.) Modified record types and general user preferences are stored for each user in [C]:\Documents and Settings \[user_name]\ Application Data\EndNote\RefTypeTable.xml: to entirely move libraries to another machine, this file has to be copied into the equivalent folder. In Mac they are stored in: Users\[your folder]\Library\ Preferences\EndNote folder	RM: 2 files dbn.RMD dbn.RMX (respectively: data and indexes)	Papyrus: 2 files: db db.IDX (respectively: data and indexes)
2 Internal database and record structure
RW: completely hidden (transparent) to the user	Bscp: unlike all the other packages analyzed here Biblioscape is a completely relational database. The Reference (Bibliographic) module has got main tables for bib. records, authors, keywords, journal titles. (Any single database is made up of some 40 files: since Notes (Free text), Tasks, Charts (graphs) are separate modules, each has got its own table. Horizontal and vertical links are possible, see below. No subfields. (Library module is not reviewed here)	BK: only vertical: Database -> Record -> Fields (-> Subfields for first names and qualifications; can extract just the four digits year in a date like: September, 20, 2002)	LM: only vertical: Database -> Record -> Fields -> Subfields (where available: automatic and limited: names, dates)	Pr: only vertical: Database -> Record -> Fields -> Subfields (where available: automatic and limited: names, dates, call numbers)	En: only vertical: Database -> Record -> Fields -> Subfields (in personal names only: surname, name, suffix)	RM: only vertical: Database -> Record -> Fields -> Subfields only in personal names (surname, the rest of the name)	Papyrus: vertical: Database -> Record -> Fields -> Subfields in names Relational: record(s) to (record(s); keyword(s) to keyword(s); record(s) to journal titles and keywords
3 Horizontal links: between databases, between records, between list entries
RW: no (folders are virtual sets, pointers to records without physical duplication)	Bscp: yes (not between different Bibliographic databases) between bibliographic records, Notes, Tasks, Charts	BK:no (but "groups", and marked records are pointers to records without physical duplication)	LM: no (but "subsets", and marked records are pointer to records without physical duplication)	Pr: no (but "groups", and marked records are pointer to records without physical duplication)	En: no	RM: only term synonyms in the 3 indexes (authors, kw, periodicals) : searching for one synonym is searching for all the connected terms (but "reference indexes" and marked records are pointers to records without physical duplication)	Papyrus: yes, between records; between keywords; various types of links: some built-in, others can be added; Search, Print/Export recognize links for records on the basis of their type; Search recognizes links for keywords on the basis of their type
4 Hierarchical links (es. thesaurus, mother/sons records, text/notecards)
RW: no	Bscp: bib. records can be linked in uni-bidrectional way via 4 types of relationship + n custom (and comment) not in a hierarchical way; list terms cannot be interlinked in a thesaurus-like manner; Notes (free text) can be linked to any other resource (bib. record, task, chart, URL, file) and viceversa, and can have hierarchical tree among notes	BK: no	LM: no fields can generate indexes which are exclusive to the generator field, entirely derived from it (i.e. automatically created and updated); cannot be directly edited. Any field data and term list contents (sort of look-up) can be "crossed" in output to replace text: string + abbreviation(s)	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): their content can be imported from external text lists, updated from records, derived from different fields, directly edited. Field data and periodical title list can be crossed in output: e.g. secondary journal title (with up to three abbreviations) can replace text entered in records Journal field	RM: no some fields generate lists which are 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	Papyrus: yes, between records; between keywords; various types of links: some built-in, others can be added; Search, Print/Export recognize links for records on the basis of their type; Search recognizes links for keywords on the basis of their type and depth see also dedicated sections: 8 Thesaurus and 14 Term/Entry lists, authority files
5 Ready, predefined record structure
RW: yes	Bscp: yes	BK: yes	LM: yes they belong to each database. Also Database templates are supplied for bibliographic research databases, library catalogs, mail lists, note taking databases, etc. and can be custom designed	Pr: yes (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	En: yes (reference types with other default preferences) they are all automatically shared among different databases on the same computer, separately for each PC user, see above "Files"	RM: yes (reference type) the reference types belong to each database	Papyrus: yes (reference type) they belong to each database
6 Input worksheets for different Record types 1. features 2. can be modified 3. can create others
RW: 1: actually the workform is only one, containing all the ... fields and when it is opened it includes an output style. Fields are ticked (by the Accucite feature: accurate citing) to show which ones will be considered by the output style being used 2: modifications are related to the output style being used: include/exclude fields and help i.e. fields comments that can be added to any field; 3: no, and cannot create others	Bscp: 1: 27 RT. Fields are identified by number and name in the db structure (and described in each RT by appropriate document type name); fields have got attributes, e.g.: data type (numeric, alphabetic, date, memo etc.), size, required, primary or secondary index ... ; 2 yes, attributes can be changed via external DBSys.exe utility; 3 yes. Two edit modes-windows: 1 User defined fields, 2 All fields. In User defined only fields related to the particular RT are displayed (no more than one scrolling line per field); in All fields, any field is displayed and available for input, though dimmed if not included in the RT, Memo fields can have a large window for inputting data	BK: 1: 17 workforms/RT -all with the same fields- for books, articles, thesis, reviews, videos etc.; fields are identified by code: total number is fixed 16; fields may have got properties such as : repeatable (multiple: authors, keywords), linked to a term table, to the journals glossary, allowing specific formatting options; 2 may change name but not code or position within the entry/display workform	LM: 1: 50 workforms/RT -with varying fields- for books, articles, thesis, reviews, videos etc.; fields are identified by name: total number is fixed max 65; fields are identified by name; any field has got properties such as : content type (text, number, name, date, call number, literature reference sources); features : repeatable (multiple), required, unique, validate new entry, ignore leading words in searching and sorting, linked to a term table (plus : only tables terms allowed, expand abbreviations if contained), indexed for faster search; fields come with predefined properties but user can change, add, port to other fields; field properties are automatically the same in all RTs (i.e. if subjects field is required, it will so through articles, thesis, computer programs etc.) 2: yes, very deeply 3: yes n, if a field is deleted from RT, or RT is changed to a non-matching type, existing field content is lost; as fields are identified by name, when fields names are changed in RT, styles are affected and must be manually fixed; also searching and global replace must take into account new names	Pr: 1: 39 workforms -with varying fields- for books, articles, e-mail, thesis etc.; fields bear "step" displayed name: total number is fixed max 45; 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 3: yes n, each is a file 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, searching and global editing are not	En: 1: 42 workforms / reference types -with varying fields- for book, articles, e-sources, case, bill, thesis etc. (not for journal as a whole serial); fields bear "step" displayed name: max 52 fields allowed; fields are identified by the position they hold in the Generic RT, fixed across all reference types; some fields (e.g. names, journal titles, pages, URL, keywords, figure, caption) have peculiarities (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 2: given the abovementioned constraints, one can add, delete, rename fields; but attributes cannot be changed --apart from linking a field to a term list 3: one can use the 7 undefined custom fields when a field is deleted from RT (or mismatched), existing content is put to the corresponding Generic RT field; no numeric fields apart from RN for sorting; if fields names are changed in RT, styles are automatically updated, searching and global editing are not affected	RM: 1: 35 predefined forms: Reference Types -with varying fields- for books, articles, e-mail, thesis, video, electronic citation etc.; fields bear a label as "step" displayed name: max 37 fields allowed (of which: 5 user defined + 3 miscellaneous; all user-defined fields are URL and file path compatible); 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; 2: yes, given the abovementioned constraints, can add, delete, move (by dragging on the RT and fields edit window), rename fields; their attributes cannot be changed 3: no	Papyrus: 1: 16 predefined forms: Reference Types -with varying fields for books, articles, internet resources, thesis etc.; fields bear a base name which identifies them plus a RT specific name; total number of built-in fields is 59; Any field has got attributes as far as: type (more than 15 types: name, year, number...), quantity (multiple occurrences), indexing (word, phrase ... + n. of chars per indexed word), spell-checking, position within RT and mandatory/optional input 2: modify built-in reference types by adding user-created fields, and changing: name, position, mandatory/optional input of fields; user created RTs are under user's control 3: yes, can create (up to 100) new RTs and (up to 100) new fields [which can be added to built-in RTs]
7 Fields attributes can be changed; can be applied to other fields
RW: no	Bscp: yes, some within Biblioscape, some via external DBSys utility (with a few limitations: e.g. length can be modified only for "chars" fields, lookup list for data input are available only for certain fields and this cannot be modified, real multi-value fields are only authors and keywords ...)	BK: no	LM: yes	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 to be chosen, while a list can include more fields	RM: no but can always decide whether input in a given field is mandatory or not	Papyrus: built-in fields attributes cannot be changed (apart from: no of chars per indexed word; spell-checking and position within RT); attributes for new fields are entirely under user's control until a field is created, then it cannot be altered
8 Multi-value fields 1. present/absent 2. specific input rules
RW: 1 several (among which authors, translators, descriptors ...) 2 separator ";"	Bscp: 1: authors, keywords 2: separator is " ; "	BK: 1: authors/editors, keywords (output display can recognize first name and other occurrences); 2 each entry on a new line (if you select entries from the list, it is up to you not to leave them on the same line)	LM: 1: present (output display can recognize also first last and all other occurrences); 2 each entry on a new line (if you select entries from the list, it is up to you not to leave them on the same line)	Pr: 1: Output display recognizes names and kw; automatic indexes recognize only names and kw; sort in subject bibliography recognizes any field, provided occurrences are separated by: slash(es), <CR> Line Feed or semi-colon (;) in author field 2: separators for names and kw and see 1	En: names (authors, translators etc.), and kw in: indexing, sorting the first author, output including subject bibliographies; lists can recognize different separators in every single field (<CR> is always accepted) 2: each occurrence on a new line or properly separated via punctuation	RM: 1 names, kw, fields for URLs and other external resources; 2 each value is separated by a semi-colon (;)	Papyrus: 1 authors, editors -and their roles, publishers, places, several patents fields, keywords, pictures ... are built-in fields defined as multiple; any newly created field can be multiple and input, indexing, output will recognize this property; 2: each occurrence on a new line
9 Indexed fields for searching
RW: all the fields can be searched though differently indexed	Bscp: all (some have got secondary indexes for sorting, authors, kw and journal have faster indexes), almost all generate lookup lists	BK: all	LM: all fields content is automatically indexed, out of user's control (apart from one general option : whole or beginning of field is the default searchable string); each character (right/left truncation), word, phrase, is indexed, with user defined stopwords only if in leading position; user can define fields as "indexed" for faster search	Pr: all fields content is automatically indexed, out of user's control; each character (right/left truncation), word, phrase, is indexed, without stopwords, and thus retrievable	En: generally speaking, all fields content is automatically indexed, out of user's control; each character (right/left truncation, word, phrase), is indexed, without stopwords, and thus retrievable (to take full advantage of this feature it used to exist "Use Full Text Index" while searching: suppressed since v. X)	RM: all fields are indexed for searching purposes: Authors, Dates, Periodical titles, kw, have special -faster- indexes. fields number: 2 Ref ID, 4 author, 5 Date primary, 7 Keywords, 11 Periodical, 14 Secondary author, are called 'Indexed fields': they build up a special internal index with separate entries pointing to the records that contain them, searching should be faster and different from a full-text indexing (the Guide states)	Papyrus: all fields content is automatically made searchable; many built-in fields are indexed to improve reterieval speed: RN, RefID, names, dates, titles, journals, medium, publishers and places, abstract, comment, kw; indexing for user created fields is under user's control
10 Record number 1. system assigned 2. reserved, cannot be altered 3. user assigned 4. allows duplicate numbers 5. renumbering 6. is a sortable field 7. is a searchable field 8. can be displayed in printed output 9. reuse deleted numbers 10. can be alphanumeric
RW: 1 2 6 7 8	Bscp: it acts as Ref Id, numeric primary index. Cannot be modified or reused if a record is deleted	BK: two record numbers. First automatically assigned, can decrease if one deletes references. Second automatically randomly assigned (and will change when copied to another database if it conflict against existng one), can be modified by user. The second identifies the record	LM: system assigned, reserved can't be modified, renumbering is possible; can be used for sort, search and display; can reuse deleted ones	Pr: system assigned or user assigned if wanted; allows for duplicates; renumbering is possible; can be used for sort, search and display; reuse deleted; can be alphanumeric when manually created	En: 1; 2; 5 record numbers change to avoid duplicates when records are added or copied; 6 the same for output and for sorting the database list; 7; 8	RM: 1 system and 3 user, both: either a) numeric, or b) author-date (more records of same author/same year automatically get alphabetic identifiers); 5 renumbered when copied to another database with records bearing same numbers; 6; 7; 8; 10, as 1 b) author-date	Papyrus: 1; 3; 5 (only if copied to another database with records) 6; 7; 8; 9 (must manually enter); 10 as RefID

Database and record structure

1 Files

2 Internal database and record structure

3 Horizontal links: between databases, between records, between list entries

4 Hierarchical links (es. thesaurus, mother/sons records, text/notecards)

5 Ready, predefined record structure

6 Input worksheets for different Record types 1. features 2. can be modified 3. can create others

7 Fields attributes can be changed; can be applied to other fields

8 Multi-value fields 1. present/absent 2. specific input rules

9 Indexed fields for searching

10 Record number 1. system assigned 2. reserved, cannot be altered 3. user assigned 4. allows duplicate numbers 5. renumbering 6. is a sortable field 7. is a searchable field 8. can be displayed in printed output 9. reuse deleted numbers 10. can be alphanumeric

6 Input worksheets for different Record types
1. features
2. can be modified
3. can create others

8 Multi-value fields
1. present/absent
2. specific input rules

10 Record number
1. system assigned
2. reserved, cannot be altered
3. user assigned
4. allows duplicate numbers
5. renumbering
6. is a sortable field
7. is a searchable field
8. can be displayed in printed output
9. reuse deleted numbers
10. can be alphanumeric