FrankensteinVariorum / fv-data

TEI data for the Frankenstein Variorum project
The Unlicense
3 stars 0 forks source link

Signaling an empty reading witness #16

Closed zmbq closed 1 year ago

zmbq commented 5 years ago

The very first app tag on the first chunk has an empty n:

<app xml:id="C01_app1" n="">

How would you like me to visualize that? Treat n as a really small non-zero number (so I use the lowest variant intensity)?

ebeshero commented 5 years ago

@zmbq If I'm right about this, there's one of these at the top of the first 6 chunks, C01 to C06... and it's there b/c the MS is missing and the edit-distance process can't generate a number in those cases. And I think I have a patch just for this that I must have neglected to run when we last did the pipeline...There's no variation among the other witnesses here, so I think (while waiting a moment for me to fix the pipeline), we can treat this as zero.

ebeshero commented 5 years ago

@zmbq Indeed yes. I skipped a step toward the end of my pipeline that repairs these--apologies! The good news is, when I automate the pipeline, we won't miss this step (sigh).

ebeshero commented 5 years ago

But for right now it's just as well it's not automated, because we knew we'd probably need to intervene and debug as we're doing now.

ebeshero commented 5 years ago

@zmbq Problem solved: I'd indeed run my complete pipeline, but my patch for empty witness pointers was not firing in a few locations. Your issues this morning helped me to target and isolate those special cases, so we're properly marking these as empty now--no pointers when a witness has nothing. (This is the case in a few places from C06 onwards in both fMS and f1831, and my patch was overly precise in looking only for the fMS.)

My pipeline still outputs these empty witness locations as <rdgGrp n=''>, without giving a number. The parent <app n=''> will also be empty in those first 6 files because I didn't make an edit-distance calculation on these files: the fMS was simply empty.

In other locations that hold an empty witness, however, I am storing a max edit-distance value in the parent app/@n. That's the case when it's not in the first 6 collation units (with the fMS entirely missing). We can do that because the edit distances are realistic measures now--there is an fMS witness present in this collation chunk, and it is simply silent at this moment, not completely absent.

Later on in C06 - C08, we have moments when one and sometimes two witnesses (that are otherwise available) have no text available at a specific variant location where the others have lots of text. When a witness is empty in that case, there's no place for a user to visit that location in the target edition, so we don't really have a way to make that available as a hotspot. I think we don't need a pointer, then, but just need to signal in the Variorum note on the right of the page that certain witness (fMS and f1831 for example) are empty at this moment.

Since the matter of the witness being missing at this point can be signalled in other ways, I'm not too concerned at no display of an inline hotspot where a witness is empty. We'll just want to make clear that 1831 is empty in the output Variorum note (in the side margin) at these moments.

ebeshero commented 5 years ago

Note: I edited and updated the comment above for clarity. Hope this helps.

ebeshero commented 5 years ago

And I'm leaving this issue open: there's no bug to solve in my pipeline, but this issue may help us with questions of how to display the edition when a witness is missing. @zmbq

ebeshero commented 1 year ago

Solved now with a new symbol we're outputting for a missing witness at this point.