Term/Entry lists

Bibliography formatting software: An Evaluation template

3. Library Master, ProCite, EndNote, Reference Manager, Papyrus: full evaluation grid

3.14. Term/Entry lists

Term/Entry lists

Library Master Procite EndNote Reference Manager Papyrus

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, while a field can automatically update only one list, unless you do it on the fly while updating a 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; any list can contain entries also not derived from records (import or direct input, edit and deletion: but to change terms in the fields one has to perform global change); automatic duplicate detection and sort; terms can be suggested during input if term already exists in the list (auto-completion); terms which are new to the list are highlighted in red; document total number linked to entries 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, not Menu otpions-)
Remarks: alphabetic scrolling 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)
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

LM: no Pr: yes 4 indexes, not the others En: no : 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, or can contain external 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: derived and can also hosts 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

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 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

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

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 RM: yes as straightforward global edit from Term manager Papyrus: yes, the System lists

6 When list entries are edited, records content 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)

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 highlighted) Papyrus: yes (new kw and journals)

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

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 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

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

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

LM: yes Pr: yes En: yes RM: yes Papyrus: yes

12 Lists are useful for searching

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: to pick-up terms to form a query expression (not in remote, Z39.50 searches) 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

LM: yes the tables Pr: ALTERNAT.TXT to replace ÇtextÈ strings; matching entries in journal list En: journal list 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

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

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

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 must be imported afterwards) 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

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

Library Master	Procite	EndNote	Reference Manager	Papyrus
Term/Entry lists
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, while a field can automatically update only one list, unless you do it on the fly while updating a 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; any list can contain entries also not derived from records (import or direct input, edit and deletion: but to change terms in the fields one has to perform global change); automatic duplicate detection and sort; terms can be suggested during input if term already exists in the list (auto-completion); terms which are new to the list are highlighted in red; document total number linked to entries 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, not Menu otpions-) Remarks: alphabetic scrolling 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) 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
LM: no	Pr: yes 4 indexes, not the others	En: no : 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, or can contain external 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: derived and can also hosts 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
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	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
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
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	RM: yes as straightforward global edit from Term manager	Papyrus: yes, the System lists
6 When list entries are edited, records content 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)
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 highlighted)	Papyrus: yes (new kw and journals)
8 List entry can contain its own supplementary data: note, abbreviation, date, compiler, x-refs
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	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
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
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
LM: yes	Pr: yes	En: yes	RM: yes	Papyrus: yes
12 Lists are useful for searching
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: to pick-up terms to form a query expression (not in remote, Z39.50 searches)	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
LM: yes the tables	Pr: ALTERNAT.TXT to replace ÇtextÈ strings; matching entries in journal list	En: journal list 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
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
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
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 must be imported afterwards)	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
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

Features in general

Features in general

Features in general

Features in general

Features in general

1 Fixed number

2 Lists' content is automatically derived from db data, 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