Term/Entry lists

3.14. Term/Entry lists

Term/Entry lists

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

Features in general
3 lists available: pre-defined, unmodifiable for authors (i.e. any name field), journal titles, kw-descriptors.
The lists receive just what you enter in the records, automatically. The feature can be disabled in customization settings.

Lists entries can be directly edited and the change is instantly reflected in the record(s) containing the entries.

Lists can also be used as lookup lists in searching records

While editing records also a short journal titles lookup list is available
Features in general

Virtually any field (56 available in the standard db structure, but Notes, Abstract, Miscellaneous, and Document never available) can have its own 'lookup list'. Usually (apart from main, secondary, tertiary ... authors) each field generates its own list, thus you will not find Authors in the Producers list.
Lists content automatically (when you edit an entry, then Refresh) reflects field content: they are dynamically generated. They are not separated from database, cannot be independently accessed nor shared with other db. They can be used to browse the short record list of the db, to retrieve records.
Lookup lists are useful during data input (there are not as many as for searching and it is not customizable); autocompletion available; new entries are instantly accessible.
To edit an index entry, one directly edits the entry in the list via dedicated find/replace function where Regular expressions can be used.
Only authors and keywords can really handle repeated values as separate strings, e.g.:
Keywords: water pollution; fire produces two entries in the list, whilst: Place of publication: Rome; Florence still produces one single entry in the list.
No alphabetic scrolling at all, must use mouse; A/D sorting on entries or related document counter

One Term table: accessible from any field. The list is made up of terms, and their possible abbreviations, grouped by category. Abbreviation and category serve as terms filter. Only the term is inserted in the field. Can be imported and exported as tabbed delimited file.

One Journal list : each title on a line, three possible values, import/export as tab delimited file. Only useful in output Features in general

Indexes : four built-in indexes (called: "term lists") directly linked to fields content : authors, editors, keywords, journals. Any other field can generate its term list upon user's choice
Predeterminated structure. Each one exclusively belongs to the field that originates it, thus authors and editors are separate files. Indexes content automatically reflects field content, can host unlinked entries only as long as you do not update the list. They are not separated from database, cannot be independently accessed nor shared with other db. They can be used to browse the short record list of the db in two situations: 1) select "Utilities" --> Term Lists; 2) while editing/browsing (no different mode) a record, i.e.: a) a full reference is displayed, b) the relevant term list button is pressed, c) the brief view of records connected to that entry is activated; thereby can swiftly change list.
They are useful during data input; autocompletion available; new entries are instantly accessible.
To edit an index entry, one must edit one record or more via global replace: no direct access to the entry in the list.
Terms lists: Journal Glossaries are just term lists and not indexes at all. Their structure pattern is: "Abbreviation | Short Name | Full Name"
While editing, the abbreviation can be replaced by either short or full name. In formatted output can choose short or full form. As external tables they are shared among databases, do not reflect fields content, are edited separately.
Remarks : alphabetic scrolling and autocompletion are efficient. In general lists's structure is stiff: cannot import, share -either between databases and fields-, or host independent entries. 1:1 unmodifiable relationship between field and index is not at all an advantage, though theoretically logic, see e.g. authors and editors Features in general

