<div dir="ltr"><font face="courier new, monospace">Dear Isis community:</font><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">I have tried to follow the part of this thick thread covering 'Problems Importing ISO Files with "repeated subfields" in JIsis'.</font></div>
<div><font face="courier new, monospace">Sorry for this text being long but I hope it will help to summarize, clarify, offer a new point of view of the question.</font></div><div><div><font face="courier new, monospace"><br>
</font></div><div><font face="courier new, monospace">1)</font></div><div><font face="courier new, monospace">As a matter of fact the issue of repeatable subfields within (CDS/ISIS, Winisis JISIS) is and has always been a delusive problem. A fake. And even in this occasion it seems to have been misleading.</font></div>
<div><font face="courier new, monospace">Specifically, IT DOES NOT EXIST, especially when one uses the repeatable field-occurrences separator " % " and in those occurrences he enters subfields with same code (from the mere stance of coded data it is simply what happens with multiple authors).</font></div>
<div><font face="courier new, monospace">Those are only and simply "repeatable fields".</font></div><div><font face="courier new, monospace">[The story of dealing with "so[badly]called repeatable subfields" was probably born in Italy (Tuscany) at th time when IFLA's ISBD and printing were extremely important and people wanted to be compliant a tthe same time with ISBD and MARC and punctuation.</font></div>
<div><font face="courier new, monospace">I am not going on in commenting on that here.</font></div><div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">2)</font></div><div><font face="courier new, monospace">We should not not forget, by the way, that MPL and MDL ISIS's modes smoothly read a field with repeated subfields WITHOUT the " % " field-occurrence separator. It read them as they are stored.</font></div>
<div><font face="courier new, monospace">Similarly Winisis can locate a specific occurrence of the field along with its subfield: v16[2]^b.</font></div><div><font face="courier new, monospace">Furthermore, it let's us play with more fun when we resort to the use also of NOCC and OCC format commands.</font></div>
<div><font face="courier new, monospace">It still holds true that in CDS/ISIS and MHL mode one in CDS/ISIS cannot deal with a specific internal occurrence of a field and its subfields by adressing only it to add, for example, a certain punctuation. Thence the astute (once more Tuscan!) expedient of repeatable fields/occurrence of the same bibliographic (MARC) field to store different parts of one bibliographic area by splitting it into occurrences of the same field, each bearing one occurrence of the same ("repeate) ISBD element: the title, ISBD area 1 with multiple subtitles, the Publication ISBD area 4 with multiple places and/or publishers are the most outstanding examples.</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">3) </font></div><div><font face="courier new, monospace">I) Having analyzed this way the useful remarks by M. Giuzzo Barbaro on the limping import of certain data into JIsis</font></div>
<div><font face="courier new, monospace">II) Having analyzed this way the bogus of the 'repetable subfields' (see above)</font></div><div><font face="courier new, monospace">III) Having performed several tests on different fields, occurrences, subfields, absence of subfields ... between CDS/ISIS and JISIS, and also CDS/ISIS and JIsis by themselves.</font></div>
<div><font face="courier new, monospace">IV) I dare to suggest that there is simply a problem in the way JISIS (at least in import, perhaps somewhere elsetoo ) handles the TAG 001.</font></div><div><font face="courier new, monospace"><span class="" style="white-space:pre">N.B. I have remarked that i</span>f it contains more than one occurrence of the field TAG [00]1 it will cut all of them off but the last, be it carrying subfields or not, and not just the first  (For sure the test could be even more accurate).</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">4)</font></div><div><font face="courier new, monospace">I have reported it to M. Jean-Claude Dauphin who is investigating it, but professionally also points out that:</font></div>
<div><font face="courier new, monospace">"When creating a new database intended to store MARC records, it's quite important to respect  the MARC rules for identifying the different types of Variable Fields:  </font></div>
<div><font face="courier new, monospace">i) Control number field (a special control field identified by tag 001);</font></div><div><font face="courier new, monospace">ii) control fields (identified by tags 002 through 009) </font></div>
<div><font face="courier new, monospace">iii) data fields (identified by tags 010 through 999).</font></div><div><font face="courier new, monospace">If your field 001 should be a data field and not a control field, you should change the tag when exporting (following the Marc rules)."</font></div>
<div><font face="courier new, monospace">[See also the JIsis Reference Manual: "6. J-ISIS Record Structure and MARC Records</font></div><div><font face="courier new, monospace">Important Note: When creating a new database intended to store MARC records, it's quite important to respect the MARC rules for identifying the different types of Variable Fields: i) Control number field (a special control field identified by tag 001); ii) control fields (identified by tags 002 through 009) iii) data fields (identified by tags 010 through 999).</font></div>
<div><font face="courier new, monospace">The control fields contains only data (no indicators and subfield delimiters) while data fields contain indicators and subfields.</font></div><div><font face="courier new, monospace">Following these rules will assure correct data export to ISO2709, MARCXML and other XML formats."]</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">4.1)</font></div><div><font face="courier new, monospace">This is true and it is also true that:</font></div><div><font face="courier new, monospace">(A) CDS/ISIS, Winisis and JIsis have never "got married" or were born with MARC inside, which is an implementation of ISO 2709, which has always been the </font></div>
<div><font face="courier new, monospace">"Isized" (adapted) format for standard import/export non for data entry.</font></div><div><font face="courier new, monospace">By all means CDS/ISIS, Winisis and JIsis have always claimed to have to do only with non numerical/text data and not with "bibliographic data". </font></div>
<div><font face="courier new, monospace">E.g. I could store mail adresses within JIsis, do import/export operations and still having the same problem if I use TAG 1</font></div><div><font face="courier new, monospace">(B) the present JISIS behavior in import is different when dealing with TAG 1 or TAG 2-9 (ISO_MARC reserved) which apparently do not have any problem when importing a field with multiple occurrences (fields bearing the same TAG)</font></div>
<div><font face="courier new, monospace">(C) Over the world there are hundred (thousands) of personal and institutional databases which use TAG 1-9</font></div><div><font face="courier new, monospace">(D) Something can be done to make the JIsis more performant to this regard: notice, warning, help ... of course, but perhaps also something more 'friendly' smooth and efficient at the software level than forcing to make use of a Reformatting FST, as simple as it might be.</font></div>
<div><font face="courier new, monospace"><br></font></div><div><font face="courier new, monospace">I am more than confident that Mr JCD will struggle to do it and improve JIsis performances, and I guess we will feel grateful to him once more.</font></div>
<div><font face="courier new, monospace">Greetings to all<br></font></div><div><font face="courier new, monospace">Francesco Dell'Orso (PERUGIA, IT)  </font></div><div><font face="courier new, monospace"> </font></div>
</div></div>