-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
MARC 100 vs 700 author / contributor inconsistency #7723
Comments
I've been keeping an eye out for these and I'm pretty sure it's currently being done wrong / sub-optimally. I'm not sure if different catalogers use different rules, but there definitely seem to be a number of instances where only the first author goes in the 100 and all the rest go in the 700. Of course, 7xx fields with a relator of "illustrator", etc should stay in the contributions and not get promoted to authors. Here are some examples that I've come across:
|
The 1xx is the "Main entry" and what it is, and whether or not it exists, is determined by the cataloging rules which were used (e.g. AACR) which vary by time and geography. There's also the possibility that the cataloger didn't follow the rules that they were supposed to. Because there can only be a single 1xx, equal co-authors are always going to end up in 7xx fields. Since OpenLibrary wants to list all authors, not just whoever is identified in the main entry, I think it makes sense to include all 7xx's EXCEPT those which can be clearly identified as non-author/editor contributors like illustrators, translators, etc. I don't think it'll ever be possible to do it perfectly by reverse engineering human provided data with unknown cataloging rules, but I think it's possible to improve on the current situation. Just taking a look at this again and I don't think the examples match the description. The Arabic/French example doesn't match the 100+700 description since it only has (three) 700s and a 710. The binary MARC record from the test suite for the first example above is: There are two online examples which are easier to visualize: The binary for the second example is: In addition to the $0's for authors which we already discuss in #7724 these show the possibility of adding dates (one of the authors has a new death date) and alternate script names to existing author records. I'm not sure if attempting to improve/upgrade existing author records is something that should be done, but it's worth considering. |
Compare:
Why are the other 700 field contributors not being imported as authors in the same way as the 700s from the Nihon no chasho example?
It looks like in the 100 + 700s case, only the 100 individual is made an author, the 700s are contributors.
In the only 700s case, each 700 is added as an equal author.
Is this desired behavior?
It looks like treating
700
s as contributors unless there is no main1xx
entries is deliberate behavior. I can't find anything that confirms either way that this is a correct or incorrect assumption.700
s seem flexible, and although there is provision for (multiple?) subfields to state the exact relationship of the name to the record -- https://www.loc.gov/marc/bibliographic/bd700.html these don't have to exist, and in practice often don't.It seems like it works out, but there is a risk some contributors (illustrators / translators) might get added as authors, and conversely some equally responsible authors may get added as mere contributors.
It looks like there isn't a clear way to indicate all the possibilities in MARC, or at least actual cataloging practice varies considerably.
I won't change the
1xx
/7xx
behavior in this PR. If a field is picked as anauthor
rather than in thecontributions
list, and an880
alternate script version exists, it will now be added to theauthor
dict as analternate_name
, regardless of1xx
or7xx
.contributions
on editions are just plain text lists of single names and don't have room for extra annotations. Work authors of https://openlibrary.org/type/author_role look like they would handle this better, but therole
field is not currently used by any of the imports (AFAIK).Originally posted by @hornc in #7652 (comment)
The text was updated successfully, but these errors were encountered: