Migration from Winisis to ABCD, some comments

Even 21 years after the release of the latest version of Winisis, this software can still be found in some documentation centres. Because it’s not exactly library software, Winisis was used for many years to manage collections. Its obsolescence was the choice of Unesco, the creator of the technology.

In 2009, Bireme officially launched ABCD as complete software for library services, but also to replace Winisis. This can be seen by accessing the ABCD Centre in the Create database menu. The first option is “From Winisis”.

Despite this possible facility, many users report difficulties with this action and that’s what I’m going to talk about in this post.

---

Compatibility

After creating a replica of a database from WinISIS is when the problems start to appear. They intensify when data is imported into ABCD.

All problems can be solved with a few adjustments. Some problems, in fact, are prerequisites of the ABCD itself, not being exactly a problem, that is, a point to be observed in a mandatory way.

Common problems are:

• MFN corrupted at the source;
• poorly constructed FST reformatting;
• Incompatibility of display formats;
• Absence of CISIS-compatible indexing rules;
• Absence of internal search forms.

As previously stated, this knowledge should be a prerequisite for the conversion and migration of databases from ABCD to Winisis, it is worth making a few comments on each of the topics mentioned above.

---

Corrupted MFN at source

An MFN is a logical record of a CDS/ISIS database, so depending on its structure or status it may not be fully or partially migrated. A great example is records with invalid characters or spaces at the end of lines that can cause an incomplete export. During export, it is essential to check if the number of MFNs exported is equivalent to the number of active MFNs. The so-called invalid characters are the characters that belong to another encoding family and that are usually entered manually, but rather through commands such as Copy and Paste during cataloging.

Active MFNs are records that have not been marked as deleted.

ATTENTION! If the database has 50 MNFs and 5 records are marked as deleted, in the export we will have 45 MNFs.

---

Poorly constructed reformatting FST

In some cases, it is possible to make use of the reformat FST to export the records following a certain configuration. This feature requires attention to avoid data loss. The most common mistake is the omission of a field that has been filled in a few times and that, if not pointed out correctly in the FST, may be exported with the missing information..****

The use of FST reformatting is optional. If left blank, the output records will retain their field labels, and the fields will retain their contents. You can perform a reformat by providing the name of an FST. In this case, the FST is interpreted as follows:

1. each FST line represents an output field
2. each output field is assigned an ISO label equal to the field identifier defined in the corresponding FST line;
3. the data extraction format provided in  the FST defines the contents of the field. In this format, the ISO label of the fields as defined in the database should be used. Each row produced by the format (or each element, if the FST specifies search term selection techniques 2, 3, or 4) will generate a new occurrence of the output field.

For example, for a database that contains the following fields:

1     Author (repetitive)

2     Title

3     Keywords (repetitive)

4    Notes

A  reformatting FST could be as follows:

1 0 MFN
100 0 (v1/)
200 0 v2
300 0 |<|v3|>|

In a brief explanation:

1 0 MFN            [output field 1 contains the MFN]

100 0 (v1/)        [output  field 100 is  equal to input  field l  (a repeating group is used in the format so that each occurrence of field l exits as a separate line)]

200 0 v2           [output  field 200 equals input field 2]

300 0 |<|v3|>| [Output field 300 contains keywords enclosed between < … >, each keyword being taken as an occurrence of field 3 input].

Since neither format references  field 4., this field will not be exported.

---

Incompatible Display Formats (PFT)

Print Format Table: A table used to define the manner in which the contents of records in a CDS/ISIS database will be viewed. PFT files are also used to print the contents of records to a file or to printers.

To format the data in a PFT file, it is necessary to have basic knowledge of the CISIS format language and HTML.

The details about this language will be covered at a specific time, but what needs to be noted is that ABCD, being a WEB software, allows many syntaxes with web languages along with CISIS, while in Winisis only CISIS is allowed. This feature causes some CISIS commands not to work in ABCD, in other words, as ABCD uses Web resources to display its formats, commands such as: colors, headers, font sizes should be replaced by HTML after exporting the data.

Basic differences between CISIS used in WinISIS and ABCD

Command	WinISIS	ABCD
New line	/ or #	<br>
Paragraph	tab(value)	Via CSS:
margin-left: value;
Font Color	cl[value]	Via CSS:
color: value;
Font size		Via CSS:
font-size: value;
ref Command		Most syntaxes don’t work.

