| 4
Database and record structure |
| 4.1 Files |
| Pr: 2 files: dbn.PDT
dbn.PDX (respectfully: data and indexes) |
En: 1 file: dbn.ENL.
"Preferences" and "Reference types"
in ENDNOTE.ENP |
| RM: 2 files dbn.RMD dbn.RMX
(respectfully: data and indexes) |
|
| 4.2 Internal
database and record structure |
| Pr: only vertical:
Database -> Record -> Fields -> Subfields (where
available: automatic and limited: names, dates,
"call numbers") |
En: only vertical:
Database -> Record -> Fields -> Subfields (names
only) |
| RM: only vertical: Database ->
Record -> Fields -> Subfields in names |
|
| 4.3 Horizontal
links: between databases, records, list entries |
| Pr: no ("group"
is a virtual duplication of -pointer to- records) |
En: no |
| RM: only term synonyms in the 3
indexes: they are equivalent in searching
("reference index" is a virtual duplication of
-pointer to- records) |
|
| 4.4 Hierarchical
links (es. thesaurus, mother/sons records,
text/notecards) |
| Pr: no |
En: 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 |
Term Lists can be
regarded as autonomous (see dedicated section): their
content can be imported from external text, updated from
records, directly edited. Field
data and list contents (sort of look-up) can be
"crossed" in output to replace text: secondary
title (journal) field + journal list (with up to three
abbreviations) |
| RM: no |
|
| some fields
generate indexes which are not only derived, i.e.
automatically created and updated, as they can have
indipendent entries and synonyms and can be directly
edited |
|
| 4.5 Ready,
predefined record structure |
| Pr: yes (workform), can
be shared among different databases |
En: yes (reference type),
they are automatically shared among different databases
(ENDNOTE.ENP: unless -in a network- placed on different
users' drives) |
| RM: yes (reference type), they belong
to each database |
|
4.6 Input
worksheets
1. features
2. can be modified
3. can create others |
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 |
En: 1: 18 reference types
-with varying fields- for book, articles, e-source etc.;
fields bear "step" displayed
name: total number is fixed max 30; fields are identified
by the number they bear in the Generic RT which
determinates their position: number is fixed across al
the workforms; some fields ( names, journal titles,
pages, URL, keywords) have peculiarities (internal
coding, indexing, output formatting, sort...) that cannot
loose or lend to other fields.
2: yes, given abovementioned constraints,
can add, delete, move, rename fields; attributes cannot
be changed
3: yes, only one |
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,
searching and global editing are not |
if a field is deleted
from RT, existing record content is put to corresponding
Generic RT field renamed [very good RT table, with bad
operability];
no numeric fields apart from RN for sorting; if fields
names are changed in RT, styles are affected, searching
and global editing are not
|
RM: 35 predefined forms: Reference
Types -with varying fields- for books, articles. e-mail,
thesis etc.; fields bear a label as "step"
displayed name: total number is fixed max 33 (5 user
defined); fields are identified by a number which does
not imply a fixed position: number is fixed across all
the RT; some fields ( names, periodical titles,
dates, pages, URL, kw) have, to a different extent,
properties (internal coding, indexing, output formatting,
sort, searching...) that cannot lose or transfer to other
fields;
2: yes, given the abovementioned
constraints, can add, delete, move, rename fields; their
attributes cannot be changed
3: no |
|
| 4.7 Fields attributes can be
changed; can be applied to other fields |
| Pr: no |
En: no |
| RM: no |
|
4.8 Multiples
(multi-value) fields
1. present/absent 2. specific input rules |
Pr: 1: names and kw as
for the output; automatic indexes only for names and
keywords; sort for any field provided occurrences are
separated by: / <CR> <Ctrl-CR>
<Shift-Enter> // or ; in author field
2: separators for names and kw and see 1 |
En: names as for the
output (not kw); no headings sort; lists can recognize
one (different) separator in every single field;
<CR> always fine
2: separators see 1 |
| RM: 1 names and kw (33 URL); 2 each
value is separated by a semi-colon (;) |
|
| 4.9 Indexed
fields for searching |
| 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: all fields content is
automatically indexed, out of user's control (apart form
QuickIndexes); each character (right/left truncation),
word, phrase, is indexed, without stopwords, and thus
retrievable |
| RM: All fields are indexed for searching purposes: Authors, Dates, Periodical
titles, kw have special indexes |
|
4.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 |
| Pr: 1 3 (if wanted); 4 5
6 7 8 9 10 (must manually assign) |
En: 1; 2; 5 (only if
copied to another database with records); 6 for output;
only temporarily for the database; 7 |
| RM: 1; 2 if 1; 3; 4 no, must be
unique; 5 (only if copied to another database with
records); 6; 7; 8; 9 (must manually enter); 10 |
|
