Migrate data in 031$s and delete field

[jenniferward]

031$s is called Validity and is from the Swiss instance of Muscat. Codes were used to indicate degree of editorial intervention in the music incipit. From the Swiss guidelines: ? There is a mistake in the incipit that has not been corrected. + There is a mistake in the incipit that has been corrected. t The incipit has been transcribed (e.g. from mensural notation)

The field is only used about 2,000 times, mostly in Swiss records, but it has also been used accidently by people who click on the wrong field. It would be better to remove 031$s, and indeed the current guidelines say Do not enter anything into this field!

We had similar guidelines in Kallisto but we put this information in $q (General note). From the Kallisto guidelines: ? = Error in the incipit could not be corrected. + = Error in the incipit has been corrected. t = The incipit has been transcribed into modern notation.

Since the symbols ?, +, and t are not readily understandable to outsiders, they should be replaced and moved to $q.

So we have to migrate the data from 031$s to 031$q, replace the codes, and delete $s.

We also have codes in $q but those are addressed in a separate issue.

Open questions:

1. Should we use the same English phrases throughout, or use German for the German records?
2. Are the sentences from the Kallisto guidelines ok? Or maybe for t be more specific: The incipit has been transcribed into Common Western Music Notation.

[jenniferward]

Examples: t https://muscat.rism.info/admin/sources/400253137 ? https://muscat.rism.info/admin/sources/400253744 + https://muscat.rism.info/admin/sources/401000838

[lpugin]

I am not fully convinced we want to drop these. What about making the field controlled with a drop-down list? That would prevent people from entering something else.

[cgueggi]

Actually this came even from the old Pikado rules. It seems as if the Swiss Arbeitsstelle was the only one who used it... I think this is useful information there and thus I agree with Laurent's idea to create a drop-down list.

[ahankinson]

t seems useful, but not sure about the others, since they don't actually say what the error is, nor how it was corrected or not.

If we're not accepting new entries in this field (and it seems from the guidelines that we're not) then at the very least this should be made read-only.

But it would also be possible to expand that to an entry in a notes field, and that would be more useful to users than a cryptic code.

[xhero]

+1 to make the field read only if we don't want new data there.

[BaMikusi]

'Read only' might make sense as a temporary solution but IMO the field should be deleted eventually. As @ahankinson hints, the + is of no help whatsoever, since it doesn't tell the user what the original error (corrected by the cataloger) was, and the ? is not much better, since it leaves the user guess which error it may refer to, whereby an incipit might easily include more than one questionable passage. So, if these hints are to make any sense, they should be complemented by a more concrete free-text remark -- and then we might as well have only that remark stand in $q and drop $s altogether. Indeed, since most catalogers never heard of this $s option and the specific set of abbreviations it is associated with, such commentary has typically been placed by them in $q anyway, so relocating the coded hints also there would make the picture more uniform overall.

Which is to say that I am for Jennifer's original idea to replace these codes in $s with textual hints in $q. For the first two abbreviations, the verbalizations from the Swiss guidelines seem fine; for the third one the variant with 'Common Western Music Notation' is perhaps more appropriate (less objectionable even for pedants).