TIP! Generate a new display format using the Reports screen from the ABCD Center. You can edit the default format and generate a new compatible one automatically using the Table option.

---

Absence of CISIS-compliant indexing rules (FST).

You can’t run any queries on ABCD without indexing it. Importing the Winisis FST file will even allow indexing, however if some types of rules, such as the absence of prefixes are not defined, probably the search forms will not work correctly.

The Field Selection Tables, or simply FST, defines criteria for extracting one or more elements from a master file record. These elements are used in the generation of the inverted file (index), sorting of records in printing reports, or to reformat records during an import or export operation.

The CISIS Interface supports all 8 Indexing Techniques (IT), from 0 to 4 without the possibility of field identification and from 5 to 8 with field identification through prefixes.

Eight basic parameters are required to define it:

No prefix	Prefixed	Technique Operation
0	0	Entire field – Constructs an element from each line extracted from the format. This technique is usually used to index entire fields or subfields. Note however, that CDS/ISIS will build elements from lines and not from fields. This is due to the fact that CDS/ISIS considers the output of the format to be a string, where fields are no longer identifiable. a character string, where fields are no longer identifiable. It is therefore the user’s responsibility to produce the correct data using the format, especially when indexing repetitive fields and/or more than one field. In other words, when using this technique, make sure that the data extraction format outputs a line for each element to be indexed.
1	5	Subfield – Constructs an element from each subfield or row extracted by the format considering delimiters. As CDS/ISIS looks for subfield delimiter subfield delimiter codes in the format output for the technique to work correctly, the the format must specify the proof mode (or no mode, which is the default) that preserves the subfield delimiter codes in the output. Remember that “header” and “data” modes replace subfield delimiter codes with punctuation marks. Also note that technique 1 is an extension of technique 0.
2	6	Terms marked with <e> – Constructs an element from each term or phrase included between < and > (less than and greater than). No text outside the < and > characters will be indexed. Note that this technique requires proof mode because the other modes delete the < and > characters.
3	7	Terms marked with / e / – Performs the same processing as technique 2, except that the terms are included between slashes (/ … /).
4	8	By word – Builds an element from each word of the text extracted by the format. A word is any sequence of contiguous alphabetic characters.

Indexing techniques 5, 6, 7 and 8 operate similarly to techniques 1, 2, 3 and 4, respectively, differing only in the fact that they add prefixes to the extracted terms. The specification of a prefix is an unconditional literal that uses the general form.

Example:

mpu,('|TW_|'v245^a|%|/)

In Winisis	In ABCD
70 0 mhu,(v70/)	70 0 mhu,(‘AU_’,v70/)
24 4 mhu, v24	24 8 mhu,’/TI_/’,v24
69 2 v69	69 6 ‘/KW_/’,v69

It is important to note that with the 0 (zero) technique it is the only one where prefixing is an option.

---

Absence of internal search forms

When ABCD receives a database from Winisis, it is not able to predict which fields will be available for search or how the data will be available, so it is mandatory to create your search forms right after creating a database.

The simple and advanced search forms are used in two places in ABCD: in the cataloging module – to allow the cataloger to quickly and/or efficiently identify a specific record for editing (duplicate check or copy) – and in the OPAC – as the advanced search form.

Here ABCD simply offers an editor for the table that defines the three-column lookup form:

• The first column is the name of the field or “index” as it will appear in the search form;
• The second column contains the identifier used for a particular field (or a combination of fields) of the FST;
• The third and final column contains the prefix, or initial fixed string, that is used (if any) in the ISIS inverted file for this index.

The ABCD will also present, on the side (on the right) of this table, the existing FST to facilitate the identification of the indexes (search fields) and the identifiers used. Clicking “Update” saves the table, which is actually a file called “busqueda.tab”, stored in the language subfolder of the “pfts” folder inside the database folder.

---

Conclusion

Although ABCD is an heir to the Winisis structure, it must be borne in mind that it is a system entirely geared towards operating in Internet browsers. As it is a large database manager, it is up to the person who maintains it to have the planning and specific knowledge to carry out a quality migration. To do this, we suggest reading the manuals available in the downloads section.