Harris Matrix: thoughts from reading Harris about HM implementation in recording, Kiosk, and editable

[lbestock]

Notes on Harris are in the Googledrive. But I did have some thoughts about implementation after reading him, and those more properly belong in a ticket.

To this point we (a term I use loosely - Lutz who fights math really) have been focused on how to produce a HM from the relations. But once we have that, and we seem close, other issues arise. The two areas that struck me, and which are quite separate as Harris and those who have used him seem very clear about, too:

1) How to view the algorithmic output HM in the Director's View and in the recording app in a way that best supports process during excavation; 2) How to manipulate an output for a final Harris Matrix, which is a different beast than an in-process HM.

For 1, In the Director's View it would be great if this is more or less built always, reflecting the current state of things. If it were able to highlight in the matrix those loci that are also in the locus list, I would really be able to use it to ask questions of my excavators. In the field in the recording app this seems extremely helpful to me, too. It also sounds like a ton of work to have an HM generated with the ability to highlight the locus. My dream is a HM generated in the recording app at unit level that is just unhighlit, and then if you ask for the HM from within a locus it turns that locus yellow or some such.

Views aside, it seems clear we are close to a usable HM meeting the in the field needs. Can we meet the final interpretive HM needs? And can we rely on users to distinguish the two?

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?

I do worry a lot about the users. But a relief on this front is that a process and a final HM are even visually distinguishable. I just suspect that either people will spit out process ones and call them final without adding phases on at all or manipulating outputs, or will take that and use different software that doesn't know the relations behind it to produce something that is visually a final HM but runs the risk of violating algorithms because it has been divorced from the data. As one must suspect happens to users of paper HMs (or digitally equivalent programs) not infrequently with complex sites.

[urapadmin]

1. How to view the algorithmic output HM in the Director's View
   • see #2532 and in the recording app in a way that best supports process during excavation;
   • see #2531

[urapadmin]

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?

• But all this belongs to the phasing ticket: #2533

[urapadmin]

I think we can close this, right, @lbestock ?

[urapadmin]

I just close this now