[Isis-users] JISIS - Problems Importing ISO Files, AND so-called "repeatbale subfields"

[Odf Fdo]

Dear Isis community:

I have tried to follow the part of this thick thread covering 'Problems
Importing ISO Files with "repeated subfields" in JIsis'.
Sorry for this text being long but I hope it will help to summarize,
clarify, offer a new point of view of the question.

1)
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.
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).
Those are only and simply "repeatable fields".
[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.
I am not going on in commenting on that here.

2)
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.
Similarly Winisis can locate a specific occurrence of the field along with
its subfield: v16[2]^b.
Furthermore, it let's us play with more fun when we resort to the use also
of NOCC and OCC format commands.
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.

3)
I) Having analyzed this way the useful remarks by M. Giuzzo Barbaro on the
limping import of certain data into JIsis
II) Having analyzed this way the bogus of the 'repetable subfields' (see
above)
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.
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.
N.B. I have remarked that if 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).

4)
I have reported it to M. Jean-Claude Dauphin who is investigating it, but
professionally also points out that:
"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).
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)."
[See also the JIsis Reference Manual: "6. J-ISIS Record Structure and MARC
Records
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).
The control fields contains only data (no indicators and subfield
delimiters) while data fields contain indicators and subfields.
Following these rules will assure correct data export to ISO2709, MARCXML
and other XML formats."]

4.1)
This is true and it is also true that:
(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
"Isized" (adapted) format for standard import/export non for data entry.
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".
E.g. I could store mail adresses within JIsis, do import/export operations
and still having the same problem if I use TAG 1
(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)
(C) Over the world there are hundred (thousands) of personal and
institutional databases which use TAG 1-9
(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.

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.
Greetings to all
Francesco Dell'Orso (PERUGIA, IT)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.iccisis.org/pipermail/isis-users/attachments/20140506/250d8d44/attachment.html>