If I understand it correctly, the Marc21 format allows for arbitrary indicators, addressing the usecases mentioned by @fjorba. This seems a definite improvement compared to Invenio 1.x.
For illustrative purposes I'll just use Marc 100
below, however, Marc has several fields where these issues apply as well.
If I understood the schema correctly, however, each marc field gets mapped to a JSON internal name. So, e.g. a field like 100__
gets mapped to main_entry_personal_name
. Similarly, 1000_
, 1001_
, 1003_
get mapped to main_entry_personal_name
as well, so all author personal names end up in the same JSON field. Again this addresses nicely the usecase of @fjorba as finally all authors regardless of the indicators get indexed and displayed as behind the ingestion only main_entry_personal_name
is used.
In discussions with @martinkoehler we now wondered about dissemnation and probably indexing issues from there.
Say, I ingest Marc21 records that are using 1001_
. In Marc-language this refers to $a
to store Surename, Forename
. So the 1_
gives semantic introducing the concepts of Surename and Forename and define how they should be extracted.
Now I ingest from another Marc source, and I get 1000_
. Here the 0 signifies, that the name in $a
is a forename. The cannonical example at LoC being
100 0_ $aJohn $cthe Baptist, Saint
Sidenote to @martinkoehler: from the examples to 0_
it is clear, that this does not refer to a storage like Henry Adams compared to 1_
Adams, Henry, but that it is indeed meant for name entities that consist of a forename only, like e.g. popes, saints or artists names.
In this discussion we also came to the point that it would be possible in principle to treat 1_
programatically as "split the name at ,
to the concepts of forename and surename and store them in two JSON fields. We were not clear if this is intended. It could address the dissemination issue mentioned below.
Another case is 1003_
:
Where you do not have a concept of forename / surename but the concept of family name. (Note: I'd have to check if RDA would not drop the family in the above, it is clearly expressed in 3_
already can be a left over from ISBD in the AACR. At least I'd prefer to drop it.)
For indexing, one can argue that in the word index for names it might be no issue to treat them all alike. Regardless what you search is, Adams, Henry or Heny Adams the word index will take care of it probably treating the ,
as an unsignificant character. It might come up in the phrase index however, at least if one has a mixed storage (say one 100__$aHenry Adams
).
Some thoughts on this?
The second point and actually the main concerns arrise from reexporting to Marc. If 1001_
is ingested one would suspect to get 1001_
back, right? If I understand it correctly, right now one would get 100__
, right? Given the semantics introduced by the indicators, ignoring This them would loose information effectively.
In the current system this would not happen at least not if one stores the ingestion format as is. And as all processes are working on the ingested format updates to the records would be processed properly and thus keep the format.
Any thoughts on this yet?