HM: Phasing

[urapadmin]

Coming out of #2403:

For 2, the final HM will have the addition of both horizontal lines separating phases, and the ability to move loci up and down to be in the right phase if they are not put there by the algorithm, what Harris calls permutation of a multilinear stratigraphic sequence. This one is complicated because there isn't always room in the originally generated layout without moving things around. Presumably we have to bring the output into some other software that allows manipulation? We thought for a bit about creating contemporary relations in the recording app that don't have a physical part to make things align once they have been interpreted as contemporary. But it's not quite that simple, because things might be of the same phase but not contemporary. Harris uses an example of a building where you can see what order the beams were put down in the foundation, so they are not contemporary with one another narrowly, but they do all belong to the same phase. So if you had a beam that had no direct physical relation to any others in that phase and was floating stratigraphically but which you knew archaeologically to be of the same phase, you would want in your final HM to move it to that phase but you couldn't do it by saying it was chronologically contemporary with any of the other beams. I can imagine doing this in the way we were playing with grouping things in #2399, and the FA small walls are a good case study for us on this one. But I suspect that any output that works only on algorithms for the end product without enabling an archaeologist to physically slide things around is going to be much less useful and in fact probably not used. We don't want this just visual, however, because then someone could violate the algorithms, which of course is also not the point - the point is which of the algorithmically possible outputs best matches the interpretation of the archaeology? We ideally want to be able to slide things up and down, have other loci move over to make room if needed, and have it refuse our placement if it is algorithmically impossible.

What does the HM compiler do there? Is it spits it out and you're done, or can it be manipulated? As in, is it satisfying only the in-process HM need, or is it attempting to be the basis of a final HM?

The HM Compiler does what we will do, too, it asks you to assign a node to a phase. One way of doing that visually is to click on several nodes and group them to a phase. That is not moving stuff up and down. But I think that is also not really so important. If we list all the loci and groups (phases) and give users an easy way to just assign a locus to a phase I think that should be fine. It is necessary to think about implications here. What do we want to happen happen to those nodes that are not in that phase but would belong to that phase by means of the temporal relations?

Originally posted by @urapadmin in https://github.com/arch-kiosk/arch-kiosk-office/issues/2403#issuecomment-1927482480

[urapadmin]

• this is also closely tied to #2528 and the idea of an interpretational model or argument. In the end phasing is interpretation. So it should belong there.