Correction proposals for places in HGV - 1

[enury]

As I am working closely with places for a small project, I'm noticing some possible corrections in the HGV metadata.

I'll open issues as I go along with proposals for corrections. Some seem straightforward, like the first suggestion below, but for others I am not sure what the best course of action is.

1. Harmonize Egypt/Aegypten to Ägypten, Middle Egypt to Mittelägypten
2. Five documents do not have a <provenance> but it can be added from the origPlace which is not "unbekannt" (e.g. TM 79319)
3. Two documents do not have an origPlace. TM 316739 can be corrected from the provenance, but TM 78852 has an empty provenance as well (it seems it should be unbekannt according to a comment).
4. Seventeen documents have a provenance without a placeName (13 of them have two provenances, one of which is empty). Fill or remove the empty provenance?
5. There are 89 provenance without a @type : should the type 'located' be added?
6. Six documents have a placeName inside origPlace, should the placeName elements be moved to provenance?
7. When there are several provenance of a type, e.g. located, it seems the most common encoding is to have a single provenance with several <p> elements inside. But there are also 7 documents with two 'located' provenance, and 1 with two 'sent' provenance. I am not sure if both encoding are valid, or if the first one is preferable.
8. Should the HGV files for 4145 and 5323 be removed? They also exist as 4145a, 5323a etc.

[samosafuz]

I typically leave decisions about HGV to James, but I would respond to these items as follows:

1. Yes (and you've already completed this change)
2. Yes, this should be ok, as the value(s) of <provenance> typically populate <origPlace>. The only potential issue I can foresee is if there is @subtype="nome" or @subtype="region" for any of the <placeName> elements under <provenance> (these are automatically added to <origPlace>, too, by the editor)
3. This sounds correct. Ensure that the value of <origPlace> will be accurate.
4. This is one that perhaps I'd like to look at carefully with you before we make any changes. A case-by-case approach is called for in order to make sure we've the optimal (and consistent!) EpiDoc encoding
5. Yes, @type="located" is generic in HGV, and it should not disturb anything to add it
6. This is another one that I'd like to look at with you; what you suggest sounds correct, but we'll want to take care to produce consistent EpiDoc across HGV
7. These sound like complicated cases that are perhaps best put aside for the moment: you'll need to consult the editions/scholarship carefully, as well as the revision history of the HGV files, to understand why the encoding is the way it is. Only then can we prescribe the appropriate modifications
8. This is a bit tricky. I note that, in DDB, the file for sb.16.12709 has <idno type="HGV">4145</idno> (and not 4145a) and that the file for p.tebt.3.1.714 has <idno type="HGV">5323</idno> (and not 5323a). I assume that the intention is to use the <idno> values that are suffixed by a and b. But we first need to make sure that the various idnos are aligned perfectly in HGV and DDB, that the metadata in 4145.xml and 5323.xml is equivalent to that of 4145a.xml and 5323a.xml, and that the idnos 4145 and 5323 are not elsewhere invoked, before we delete 4145.xml and 5323.xml

Please prepare these items as separate commits, which will make them easier to untangle in the future (if necessary).

[enury]

Thank you for your reply @samosafuz !

I wanted to flag these as I noticed the discrepancies in the XML code, but I don't know when I can look at it, apart for point 5 that is easy enough to implement, and points 2 and 3 as well.

I can certainly provide lists of TM numbers for the more thorny issues, if you would like to look at them too.