"Witnesses", "Attestation", & related issues

[abausi]

I would like to shate just a few thoughts, as concisely as possible, on issues which, as I understood from the recent Naples meeting and further exchanges, were debated in Bm. I am not pointing out how these thoughts should be technically implemented (there are certainly different ways), but I would like to recall their essential and strategic importance for the quality of the data produced, and to keep what we promised.

1. "Witnesses": I am happy with the comprehensive meaning given to them (embracing MSS either present/encoded or not in Bm: this is absolutely correct, since "witnesses" are witnesses to a text and depending on this, also to editions, translarions etc.); but we definitely also need a way to indicate which of the "Witnesses" were already used in editions, and which ones exactly for each edition: this is essential for understading the state of the art in the field, how it developed, based on which MSS. It would be definitely preferable to mark which MSS were used, and leave simply unmarked all those who were not (yet) used.

2. "Attestation": refers to MSS actually described in Bm; these are also "Witnesses", but, as far as I understand, the list is generated from the presence of the text ID in Bm. A way should be found to synhronize this list with that of "Witnesses", so that, in case, redundance does not end up in confusion. Or the relationship between the two shoudl be explained as carefully as possible, as a transitional state. (Ideally, all "witnesses" should have a full description once.)

3. Since Bm builds both on quantity as well as on quality, it would be reasonable, thinking carefully if what seems necessary is also easily doable, to dedicate some time not only to adding, but also to refining what is there, particularly when the need is dictated by new needs in the work of description. This is not easy to define, in practice, but gradually has to be entered into the agenda of Bm - acrually, I cannot imagine this is already current practice, which should receive due time,

@eu-genia @DenisNosnitsin1970 @thea-m @karljonaskarlsson @CarstenHoffmannMarburg @nafisa-valieva

[eu-genia]

Thank you.

1. We already have the guidelines and the technical means for
   a. listing all witnesses as listWit (where we expect to find mss known to transmit a text; we should try to add the witnesses whenever we work on a text record)
   b. marking all witnesses used in a published edition or translation by linking them from the bibliography items - we can surely add a way to highlight those witnesses that have been pointed to from the bibliography; I will add a wishlist tag to remember to implement this after the new release is produced by @HelenaSabel (this is not complicated but at the moment it is not worth working on additional visualizations as they will have to be readjusted again in the new version; in the meanwhile it would be desirable to have a clear understanding which highlight is desired that would not create additional confusion for users)
   c. providing a separate rendering for a list of witnesses used in a critical edition or translation provided by Bm as text

2. all attestations automatically appear in the dynamic list (in the box, it may partially overlap) - it is clear that ideally all witnesses should be described but probably it will never be achieved, we do what we can. So far however we often did not check that all mss aready appearing in the box are also dubbed as witnesses (moreover the discussion previously had been that we do not have to repeat if the witnesses are already encoded and thus listed as Bm attestations) - if now the working guidelines should be that they may be repeated we should, wherever we notice, add the attestations to listWit

