Skip to content
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

Validation of 490 indicators in wrong order #23

Open
phochste opened this issue Nov 9, 2017 · 13 comments
Open

Validation of 490 indicators in wrong order #23

phochste opened this issue Nov 9, 2017 · 13 comments
Projects

Comments

@phochste
Copy link

phochste commented Nov 9, 2017

In Ghent we have this MARC fragment:

4900  L $$6880-03$$aSifriyat ha-Entsiá
record-id:000714573
tag: 490
ind1:0
ind2:'empty'
6:6880-03
a:Sifriyat ha-Entsiá

The validator gives as error:

000714573       490$ind1        invalid value           https://www.loc.gov/marc/bibliographic/bd490.html
000714573       490$ind2        non-empty indicator     0       https://www.loc.gov/marc/bibliographic/bd490.html

Shouldn't this display the errors in the opposite order?

@phochste phochste changed the title Validation of 490 indicators Validation of 490 indicators in wrong order Nov 9, 2017
@pkiraly
Copy link
Owner

pkiraly commented Nov 9, 2017

Thanks! I am checking it.

@pkiraly
Copy link
Owner

pkiraly commented Nov 9, 2017

@phochste

The full record is this:

LEADER 01168cam a2200325 a 4500
001 000714573
005 20170426113133.0
008 940524s1993    is       b    001 0 heb d
010   $a94827404
020   $z096534215X
035   $9(DLC) 94827404
035   $a(CStRLIN)DCLH94-B1223
040   $aBE-GnUNI
042   $alccopycat
050 00$aPJ4150$b.S58 1993
066   $c(2
100 1 $aSivan, Daniel.
245 10$aDiḳduḳ leshon Ugarit /$cme-et Daniyel Siṿan.
246 2 $aUgaritic grammar.
260   $6880-02$aYerushalayim :$bMosad Byaliḳ,$c1993.
300   $a213 p. ;$c22 cm.
490 0 $6880-03$aSifriyat ha-Entsiḳlopedyah ha-Miḳraʼit ;$v9
504   $aIncludes bibliographical references (p. [201]-213) and index.
650  7$aUgaritic language$xGrammar.$2lcsh
740 0 $aUgaritic grammar.
880 10$6245-01/(2/r$aדקדוק לשון אוגרין /$cמאת דניאל סיון.
880   $6260-02/(2/r$aירושלים :$bמוסד ביאליק$c1993.
880  0$6490-03/(2/r$aספריית האנציקלופדיה המקראית ;$v9
852 4 $xLW$bLW55$cL88$jLWBIB.L88.NW.GRAM.UGAR.0001$p000010545552
920   $abook

the interesting part is this line:

880  0$6490-03/(2/r$aספריית האנציקלופדיה המקראית ;$v9

880 field is a language variation of the information recorded in the field references in $a subfield, in this case it is 490. The description of 880 (http://www.loc.gov/marc/bibliographic/bd880.html) says at both indicators: "Appropriate indicator as available in associated field". I am not one hundred percent sure, that as I understand it the validation should take these two indicators as it should be the indicators of 490. And if this supposition is correct, then the validator correctly reports that there is a problem at that place, since is should be 0 and ' ', but it is on the reverse, ' ' and 0. Could you check with yourr colleagues, that this interpretation is correct?

What is missing this case is the notation that it is a referenced field (given that the above sentences are true).

@pkiraly
Copy link
Owner

pkiraly commented Nov 9, 2017

I will encode reference field path the following way:

880->490$ind1

Is it acceptable? Is there a standard way of notation?

@phochste
Copy link
Author

@cKlee is working on a standard notation and might help you http://marcspec.github.io/MARCspec/marc-spec.html

We in Ghent have the interpretation that 490 indicators should be in 880. And it would be a mistake that 880 and 490 indicators are different? I'll get more input from a MARC specialist I know.

@pkiraly
Copy link
Owner

pkiraly commented Nov 10, 2017

Thanks for the reference, I'll follow that notification!

Yes, I think that it is a mistake, but that is my interpretation. The wording of the standard is not very clear for me.

@pkiraly
Copy link
Owner

pkiraly commented Nov 10, 2017

BTW: yesterday I commited changes to make it explicit that it is referenced. Right now it uses 880->490$ind1 notation, I'll change it to something like 880$6{490_1} (I'll consult with @cKlee).

@cKlee
Copy link

cKlee commented Nov 10, 2017

Let me know, if I can help.

@pkiraly
Copy link
Owner

pkiraly commented Nov 10, 2017

Dear @cKlee,

the aim of this task is to provide a validation report for MARC records. The tool produces a report line for each found issue, which contains the ID, a MARC path (where the error happened), type of error, extra information, such as the invalid code, and the URL to the MARC standard which describes the problem in details. Now we run into the problem that we found an error in a referenced field 490, which is embedded in 880. The tool so far reported that the problematic field is 490, and it was not clear if it is the non referenced or the referenced 490. So we would like to make it explicit, making a distinction between these two. I provisionaly introduced the notation

880->490$ind1

@phochste called my attention to your MARCspec document which is great, and I decided, that in the future this tool will follow your specification. I am not sure however how do you notate this case.

Thank you in advance,
Péter

@cKlee
Copy link

cKlee commented Nov 10, 2017

I see. The problem lies within the usage of the indicators. With MARCspec you cannot reference indicator content. Thus you cannot state, that a field is only referenced when another field has the same indicators, unless you specify which specific indicators they have.

And with MARCspec you have to be more precise on the field repetition:

880[2]{__0$6=490[0]__0$6}

... is interpreted as: Reference data of the second repetition of field 880, if field 880 has an indicator 2 with value 0 and subfield $6 equals subfield $6 of the first 490 field, having the indicator 2 with value 0.

And this would not reference any data, because the first 490 field has no indicator 2 with value 0. But this is very difficult to read/interpret for humans.

But I'm willing to extend MARCspec with a syntax for references to indicators. This deficit bugged me for quite a while. But I'm not sure what the best way to do that is. I'm open for suggestions ...

@cKlee
Copy link

cKlee commented Nov 10, 2017

MARCspec/MARCspec#24 (comment) is a proposal for an extension of MARCspec towards references to indicator values.

Thus what you are trying to express would look like

880[2]{^1=490[0]^1}

Reference data of the second repetition of field 880, if indicator 1 equals indicator 1 of first 490 field. For better readability you might omit the field position/index, like

880{^1=490^1}

If you want to refer to a subfield, then abbreviation is not possible:

880$6{880^1=490^1}

because one could either refer to indicator value 880^1 or subfield value 880$6. Something like 880^1$6 is not possible.

Is this something you could use?

@pkiraly
Copy link
Owner

pkiraly commented Nov 10, 2017

@cKlee

Thanks a lot for your help! I'll ask MARC cataloguers, if they are OK with this notations.

My first impression is the specification is mainly for comparing values, and what I really need right now is simply addressing an element in a MARC record. Something like xpath. But maybe I am wrong, and I should read your specification more carefully.

@cKlee
Copy link

cKlee commented Nov 10, 2017

Well, it is like XPath for MARC. But like in XPath it is difficult to express dependencies. If you want a more expressive syntax like you suggested 880->490$ind1, you could also mix this with MARCspec, like 880->490^1 or 880^1!=490^1. This is not valid MARCspec, but two MARCspec references in your own syntax.

I don't want to persuade you. I'll extend MARCspec with indicator refs nevertheless.

@pkiraly
Copy link
Owner

pkiraly commented Nov 13, 2017

Dear @cKlee,

Great, we are on the same page, you don't have to persuade me, I just need more knowledge about MARCspec. I'll send you questions regarding to the specification in email.

Thanks again!

@pkiraly pkiraly added this to To do in Release 0.2 Nov 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Release 0.2
  
To do
Development

No branches or pull requests

3 participants