|
|
|
Meta
|
NOTE: this document describes traditional ISIS and early OpenIsis proposals.
For updated information please refer to the simplified
Malete structures
traditional field definition and OpenIsis data definition metadata.
| | the traditional FDT |
According to the CDS/ISIS manual,
the field definition table is displayed like
44 Serie 300 X R vz
and contains for each field tag:
- a field description (up to 30 characters)
- maximum length (1 to 1650)
- field type:
X for alphanum, A for strictly alpha (not including space),
N for numeric (decimal digits), P for pattern (see below).
- repeatability indicator
R meaning field is repeatable, N else
- format (subfield list or pattern)
For a P field, this gives a COBOL-PIC-style pattern
consisting of X (alnum), A (alpha), 9 (num) and literal letters,
e.g. 99-999/AA to allow for input like 35-674/XE.
For other field types, this is a list of legal subfields,
e.g. vz to allow for input like foo^vbar^zbaz.
Patterns are not supported by winisis as of Version 1.4.
The actual file format looks like
Series vz 44 300 0 1
which is 30 characters name, 20 characters subfield/pattern,
the field tag, maximum length, a number encoding the type
(0 alphanum, 1 alpha, 2 numeric, 3 pattern),
and a number 1 for repeatable / 0 for non repeatable fields.
Moreover, the FDT defines the available
worksheets W (.fmt), printformats F (.pft) and field selections S (.fst).
Each such definition is on a line starting with the
key letter and a colon, and followed by (blank padded)
6 character fields of file basenames.
F:THES THES1 THES2
| | principles of OpenIsis metadata |
Definition of data is done in the database's
Options
record, rather than in a separate file.
Data definition is aimed at being quite general,
supporting a wide range of formats according to different application needs.
It includes several features that are also found in IsisMARC's FDT21
by Ernesto Spinak, but uses substructures rather than a separate database.
Data definition does not only define fields, but also subfields,
subrecords, code values (enums) and types in a uniform approach.
Basically, for every data element,
there is one (heavily structured) field describing the element,
which may, however, refer to or be referred to by other fields.
It has the following subfields, separated by TAB:
- i id
numerical tag of the field or type described
- s sub
subfield identifier of the element defined (repeatable).
Not present in a (top level) field definition.
Number base 36 (i.e. 0..9,a=10,b=11..z=35).
If the subid does not start with a number base 36,
the element can be referred to by it's position among the subfield
declarations for the same parent (in base 36, starting from 0).
If there is a number, not followed by any characters,
the subfield is identified by this number.
If subid is empty, or the number is followed by a ')',
the field is unidentified in it's parent.
If any other character like '=', the field is identified by it's name,
delimited by this character (or any single non-id char).
- e end
end of this element (i.e., for a toplevel field, the initial part).
Consists of a leading delimiter char and some optional flags.
If empty, is the standard subfield delimiter (a TAB).
If absent, and the field has fixed length (type 3 or 4), it has
no delimiting character, but just stops after it's length.
Else a subfield inherits it's parents end (defaulting to TAB),
and for a toplevel there are no subfields (you may still define
subfields, but the field value itself will include them).
Traditional ISIS data should use e^.
An initial numerical value (decimal digits) is interpreted as ASCII code
of the delimiter char (TAB is 9).
If end contains a (literal) blank, any blanks after the delimiter
are consumed.
If end contains a quote ("), the delimiter is not recognized within quotes.
If end contains a backslash (\), the backslash character can be used
to escape the delimiter, a quote (if spec) and itself.
- n name
technical name of the element, preferrably in english.
Must be a lowercase identifier (matching regular expression [a-z_][a-z_0-9]*)
unique throughout this data definition.
- b base
basetype. tag or name of element to copy definitions from.
- t type
numerical primary type of data, describing the initial part of the element
(up to the first subfield delimiter, if any). default is 0.
- l length
numerical (max) length. Absent = ~ = any.
Note that 0 does NOT mean any, but empty, i.e. the element is a flag.
For fixed subrecords, this gives the number of childs.
For other types, it is the length in characters (not bytes!).
For types 3 and 4, this is a fixed length.
- f format
format pattern, highly dependent on type.
if empty, indicates fixed length as given by l.
for type 3, if the format is shorter than l,
the last character is repeated to fill length l.
if nonempty, can be used to imply type 3 and a fixed length.
f is repeatable, allowing alternative formats.
for subrecord( header)s, this gives a legal child as
tag_or_name[,[min][,max]],
where min defaults to 0 and max to unlimited.
for most other types, this is the traditional pattern format (see above).
- m min
Minimum # of occurences. Absent = 0. Empty = 1.
- r repeat
Maximum # of occurences. Absent = 1. Empty = ~ = any.
Use r0 for fields that should not directly be included in their parent,
but are referenced as basetypes or childs.
- v value
default value, code for enums
- x xref
crossreference for field (see below) (repeatable)
- d description
descriptive text in the database's lead language.
translations are maintained separatly.
| | types of fields |
| code | C-name | name | description |
| 0 | FTX | any | actually any characters |
| 1 | FTA | alpha | STRICTLY alpha |
| 2 | FTN | numeric | only digits or signs (+-) |
| 3 | FTP | pattern | given by COBOL-style pattern |
| 4 | FTB | boolean | 0 or 1 (was 13) |
| 5 | FTE | enum | one of the codes listed for this field (was 12) |
| 8 | FTI | iso | alphanum using delimiter ASCII 31 (obsolete, was 10) |
| 9 | FTT | table | alphanum using delimiter ASCII 9 (TAB) (obsolete, was 14) |
| 13 | FTO | operator | fixed subrecord |
| 14 | FTR | record | embraced subrecord (structure) |
| 15 | FTS | sequence | counted subrecord (array) |
| 16 | FTV | value | an enum value |
| | field names |
It is common practice to use long field descriptions
like "Corporate Bodies" or "Govt. Publications No.",
which may be nice looking but are not well suited for technical use.
Therefore the OpenIsis metadata contains an extra field name
in it's metadata record.
When sourcing metadata from an FDT file,
OpenIsis will derive field names by lowercasing the descriptions
and replacing all runs of non-alphanums by a single '_',
yielding "govt_publications_no".
| | subrecords |
subrecords
are introduced by one of the types 13 to 15.
All those introducing fields may contain any subfields.
Type 14 records may (after the leading + or -) also contain an
initial any string, whose length may be restricted to the given length.
(Typically used to hold an initial textnode's contents).
| | crossreferences |
Crossreferences can be used for several purposes, including
- specifying referential integrity constraints
- especially authority, coding and terminology relations
- specifying inheritance relations in the
PatchWork
However, all these purposes are more or less the same,
depending just on how you look at it. Any flavour of reference may be used
- on data entry,
to ensure that a reference can be resolved according to a given cardinality
- on data retrieval,
to enrich the data of a refering record by it's refered-to records
Basically, the contents of an element for which a crossref is defined,
may, should or must be either an MFN (row number) of a record or,
after slight modification, a (prefix of a) valid index entry,
in both cases usually in another database (table).
The crossref for a field specifies, separated by semicolon ';',
- database of reference
- cardinality as used in regular expressions
'*' for any, '+' for at least one, '?' at most one, or min,max.
Empty means exactly one.
- prefix for index lookup
Anything after the second ';'
If a value found in the index is delimited by the same delimiter
as the item in question (TAB strongly recommended),
it is considered a match and the whole index entry
considered the field of reference.
Else, the index entry's record is looked up and whatever is the entry's
tag is the field of reference.
Thus, resolving the reference, is largely governed by the index
(and you can do all sort of tricks there), not by the referer.
$Id: Meta.txt,v 1.9 2004/06/10 12:52:29 kripke Exp $
|
|