3. the focus so far has been rather on going ahead with catalogues. there are many things that would need to be refined (besides adding witness lists we have on our list such things as add secondary bibliography on manuscripts (Secondary bibliography for mss #2431 shows that this is hardly a task for a student); correct spellings; remove CAe IDs for works that actually do not belong there; disambiguate and structure existing records (e.g. Miracles of Michael and Dersana Mikael #2361); add pointers to "inherited" catalogue records that do exist but are not truly searchable (https://github.com/BetaMasaheft/Documentation/milestone/27); link to wikidata (Referring to wikidata #2065); import and map data to other projects (PEMM import and alignment #2540, Linking malke'at in Bm to https://malkeagubae.com database by Augustine #2640 etc) and many other such things). So far we have addressed all such things, including all matters connected with the work records, on a case by case basis, whenever the cataloguing workflow required a better organization of clavis and other records. If a systematic approach to any of the issues currently on the case-by-case wishlist should be introduced then clearly some of the things that are currently being done cannot be done. (I wonder if BeInf or other such current and/or future cooperations could contribute to the improvement of the clavis quality).

[eu-genia]

at the moment the page says

then there is a list of witnesses listed in listWit; in case the witnesses are used in a Bm-encoded edition the subtitle "Manuscripts used in the edition" appears; attestations appear in the box on the right.

In addition, we will, as suggested above, have some way to highlight (to decide how) the mss from listWit used in editions provided in the editions bibliography.

It seems that this is not sufficient or not clear enough. So it has to be clarified how all these distinctions can be made clearer without clattering the page more than it already is.

The question to answer is also e.g. how to treat the witness list for mss with high number of witnesses. Should we really list, in addition to the attestations dynamically produced from the catalogue, all 5000 or more Psalters in listWit? Would it not be more reasonable in such cases only limit to manuscripts used in known editions? But then again, which is the numeric limit beyond which we do not go?

[nafisa-valieva]

Thank you very much, Alessandro and Eugenia! This discussion is very helpful! I have a question: would not it be better to go the other way around: instead of doubling information on witnesses, restrict ourselves to the practice Bm team used to follow before, namely: use the ListWit for manuscripts used by editors/translators (I would like to have them distinguished, probably ´rend´ is enough). For further witnesses (or attestations) I would prefer to have them ´live´ (one can think about a better visualization, however). If the end goal of the project is to have eventually fully described records, I think the right strategy would be to encode ´Ms content´ for stubs whenever this information is missing. I do not think adding this tiny bit of information is very time-consuming. I rather think the problem here is the process of validation by reviewers: each time I work on the existing records, I am asked to make too many corrections often on the parts I have not meant to work on. I might be wrong, but if we all agree to review only corrections and not to comment on the entire record, I think it would make the task easier and it will bring us closer to completeness than ´doubling information´ in ListWit. It would also solve the problem with high number of witnesses. If, however, you both insist on encoding witnesses that were not used in the editions/translations in ListWit, we need to find a way of crediting scholars who identified further witnesses.

[DenisNosnitsin1970]

I am sorry to intervene, now when I look at how "Witnesses" are treated in the Guidelines https://www.betamasaheft.eu/Guidelines/?q=witnesses&id=work-teiHeader I am getting confused a bit. Two different types of indications should now under "Witnesses": 1) those used in <edition/>, 2) mss which are not properly encoded yet, yet known to contain the work. How can I distinguish them are user, visually, in the work record? "If manuscripts are known to contain the work.... " - is this smth different from 1)? I would say, "Witnesses" should be a category for one type of sources only; at least I do not understand it like this now. And, sure, for me it is easy to include a work ID in the stub (this is what I usually do), to let it apear in "dynamic list".

[DenisNosnitsin1970]

"The following manuscripts are reported in this record as witnesses of the source of the information or the edition here encoded." - Frankly speaking, if I were the user this would not be clear to me (also now, I am not sure as to what I understand is right).

[eu-genia]

#2690

we have
listWit where we are supposed to list witnesses known to contain the work (important also for disambiguation)
we can have listWit rend="edition" to list mss used in the edition provided in the Bm record in text
we can have listWit rend="translation" to list mss used in the translation provided in the Bm record
we have a bibliography on the work that can be linked to the manuscripts treated in the bibliography (whether edition, translation, or secondary). the links are currently visible in bibliography, but we can have a way to highlight those manuscripts in the list, linking them to the bibliography using them.

and then we have a dynamic list of attestations of a work in the Bm mss records.

Again, I repeat what I wrote in the previous issue #2690 - of course in an ideal world all known and descibed manuscripts are encoded and the ref to works are added, and then the dynamic list contains all witnesses and the general listWit is not needed, only the one referring to the edition provided in the ideal XML record that contains the full critical edition of the work with all apparatus etc.

but

we will never ever ever achieve this. never. not in 2040, not in 2100.

even the 1000 catalogued EthioSPaRe manuscripts do not contain pointers to works. not to say about the 6000+ EMML manuscripts. it is an extremely time consuming task. even for EMML manuscripts catalogued on vHMML. manuscripts containing more than 1 work take sometimes days or weeks to describe, as texts must be properly identified first.

we have all to understand that we will never ever have a dynamic list showing all known attestations of a work.

if we want to have manuscripts listed we must do it in listWit. there is no other solution. note also that limiting the listWit static list of witnesses only to manuscripts used in edition(s) would fully exclude all works that so far have not been edited but are attested in mss, many of which not duly encoded (like e.g. most of the martyrdoms of Gadla sama'tat, that have been accompanied by a list of witnesses in most cases, and most of the other IDs in the Clavis).

if someone has a suggestion how to sensibly prioritize the works that must be enriched by a listWit by all means and which can wait this could be a sensible discussion, as clearly also producing a complete (how complete?) list of witnesses for all CAe records is not realistic.

If there is a suggestion how this distinction can be better visualized and explained to the users without overfilling the already chaotic page then prepare a clear mock up of the website and I will implement it (after the new release), or Helena will while working on the TEI Publisher release.

Thank you for your concrete suggestions that can be realistically implemented and followed.

[DenisNosnitsin1970]

Please confirm if I understand you right, I quote, "we can have listWit rend="edition" to list mss used in the edition provided in the Bm record", under "edition" you mean the text, which appear if you press the button "Text" in the record, and eventually a translation of this text? (so the witnesses under listWit refer to this text, and not to any other "edition").

[eu-genia]

Yes this is correct. The attribute rend="edition" applies only to the locally provided edition. Without the attribute - everything else.

[DenisNosnitsin1970]

Sorry, I have to ask, "Without the attribute - everything else." - does this mean that there will be smth listed in "witnesses" which does not relate to the "text provided in the record"? (sorry, I strongly feel that the term "the edition" with reference to the text provided in the record may be misleading for some people, it may be a different matter, though).

[eu-genia]

The Guidelines say

We always use <witness>↗ for those manuscripts which are used for the edition we are going to (or could potentially) provide in the <div type='edition'>↗. All manuscript records containing the work if they have been fully encoded with the correct reference are displayed in the app anyway. If manuscripts are known to contain the work but have not been properly encoded yet it is recommended to list them as <witness>↗ (and make sure a corresponding stub or an external reference for the manuscript exist).

What is it that is not clear?

Since we cannot reasonably encode all manuscripts but we want to know for works whenever possible where they are attested we can provide a list of witnesses in sourceDesc.

In cases where work record contains an edition in div type edition, which is, as we all know, in the text of the xml, we must have a list of witnesses for the apparatus. This list has nothing to do with the general one and is marked by rend edition so that it is clearly set apart. Such list will be visualised with a subtitle "manuscripts used in the edition ".

[eu-genia]

Another (practical) consideration to add - when calling the dynamic search list it is easy to show as much locally stored data as possible, as in this snippet (narrative units in this case, but it is the same principle for clavis)

so you can see abstract when provided and witnesses when encoded in listWit. i find it helpful.
While it is surely possible to add in search results also data extracted from elsewhere, this will make the list generation much slower than it currently is.

In the Clavis dynamic list we see something called "List of computed witnesses" which is actually confusing, as the "list" does not show the computed attestations at all but once again the manuscripts listed in listWit, just with the locally provided names

I would remove it.

(This anyway must be postponed as the search will surely be revised in the new release)