Indexes: lists directly linked to fields content are available only when a field is indexed. Virtually any field can be indexed -by default some are- in order to speed search up, to sort the database. Their predeterminated structure cannot be modified, apart from the length of the key to be indexed. Each index exclusively belongs to the field that originates it (thus authors, editors, translators would be stored in different, watertight, indexes). Indexes content automatically reflects fields content, cannot host more or less data. They are not separated from database, cannot be independently accessed nor shared with other db. While browsing the short record list of the db, they allow to jump to the relevant record(s) by entering the desired key.
They can be used during data input and searching.
To edit an index entry, one must edit one record or more via global replace.
Journal lists are regarded as all other Terms lists (tables)
Terms lists: lists of entries to exploit during data input and output.
They never automatically reflect field content and can host data not present in records. One can force fields to accept data only if already present in a table. Any field can invoke a term list. They are free as quantity and name are concerned. They are separated from a database and can be shared across databases, can be exported, imported, merged with external text files or other term tables of the same database (merge is supposed to warn you that duplicates were present and discarded). Their structure pattern is: "String | Abbreviation 1 | Abbreviation 2 | Abbreviation 3 | Abbreviation 4"
style can configure the string to be replaced by specified abbreviation during output; any abbreviation entered in a field can be expanded to the relevant string (the relationship can be the reverse : "Abbreviation | String 1 | String 2 | etc."
Remarks : alphabetic scrolling is very good. 1:1 relationship between field and index is not at all an advantage Features in general

Indexes (4 Field Content Lists: Authors, Titles, Journals, Keywords) predeterminated, structure cannot be modified: fixed number: 4; content and update are derived and automatic; not separate from database, cannot be independently accessed nor shared with other db. In quick search work as retrieving tool as each entry points to related records;
Journal list(s): fn.PJL, each style can link "source" field to any (free number and name) list, whose structure pattern is: "Title | Abbreviation | Note": "Journal of American ... | JAMA | online ed."; abbreviation can replace title in output; list can be shared among differenet db;
Alternate text (ALTERNAT.TXT): does not have to do with styles (cannot be seen in Formatted reference display), but with printing in general, where text in record fields put between «...» can be replaced by its text equivalent put in an external text file whose structure pattern is: "text {text equivalent} | note"; fixed name, one for db and can be shared with others;
Don't use «...» as normal punctuation; idiosyncracies: punctuation marks cannot end text: N.A.T.O.; does not work within sort headings; text is case sensitive;
Terms list, fn.PJL: any other list (n) apart from the abovementioned; free number and name; structure: "text | note"; can be shared with other db;
All lists apart from 4 indexes can contain entries not derived from records (import or direct input, edit and deletion); automatic duplicate detection and sort
Remarks : alphabetic scrolling: keying in "MARCIN" can bring to "MARCIN" or to "N" depending on keying speed Features in general

Term lists: 3: authors, journals, keywords by default: can be deeply modified; Other lists: free number up to 31; user can choose from which fields list entries are derived both permanently and on the fly (n fields to 1 list, but a given field can automatically update only 1 list);
All lists: content can be automatically derived during input, import, copying records, or updated in batch mode; can set delimiters for multivalue fields; batch update of list from all or only selected references; any field can resort to entry lists; to change terms in the fields one has to perform global change, cannot act directly onto the lists; automatic duplicate detection and sort between entries; terms can be suggested during input if term already exists in the list (auto-completion); terms which are new to the list are highlighted and coloured; document total number linked to each entry is never shown. Journals lists with up to 3 abbreviations, can be individually selected in output styles. No list is physically separated from database thus cannot be shared with others (unless you export and import it in another db or you select terms in a list and then copy and paste to a list in another database -Ctrl-C Ctrl-V: no Menu otpions available)
Remarks: alphabetic scrolling -incremental search- is fairly good: keying in "MARC" usually brings to "MARC" and not to "C" (MARC) Features in general

Terms lists 3 Lists: Authors, Journals, Keywords connected only to correspondent fields whose contents cannot but being automatically included in them; fixed number: 3; not separate from database; can be independently managed: can add terms not present in records, global edit, purge, print list terms; lists cannot be shared with other db (but Periodical list can be copied); cannot be accessed from other fields, but from the Lists can copy terms to any list; in searching work as pick up lists;
Synonyms: each author and kw can have up to 255 synonyms, periodical title up to 3 (output style can use them). Synonyms automatically become physically reciprocal: A with syn. B C, then B with syn. A C etc. They can be used in searching not in editing (unless you work from the Lists towards the refs). Syn. of different terms can be combined (summed, ored)
Phrase list: one single list of "strings": user created (not imported), strings can be picked up later while editing any reference field Features in general

System lists: keywords, journals, glossary, names (to a certain extent, see details below); Indexes: any list generated by any "whole-indexed" field (such as built-in: RefID, Document type, Place and Publishers: user can create new).
Within the kw and journals lists, one can directly edit, merge, create, delete, import entries, quick find linked records, print the entries, without going through the db records. New entries created during record cataloging are validated against these lists. In addition, completely apart from records content: kw have got links (see Section 8 Thesaurus); journals have abbreviation list(s), call number, ISSN, URL, comments.
Within the Names list, entries can be directly edited (spelling and sort form), imported (only as far as sort forms are concerned), printed and they can quickly find linked records, but cannot be created or deleted.
The Glossary list is a generic term list for any not-indexed field: entries can be directly edited, created, imported, printed, deleted.
All the lists can be used during input and search directly from the relevant fields, or from any field by choosing the appropriate window

1 Fixed number

RW: yes 3 Bscp: ca 56 (some cannot be included) BK: no, 4 + any other field based + n journal glossaries LM: no Pr: yes 4 indexes, not the others En: no fixed: the 3 basic term lists are just a default, they can be deleted, others can be added up to max 31 (unlimited number of entries, each 253 chars long) RM: yes 3 term lists + 1 optional Phrase list Papyrus: the System lists cannot be altered or duplicated, one can create indexes for other fields

2 Lists' content is automatically derived from db data, and/or can contain external data

RW: only derived Bscp: only derived, as far as the lookup lists are concerned. Term table and Journal name list can import/export text tab delimited files BK: only derived as far as the 4 built-in lists are concerned. Journal glossaries are independent and host their own data LM: indexes: only derived; terms lists : can contain external data Pr: 4 indexes: only derived; others : can contain external data En: lists derive data from one or more fields (both permanently and on the fly) according to user's preferences; updating can be batch or automatic; any list can have content not derived from records (direct input or import from external source) RM: content is derived, lists can also host entries not already contained in records Papyrus: kw, journals and glossary might have their own entries not referenced within the records. All the others, names included, only reflect records content

3 Lists are physically separated from database

RW: no Bscp: no the lookup lists. Term table and Journal name list can be copied and used by other db BK: no as far as the term lists are concerned, yes the Journal glossaries LM: not the indexes, yes the Terms tables Pr: 4 built-in indexes are embedded, other lists are distinct text files En: no, they are all embedded (can be copied, see below) RM: no, they are embedded Papyrus: no, System lists -kw and journals- are relationally linked to the db; their entries can also be exported and imported into another database

4 Lists reflect records content in real time

RW: yes Bscp: yes (Refresh if edit an entry) BK: yes LM: yes the indexes Pr: yes 4 indexes, not the others: batch update En: yes, if this preference is selected; batch update is also possible RM: yes Papyrus: yes

5 Lists can be directly edited

RW: yes Bscp: kind of: via dedicated find/replace function BK: no, only Journal Glossaries LM: not the indexes (one would need to edit record content), yes the tables Pr: not the 4 indexes (they need Global Edit), yes the others En: yes, all, but it has no influence on the entries actually contained in the records RM: yes as straightforward global edit from Term manager Papyrus: yes, the System lists

6 When list entries are edited, records content change

RW: yes Bscp: yes, see above BK: no, must perform global change LM: never, must perform a global change Pr: never, must perform a global change En: never, must perform a global change RM: as a result of global editing in Term Manager Papyrus: yes

7 New entries are validated ("go list", e.g.: new, old, probably a duplicate)

RW: the list it automatically opened at the closest match Bscp: no BK: no LM: yes, it is an option (for any type of field) Pr: no En: new entries displayed in red; close or identical term is suggested (auto-completion) RM: yes (new are highlighted) Papyrus: yes (new kw and journals)

8 List entry can contain its own supplementary data: note, abbreviation, date, compiler, x-refs

RW: no Bscp: no, only term Table and Journal List may have other values for each entry, see above Features in general BK: no, only Journal Glossaries may have up to three forms for each entry, see above Features in general LM: only terms lists can contain up to 4 abbreviations or equivalent terms Pr: not the 4 indexes; yes journal list(s): abbreviation + note; yes other lists: max 2 additional fields as notes En: any list defined as "journal list" can have up to 3 abbreviations, and no other data RM: synonyms terms, which -on their turn- become entries of the list; journal titles list can have up to 3 abbreviations Papyrus : kw have got links (see Section 8 Thesaurus); journals have abbreviation list(s), call number, ISSN, URL, comments.

9 Lists can be printed

RW: no Bscp: yes, use mouse right click on the list and save it as Excel or text file BK: yes, first save a text file LM: yes all Pr: yes all En: yes all (export as .TXT file) RM: yes (all the 3 lists) Papyrus: yes

10 Import external data into the lists

RW: no Bscp: no the lookup lists, yes the Term table and the Journal list BK: no LM: not the indexes, yes the terms lists Pr: no 4 indexes, yes the others En: yes RM: no
while importing, non abbreviated words of journal titles are automatically stored in the Periodical term dictionary
Papyrus: yes into the System lists

11 Lists are useful for input

RW: yes Bscp: yes BK: yes LM: yes Pr: yes En: yes RM: yes Papyrus: yes

12 Lists are useful for searching

RW: yes Bscp: yes BK: yes
do not start from the Search/Find window, but either select "Utilities" --> Term lists, or: when a full reference is displayed, press the relevant term list button (for the four built-in lists), activate the "disclosure triangle" : the brief view of records connected to that entry is shown; can thereby directly switch to another list
LM: the indexes are pick-up lists for search terms and they speed search up Pr: yes, while browsing, indexes directly display related records En: yes, but only to the extent that you can open a list and pick terms up from it to insert in the query RM: yes (pick-up lists or faster access via Term Manager) Papyrus: yes; while browsing they do not display records not contextually, but quickly find related records

13 Lists are useful for output

RW: no Bscp: only Journal list BK: only Journal Glossaries LM: yes the tables Pr: ALTERNAT.TXT to replace «text» strings; matching entries in journal list En: journal list are also designed to replace field content by an abbreviation
RM: periodical list Papyrus: abbreviations for the journals list

14 List entries show total number of related documents

RW: yes Bscp: yes BK: yes LM: no Pr: yes 4 indexes En: no RM: no (only when printed out) Papyrus: yes, kw, journals and names

15 Lists can be shared among different db

RW: n.a. Bscp: only Term table and Journal list if copied to different folder BK: no, only Journal Glossaries LM: not the indexes, yest the Terms lists Pr: indexes can be accessed -rather than shared- from different databases; other lists can be shared En: no (but you can Copy and Paste an entire list or part of it) RM: no, apart from the periodical list that can be copied from one database to another ("Term Manager" --> Copy periodicals Papyrus: no, but kw, journals (and partially names) entries can be exported and imported into another database

16 How lists are created and updated:
   1. input: new entries automatically update the list
   2. ad hoc command to edit lists out of records
   3. import
   4. as a text file out of the program

RW: 1 Bscp: 1 2; 3 and 4 as far as Term and Journal lists are concerned BK: 1 2 only as far as Journal Glossaries are concerned LM: 1: indexes; 2 3 4 terms lists Pr: 1: 4 indexes 2: all other lists 3: yes all apart from indexes; 4: all lists apart from indexes En: 1 2 3 (4: it must be imported) RM: 1; 2 Papyrus: 1; 2 System lists; 3 System lists

17 How lists are printed
    1. from the outside, as text file
    2. from the inside, by ad hoc printing function

RW: n.a. Bscp: 1 2 as far as Term and Journal lists are concerned BK: 1 LM: indexes should be printed via an output Format; terms lists via ad hoc printing command button Pr:    1: ALTERNAT.TXT
   2: indexes: Print Subject Bibliography (Subject terms only)
   other lists: File -> Open, export and save file En: 2 export as a .TXT file RM: 2 Papyrus: 2

Term/Entry lists

RefWorks (web based)	Biblioscape	Bookends	Library Master	Procite	EndNote	Reference Manager	Papyrus †
Features in general 3 lists available: pre-defined, unmodifiable for authors (i.e. any name field), journal titles, kw-descriptors. The lists receive just what you enter in the records, automatically. The feature can be disabled in customization settings. Lists entries can be directly edited and the change is instantly reflected in the record(s) containing the entries. Lists can also be used as lookup lists in searching records While editing records also a short journal titles lookup list is available	Features in general Virtually any field (56 available in the standard db structure, but Notes, Abstract, Miscellaneous, and Document never available) can have its own 'lookup list'. Usually (apart from main, secondary, tertiary ... authors) each field generates its own list, thus you will not find Authors in the Producers list. Lists content automatically (when you edit an entry, then Refresh) reflects field content: they are dynamically generated. They are not separated from database, cannot be independently accessed nor shared with other db. They can be used to browse the short record list of the db, to retrieve records. Lookup lists are useful during data input (there are not as many as for searching and it is not customizable); autocompletion available; new entries are instantly accessible. To edit an index entry, one directly edits the entry in the list via dedicated find/replace function where Regular expressions can be used. Only authors and keywords can really handle repeated values as separate strings, e.g.: Keywords: water pollution; fire produces two entries in the list, whilst: Place of publication: Rome; Florence still produces one single entry in the list. No alphabetic scrolling at all, must use mouse; A/D sorting on entries or related document counter One Term table: accessible from any field. The list is made up of terms, and their possible abbreviations, grouped by category. Abbreviation and category serve as terms filter. Only the term is inserted in the field. Can be imported and exported as tabbed delimited file. One Journal list : each title on a line, three possible values, import/export as tab delimited file. Only useful in output	Features in general Indexes : four built-in indexes (called: "term lists") directly linked to fields content : authors, editors, keywords, journals. Any other field can generate its term list upon user's choice Predeterminated structure. Each one exclusively belongs to the field that originates it, thus authors and editors are separate files. Indexes content automatically reflects field content, can host unlinked entries only as long as you do not update the list. They are not separated from database, cannot be independently accessed nor shared with other db. They can be used to browse the short record list of the db in two situations: 1) select "Utilities" --> Term Lists; 2) while editing/browsing (no different mode) a record, i.e.: a) a full reference is displayed, b) the relevant term list button is pressed, c) the brief view of records connected to that entry is activated; thereby can swiftly change list. They are useful during data input; autocompletion available; new entries are instantly accessible. To edit an index entry, one must edit one record or more via global replace: no direct access to the entry in the list. Terms lists: Journal Glossaries are just term lists and not indexes at all. Their structure pattern is: "Abbreviation \| Short Name \| Full Name" While editing, the abbreviation can be replaced by either short or full name. In formatted output can choose short or full form. As external tables they are shared among databases, do not reflect fields content, are edited separately. Remarks : alphabetic scrolling and autocompletion are efficient. In general lists's structure is stiff: cannot import, share -either between databases and fields-, or host independent entries. 1:1 unmodifiable relationship between field and index is not at all an advantage, though theoretically logic, see e.g. authors and editors	Features in general Indexes: lists directly linked to fields content are available only when a field is indexed. Virtually any field can be indexed -by default some are- in order to speed search up, to sort the database. Their predeterminated structure cannot be modified, apart from the length of the key to be indexed. Each index exclusively belongs to the field that originates it (thus authors, editors, translators would be stored in different, watertight, indexes). Indexes content automatically reflects fields content, cannot host more or less data. They are not separated from database, cannot be independently accessed nor shared with other db. While browsing the short record list of the db, they allow to jump to the relevant record(s) by entering the desired key. They can be used during data input and searching. To edit an index entry, one must edit one record or more via global replace. Journal lists are regarded as all other Terms lists (tables) Terms lists: lists of entries to exploit during data input and output. They never automatically reflect field content and can host data not present in records. One can force fields to accept data only if already present in a table. Any field can invoke a term list. They are free as quantity and name are concerned. They are separated from a database and can be shared across databases, can be exported, imported, merged with external text files or other term tables of the same database (merge is supposed to warn you that duplicates were present and discarded). Their structure pattern is: "String \| Abbreviation 1 \| Abbreviation 2 \| Abbreviation 3 \| Abbreviation 4" style can configure the string to be replaced by specified abbreviation during output; any abbreviation entered in a field can be expanded to the relevant string (the relationship can be the reverse : "Abbreviation \| String 1 \| String 2 \| etc." Remarks : alphabetic scrolling is very good. 1:1 relationship between field and index is not at all an advantage	Features in general Indexes (4 Field Content Lists: Authors, Titles, Journals, Keywords) predeterminated, structure cannot be modified: fixed number: 4; content and update are derived and automatic; not separate from database, cannot be independently accessed nor shared with other db. In quick search work as retrieving tool as each entry points to related records; Journal list(s): fn.PJL, each style can link "source" field to any (free number and name) list, whose structure pattern is: "Title \| Abbreviation \| Note": "Journal of American ... \| JAMA \| online ed."; abbreviation can replace title in output; list can be shared among differenet db; Alternate text (ALTERNAT.TXT): does not have to do with styles (cannot be seen in Formatted reference display), but with printing in general, where text in record fields put between «...» can be replaced by its text equivalent put in an external text file whose structure pattern is: "text {text equivalent} \| note"; fixed name, one for db and can be shared with others; Don't use «...» as normal punctuation; idiosyncracies: punctuation marks cannot end text: N.A.T.O.; does not work within sort headings; text is case sensitive; Terms list, fn.PJL: any other list (n) apart from the abovementioned; free number and name; structure: "text \| note"; can be shared with other db; All lists apart from 4 indexes can contain entries not derived from records (import or direct input, edit and deletion); automatic duplicate detection and sort Remarks : alphabetic scrolling: keying in "MARCIN" can bring to "MARCIN" or to "N" depending on keying speed	Features in general Term lists: 3: authors, journals, keywords by default: can be deeply modified; Other lists: free number up to 31; user can choose from which fields list entries are derived both permanently and on the fly (n fields to 1 list, but a given field can automatically update only 1 list); All lists: content can be automatically derived during input, import, copying records, or updated in batch mode; can set delimiters for multivalue fields; batch update of list from all or only selected references; any field can resort to entry lists; to change terms in the fields one has to perform global change, cannot act directly onto the lists; automatic duplicate detection and sort between entries; terms can be suggested during input if term already exists in the list (auto-completion); terms which are new to the list are highlighted and coloured; document total number linked to each entry is never shown. Journals lists with up to 3 abbreviations, can be individually selected in output styles. No list is physically separated from database thus cannot be shared with others (unless you export and import it in another db or you select terms in a list and then copy and paste to a list in another database -Ctrl-C Ctrl-V: no Menu otpions available) Remarks: alphabetic scrolling -incremental search- is fairly good: keying in "MARC" usually brings to "MARC" and not to "C" (MARC)	Features in general Terms lists 3 Lists: Authors, Journals, Keywords connected only to correspondent fields whose contents cannot but being automatically included in them; fixed number: 3; not separate from database; can be independently managed: can add terms not present in records, global edit, purge, print list terms; lists cannot be shared with other db (but Periodical list can be copied); cannot be accessed from other fields, but from the Lists can copy terms to any list; in searching work as pick up lists; Synonyms: each author and kw can have up to 255 synonyms, periodical title up to 3 (output style can use them). Synonyms automatically become physically reciprocal: A with syn. B C, then B with syn. A C etc. They can be used in searching not in editing (unless you work from the Lists towards the refs). Syn. of different terms can be combined (summed, ored) Phrase list: one single list of "strings": user created (not imported), strings can be picked up later while editing any reference field	Features in general System lists: keywords, journals, glossary, names (to a certain extent, see details below); Indexes: any list generated by any "whole-indexed" field (such as built-in: RefID, Document type, Place and Publishers: user can create new). Within the kw and journals lists, one can directly edit, merge, create, delete, import entries, quick find linked records, print the entries, without going through the db records. New entries created during record cataloging are validated against these lists. In addition, completely apart from records content: kw have got links (see Section 8 Thesaurus); journals have abbreviation list(s), call number, ISSN, URL, comments. Within the Names list, entries can be directly edited (spelling and sort form), imported (only as far as sort forms are concerned), printed and they can quickly find linked records, but cannot be created or deleted. The Glossary list is a generic term list for any not-indexed field: entries can be directly edited, created, imported, printed, deleted. All the lists can be used during input and search directly from the relevant fields, or from any field by choosing the appropriate window
1 Fixed number
RW: yes 3	Bscp: ca 56 (some cannot be included)	BK: no, 4 + any other field based + n journal glossaries	LM: no	Pr: yes 4 indexes, not the others	En: no fixed: the 3 basic term lists are just a default, they can be deleted, others can be added up to max 31 (unlimited number of entries, each 253 chars long)	RM: yes 3 term lists + 1 optional Phrase list	Papyrus: the System lists cannot be altered or duplicated, one can create indexes for other fields
2 Lists' content is automatically derived from db data, and/or can contain external data
RW: only derived	Bscp: only derived, as far as the lookup lists are concerned. Term table and Journal name list can import/export text tab delimited files	BK: only derived as far as the 4 built-in lists are concerned. Journal glossaries are independent and host their own data	LM: indexes: only derived; terms lists : can contain external data	Pr: 4 indexes: only derived; others : can contain external data	En: lists derive data from one or more fields (both permanently and on the fly) according to user's preferences; updating can be batch or automatic; any list can have content not derived from records (direct input or import from external source)	RM: content is derived, lists can also host entries not already contained in records	Papyrus: kw, journals and glossary might have their own entries not referenced within the records. All the others, names included, only reflect records content
3 Lists are physically separated from database
RW: no	Bscp: no the lookup lists. Term table and Journal name list can be copied and used by other db	BK: no as far as the term lists are concerned, yes the Journal glossaries	LM: not the indexes, yes the Terms tables	Pr: 4 built-in indexes are embedded, other lists are distinct text files	En: no, they are all embedded (can be copied, see below)	RM: no, they are embedded	Papyrus: no, System lists -kw and journals- are relationally linked to the db; their entries can also be exported and imported into another database
4 Lists reflect records content in real time
RW: yes	Bscp: yes (Refresh if edit an entry)	BK: yes	LM: yes the indexes	Pr: yes 4 indexes, not the others: batch update	En: yes, if this preference is selected; batch update is also possible	RM: yes	Papyrus: yes
5 Lists can be directly edited
RW: yes	Bscp: kind of: via dedicated find/replace function	BK: no, only Journal Glossaries	LM: not the indexes (one would need to edit record content), yes the tables	Pr: not the 4 indexes (they need Global Edit), yes the others	En: yes, all, but it has no influence on the entries actually contained in the records	RM: yes as straightforward global edit from Term manager	Papyrus: yes, the System lists
6 When list entries are edited, records content change
RW: yes	Bscp: yes, see above	BK: no, must perform global change	LM: never, must perform a global change	Pr: never, must perform a global change	En: never, must perform a global change	RM: as a result of global editing in Term Manager	Papyrus: yes
7 New entries are validated ("go list", e.g.: new, old, probably a duplicate)
RW: the list it automatically opened at the closest match	Bscp: no	BK: no	LM: yes, it is an option (for any type of field)	Pr: no	En: new entries displayed in red; close or identical term is suggested (auto-completion)	RM: yes (new are highlighted)	Papyrus: yes (new kw and journals)
8 List entry can contain its own supplementary data: note, abbreviation, date, compiler, x-refs
RW: no	Bscp: no, only term Table and Journal List may have other values for each entry, see above Features in general	BK: no, only Journal Glossaries may have up to three forms for each entry, see above Features in general	LM: only terms lists can contain up to 4 abbreviations or equivalent terms	Pr: not the 4 indexes; yes journal list(s): abbreviation + note; yes other lists: max 2 additional fields as notes	En: any list defined as "journal list" can have up to 3 abbreviations, and no other data	RM: synonyms terms, which -on their turn- become entries of the list; journal titles list can have up to 3 abbreviations	Papyrus : kw have got links (see Section 8 Thesaurus); journals have abbreviation list(s), call number, ISSN, URL, comments.
9 Lists can be printed
RW: no	Bscp: yes, use mouse right click on the list and save it as Excel or text file	BK: yes, first save a text file	LM: yes all	Pr: yes all	En: yes all (export as .TXT file)	RM: yes (all the 3 lists)	Papyrus: yes
10 Import external data into the lists
RW: no	Bscp: no the lookup lists, yes the Term table and the Journal list	BK: no	LM: not the indexes, yes the terms lists	Pr: no 4 indexes, yes the others	En: yes	RM: no while importing, non abbreviated words of journal titles are automatically stored in the Periodical term dictionary	Papyrus: yes into the System lists
11 Lists are useful for input
RW: yes	Bscp: yes	BK: yes	LM: yes	Pr: yes	En: yes	RM: yes	Papyrus: yes
12 Lists are useful for searching
RW: yes	Bscp: yes	BK: yes do not start from the Search/Find window, but either select "Utilities" --> Term lists, or: when a full reference is displayed, press the relevant term list button (for the four built-in lists), activate the "disclosure triangle" : the brief view of records connected to that entry is shown; can thereby directly switch to another list	LM: the indexes are pick-up lists for search terms and they speed search up	Pr: yes, while browsing, indexes directly display related records	En: yes, but only to the extent that you can open a list and pick terms up from it to insert in the query	RM: yes (pick-up lists or faster access via Term Manager)	Papyrus: yes; while browsing they do not display records not contextually, but quickly find related records
13 Lists are useful for output
RW: no	Bscp: only Journal list	BK: only Journal Glossaries	LM: yes the tables	Pr: ALTERNAT.TXT to replace «text» strings; matching entries in journal list	En: journal list are also designed to replace field content by an abbreviation	RM: periodical list	Papyrus: abbreviations for the journals list
14 List entries show total number of related documents
RW: yes	Bscp: yes	BK: yes	LM: no	Pr: yes 4 indexes	En: no	RM: no (only when printed out)	Papyrus: yes, kw, journals and names
15 Lists can be shared among different db
RW: n.a.	Bscp: only Term table and Journal list if copied to different folder	BK: no, only Journal Glossaries	LM: not the indexes, yest the Terms lists	Pr: indexes can be accessed -rather than shared- from different databases; other lists can be shared	En: no (but you can Copy and Paste an entire list or part of it)	RM: no, apart from the periodical list that can be copied from one database to another ("Term Manager" --> Copy periodicals	Papyrus: no, but kw, journals (and partially names) entries can be exported and imported into another database
16 How lists are created and updated: 1. input: new entries automatically update the list 2. ad hoc command to edit lists out of records 3. import 4. as a text file out of the program
RW: 1	Bscp: 1 2; 3 and 4 as far as Term and Journal lists are concerned	BK: 1 2 only as far as Journal Glossaries are concerned	LM: 1: indexes; 2 3 4 terms lists	Pr: 1: 4 indexes 2: all other lists 3: yes all apart from indexes; 4: all lists apart from indexes	En: 1 2 3 (4: it must be imported)	RM: 1; 2	Papyrus: 1; 2 System lists; 3 System lists
17 How lists are printed 1. from the outside, as text file 2. from the inside, by ad hoc printing function
RW: n.a.	Bscp: 1 2 as far as Term and Journal lists are concerned	BK: 1	LM: indexes should be printed via an output Format; terms lists via ad hoc printing command button	Pr: 1: ALTERNAT.TXT 2: indexes: Print Subject Bibliography (Subject terms only) other lists: File -> Open, export and save file	En: 2 export as a .TXT file	RM: 2	Papyrus: 2

Term/Entry lists

1 Fixed number

2 Lists' content is automatically derived from db data, and/or can contain external data

3 Lists are physically separated from database

4 Lists reflect records content in real time

5 Lists can be directly edited

6 When list entries are edited, records content change

7 New entries are validated ("go list", e.g.: new, old, probably a duplicate)

8 List entry can contain its own supplementary data: note, abbreviation, date, compiler, x-refs

9 Lists can be printed

10 Import external data into the lists

11 Lists are useful for input

12 Lists are useful for searching

13 Lists are useful for output

14 List entries show total number of related documents

15 Lists can be shared among different db

16 How lists are created and updated: 1. input: new entries automatically update the list 2. ad hoc command to edit lists out of records 3. import 4. as a text file out of the program

17 How lists are printed 1. from the outside, as text file 2. from the inside, by ad hoc printing function

16 How lists are created and updated:
1. input: new entries automatically update the list
2. ad hoc command to edit lists out of records
3. import
4. as a text file out of the program

17 How lists are printed
1. from the outside, as text file
2. from the inside, by ad hoc printing function