Closed kosloot closed 3 years ago
The text class parameter is not sufficient information to be able to extract the proper correction, we really need correction handling for that as discussed in LanguageMachines/foliautils#60. folia2txt doesn't implement a direct interface to this yet, the current way to handle it would be a two-step process, first modifying the document with foliacorrect --corrected
or foliacorrect --original
(which effectively resolves/removes all correction elements), and then doing folia2txt.
But even with correction handling there is an extra challenge in this example because of the nested correction (which I was aware of already but never implemented a solution for). The correction handling allows for retrieving either the deepest original solution (CREEREN/older) or the most current one (creëren/current), it does not accommodate finding an intermediate original currently (creeren/old).
But even with correction handling there is an extra challenge in this example I was fully aware of that :)
I even wonder if this is totally resolvable with 'CorrectionHandling'.
In the libfolia implementation, I use 'CorrectionHandling' as a hint for searching at most.
The primary search condition is the 'class'. And I search in <New>
and <Current>
first, and in Original as a last resort.
This works (in this example at least), but is a bit flaky I think.
CorrectionHandling.ORIGINAL should probably search in <Original>
nodes first, but what if nothing is found?
Search in the other nodes? Or return an empty result?
really tricky
Returning an empty result would never be a good idea, I think.
I would not actually want to run TICCL twice over the same FoLiA, for a new correction round I would restart from the original FoLiA and give it another version number.
But I can well envisage automatically corrected text being further manually (re)corrected and then this problem would probably be at play.
CorrectionHandling.CURRENT
should only search in current/new nodes and CorrectionHandling.ORIGINAL
only in original nodes. There is a CorrectionHandling.EITHER
in case you don't care want something back, but the usefulness of that option is debatable as it's rather undefined behaviour what happens.
Situations in which you get 'nothing' back are meaningful in the sense that they usually imply a deletion.
Ok, I did not think of deletions. You're quite right there.
CorrectionHandling.CURRENT should only search in current/new nodes and CorrectionHandling.ORIGINAL only in original nodes.
But you will end up in trouble in the above example anyway. I don't see an escape yet
A possible solution would be implementing a maximum depth parameter for correction handling, but I don't have any use cases for this so I wouldn't bother implementing this for now.
Well: ucto is able to split words (like separating !., and ?). This can be applied to the outcome of FoLiA-correct. So there you go. A 2-level correction.
Also: doesn't FLAT allow for correcting corrections?
As we originally envisaged it, UCTO would indeed be the next logical step after TICCL-correcting a book, say, in order to move away from 'str' to e.g. 's'.
And as soon as I have TICCLed Nicoline's 17th century newspapers, I indeed want to ask her to set some of her volunteers at work manually correcting the corrections. And for that, I do have FLAT in mind.
Also: doesn't FLAT allow for correcting corrections?
Yep, it does. It can also display the nesting. And it can visualize either the current/new text or the original one.
(Off: @proycon when do you think FLAT will be capable of ingesting FoLiA 2.5?)
The latest development version should be able to handle FoLiA v2.5 already right? But a release is indeed due (there's still some other work stuck in the pipeline awaiting completion though).
I'm closing this one as it was more a question thread which has been settled, and the derived issues LanguageMachines/foliautils#60 and proycon/foliatools#40 are implemented now.
consider this (rather silly) example: corr_1.txt
so this is a corrected correction, where all
<t>
members got a class assigned and the most recent "current" I agree this is odd, but it is valid FoLiA, according to both folialint and foliavalidator.Now lets see what FoLiA-2text and folia2txt make of this:
First with class-current:
GOOD! Now with class=old:
HMM, BAD??
And with class=older:
Also BAD?
What would be the desired outcome? The FoLiA-2text outcome has the least surprisal. But is it correct?