4.6. Database and record structure

Database and record structure

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

A -  Database and records organization

EW: completely hidden (transparent) to the user RW: completely hidden (transparent) to the user (SQL tables based) Pr: only vertical: Database -> Record -> Fields (-> Subfields available only in: names, dates, call numbers) En: only vertical: Database -> Record -> Fields (-> Subfields available in personal names only: surname, name, suffix) RM: only vertical: Database -> Record -> Fields (-> Subfields only in personal names: surname, the rest of the name)

B - Horizontal links: between databases, between records, between list entries

EW: no links between databases; groups are pointers to records without physical duplication; can navigate from one record to another set -only- via authors.
If the record comes from ISI Web of Knowledge can navigate towards the source record and related records
RW: not between databases; folders are virtual sets, pointers to records without physical duplication; not x-refs between list entries; you can navigate from one record to another set via the list terms (authors, keywords, journal titles etc.) Pr: no (but "groups", and marked records are pointers to records without physical duplication)

En: no (but "groups" are pointers to records without physical duplication)

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)

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

EW: no RW: no Pr: no

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

En: no

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

RM: no

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

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

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

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

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

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

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

E - Number of RT record types

EW: 44 RW: 31 Pr: 39 En: 44 + 1 Generic + 3 Unused customizable RM: 35 (1 Generic included)

F - Can modify the exisiting record types (apart from changing name) and create extra

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

G - Number of fields per record

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

H - Can create extra fields

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

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

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

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

RM: no

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

J -  Multi-value fields allowed

EW: authors; keywords; URLs RW: several (among which authors, translators, descriptors ...) Pr: Output display recognizes names and kw; automatic indexes recognize only names and kw (not the titles); sort in subject bibliography recognizes any field, provided separators are present
En: yes, names (authors, translators etc.), and kw are recognized as such in: indexing, sorting the first author, output including subject bibliographies; lists can recognize different separators in every single field (<CR> is always accepted) RM: names, kw, fields for URLs and other external resources

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

EW: ther is not visible record number, but there is record identifier carried into a WP document in order to format manuscripts RW: system assigned and reserved; it is a sortable and searchable field and it can be displayed in output 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: system assigned; reserved; record numbers change to avoid duplicates when records are added or copied and then renumbered; the same for output and for sorting the database list; it is searchable; can be displayed in output RM: system assigned and also user controlled: a) numeric, or b) author-date (more records of same author/same year automatically get alphabetic identifiers); renumbered when copied to another database with records bearing same numbers; it is a field that can be used in sorting, searching and display; alphanumeric when author-date
EndNoteWeb (web based) RefWorks (web based) Procite EndNote Reference Manager
Database and record structure  Database and record structure  Database and record structure  Database and record structure  Database and record structure 

Table of contents  | Index