Working with Named Places: How and Why to Build a Gazetteer

[yann-ryan]

The Programming Historian has received the following tutorial on 'Working with Named Places: How and Why to Build a Gazetteer' by @grunewas and @rmostern. This lesson is now under review and the lesson preview will be posted shortly.

Please feel free to use the line numbers provided on the preview if that helps with anchoring your comments, although you can structure your review as you see fit.

I will act as editor for the review process. My role is to solicit two reviews from the community and to manage the discussions, which should be held here on this forum.

Members of the wider community are also invited to offer constructive feedback which should post to this message thread, but they are asked to first read our Reviewer Guidelines (http://programminghistorian.org/reviewer-guidelines) and to adhere to our anti-harassment policy (below). We ask that all reviews stop after the second formal review has been submitted so that the author can focus on any revisions. I will make an announcement on this thread when that has occurred.

I will endeavor to keep the conversation open here on Github. If anyone feels the need to discuss anything privately, you are welcome to email me.

Our dedicated Ombudsperson is (Ian Milligan - http://programminghistorian.org/en/project-team). Please feel free to contact him at any time if you have concerns that you would like addressed by an impartial observer. Contacting the ombudsperson will have no impact on the outcome of any peer review.

Anti-Harassment Policy

This is a statement of the Programming Historian's principles and sets expectations for the tone and style of all correspondence between reviewers, authors, editors, and contributors to our public forums.

The Programming Historian is dedicated to providing an open scholarly environment that offers community participants the freedom to thoroughly scrutinize ideas, to ask questions, make suggestions, or to requests for clarification, but also provides a harassment-free space for all contributors to the project, regardless of gender, gender identity and expression, sexual orientation, disability, physical appearance, body size, race, age or religion, or technical experience. We do not tolerate harassment or ad hominem attacks of community participants in any form. Participants violating these rules may be expelled from the community at the discretion of the editorial board. Thank you for helping us to create a safe space.

[anisa-hawes]

Dear @yann-ryan, @grunewas and @rmostern,

Lesson materials for this submission have now been processed and uploaded. Files can be found in the following locations:

• .md file: /drafts/originals/space-place-gazetteers.md
• images: /images/space-place-gazetteers
• assets: /assets/space-place-gazetteers

An initial Preview of this submission is available: http://programminghistorian.github.io/ph-submissions/en/drafts/originals/space-place-gazetteers

[yann-ryan]

Dear @grunewas and @rmostern,

Thank you for this clear and informative lesson. I think it will make a great introductory lesson to gazetteers. Your discussion of the intricacies of space and place work really well. It's also nice to see a lesson suitable for beginners and not requiring any coding experience, and I think it's worth editing the lesson with this in mind as a selling point!

Below is my initial review and suggestions for edits. I have anchored each point to paragraphs from the preview. When responding, I would be grateful if you could copy the text and checkboxes into a comment on this issue, and tick/make a note on your responses to each. Generally, this initial edit is requested within 30 days. If this is not possible, please respond here or contact me via email.

My main suggestion to improve the readability of the lesson is to adjust the structure and headers to make them more logical and informative. I suggest the below as a structure for the lesson. In most cases, the paragraphs can remain in the same order - I've given the suggested division of the paragraphs in parentheses after each header. I've also provided what I think are the topics for each section, but I suggest coming up with your own header names.

1. Lesson Overview (1-2) 1.1 Learning outcomes (3-4) 1.2 Prerequisites?

2. Background (5) 2.1 What is a place? (6-9) 2.2 Gazetteer or GIS? (10-13) 2.3 Considerations (14-15) 2.3 Linked Places GeoJSON and LP-TSV (16 but rewritten)

3. Building a gazetteer from historical text (17-18) 3.1 Create spreadsheet format/data model (19-30) 3.2 Data dictionary (33) 3.3 Fill information (34-37) 3.4 Mapping with modern software (39-50)

4 Enhancing with LOD or GIS mapping (as-is)

5 Conclusion (as-is)

Most of these simply involve inserting header names within the existing paragraph structure.

The second general comment relates to the use of figures in the lesson. Screenshots of spreadsheet pages are not very good from an accessibility point of view, and I recommend replacing the information with markdown tables.

Similarly, where possible, I recommend alternatives to the screenshots in figures 6 to 8. Figure 6 could be replaced with a simple hyperlink to https://whgazetteer.org/search. I understand that this won't work for the other screenshots, but please replace the hand-drawn arrow in Figure 7 with a clearer one - this could be easily done by importing the screenshot into powerpoint or google slides, and using the Shapes tool.

Alternatively, consider rewriting so that these instructions reflect the process rather than the specifics of the web interface.

More specific comments:

• [ ] Paragraph 2: add a sub-heading 'learning outcomes' (see suggested header structure above)

• [ ] Paragraph 2-3: add a short section on prerequisites, even if these are minimal (important for the reader to know from the beginning). You could explain that no coding necessary, no software except spreadsheet software, etc.

• [ ] Paragraph 4 and throughout: refer to the reader in the second person (you) as per author guidelines, rather than 'the learner will', etc.

• [ ] Paragraphs 6 - 16 are a very long introduction without any actions from the reader, from a Programming Historian background. Perhaps read through and see if any of this material could be cut or shortened. Additional headers (see above) may also help.

• [ ] Paragraph 14: the reference to New York may not be so obvious to an international audience. Suggest clarifying this with something like (modern-day New York) following the words Hudson River.

• [ ] Paragraph 16: Add a new short section clearly explaining the LP-TSV format, incorporating the existing material here (see above)

• [ ] Paragraph 20: considering replacing screenshot with just a link, or copy a sample of the text into a coding block.

• [ ] Paragraphs 21-29. These instructions read as if the reader is meant to fill in information as well as the field names, but the following section suggests these should be done separately (as does the first screenshot of the columns empty except for the headers). I suggest removing the instructions on the specific data entry and incorporating them from paragraph 34 onwards.

• [ ] Paragraph 32: including this as an alert box would keep the flow of the lesson.

• [ ] Paragraph 33: Use a separate 'data dictionary' header.

• [ ] Paragraph 35: replace screenshot with markdown table

• [ ] Paragraph 34: Start a new section here to distinguish populating the spreadsheet with data from building the spreadsheet field names (see above).

• [ ] Paragraph 36: remove the period after before To on the final line of the paragraph.

• [ ] Paragraph 38: replace screenshot with markdown table

• [ ] Paragraph 40: explain ISO code and where they can be found.

• [ ] Paragraph 41: replace screenshot with markdown table.

• [ ] Paragraph 43: replace screenshot with url to https://whgazetteer.org/search/

• [ ] Paragraph 44: specify that the reader should search for Tudela in the search box.

• [ ] Paragraph 45: replace the hand-drawn arrow with a shape/clipart

• [ ] Paragraph 52: I was slightly confused until I remembered that Tudela is both the author and the place! Might be worth specifying his full name here.

• [ ] Paragraph 53: In contrast to the rest of the lesson, there is a lot of dense information and jargon in this paragraph. I suggest rewriting, explaining each term and method in a little more detail.

[yann-ryan]

Just a note to say that the authors have been in touch, and aim to make these revisions by the end of September.

[grunewas]

@yann-ryan @anisa-hawes I've started to make a few changes. Can you let me know if I'm doing the process correctly before I make more? The GitHub interface has changed since the last time that I've done this.

[anisa-hawes]

Thank you, @grunewas. Apologies – I'm just seeing this. Please go ahead and make direct edits to your lesson markdown file which is here. Authors don't need to generate Pull Requests in our ph-submissions repository. Let me know if you have any questions, or run into problems as you go. I'd be happy to help.

[anisa-hawes]

Hello Susan @grunewas. Are you comfortable making direct edits to your Markdown file /en/drafts/originals/space-place-gazetteers.md?

Please let me know if you need any advice, or if you'd prefer to email Yann or I your edits so we can apply them on your behalf. Thank you, Anisa

[yann-ryan]

Hi @anisa-hawes, I have agreed to do the edits and the authors have sent me the new version of the markdown file. Apologies, I should have updated it here! I hope to do the edits this evening (I might contact you on Slack later to check the best way to do this).

[anisa-hawes]

Thank you, @yann-ryan! Of course, send me a note. I'd be happy to help ☺️

[anisa-hawes]

Thank you for co-ordinating this, @yann-ryan.

Hello @grunewas, Thank you for your edits!

A revised preview of this lesson is available here: http://programminghistorian.github.io/ph-submissions/en/drafts/originals/space-place-gazetteers.

With best wishes, Anisa

[yann-ryan]

The first reviewer for this lesson will be @VincentDucatteeuw, who aims to complete the review by mid-November. Thanks so much Vincent!

[rmostern]

Thanks from me as well!

Ruth

From: Yann Ryan @.> Sent: Monday, October 16, 2023 12:08 PM To: programminghistorian/ph-submissions @.> Cc: Mostern, Ruth @.>; Mention @.> Subject: Re: [programminghistorian/ph-submissions] Working with Named Places: How and Why to Build a Gazetteer (Issue #580)

The first reviewer for this lesson will be @VincentDucatteeuwhttps://github.com/VincentDucatteeuw, who aims to complete the review by mid-November. Thanks so much Vincent!

- Reply to this email directly, view it on GitHubhttps://github.com/programminghistorian/ph-submissions/issues/580#issuecomment-1764815849, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHLCEQMWVVVRITYLFBCIMYDX7VLXPAVCNFSM6AAAAAA2VKVIVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRUHAYTKOBUHE. You are receiving this because you were mentioned.Message ID: @.**@.>>

[VincentDucatteeuw]

Dear @grunewas and @rmostern

Thank you both for creating this excellent, beginner-friendly lesson on digital gazetteers. Below is my review and suggested edits. I have linked each suggestion to paragraphs from the preview. In general, my suggestions are largely concerned with improving the readability of the lesson for readers unfamiliar with the subject by clarifying certain concepts or design choices.

• [ ] Paragraph 2: perhaps a distinction between historical gazetteers and digital gazetteers is needed to make it clear to the reader that while there are historical documents that are considered gazetteers, this lesson focuses on the development of their digital equivalent.

• [ ] Paragraph 5: excellent beginner-friendly prerequisites. If this were not already the case, I would suggest that this lesson be rated as ‘low’ difficulty.

• [ ] Paragraphs 7-10: relevant introduction to the topic of place for readers unfamiliar with the concept. Prominent authors are mentioned, which is great. I understand that it is not possible to refer to every author who has discussed the concept, but if possible I would suggest referencing the work of Yi-Fu Tuan (Space and Place, 1977). Of course, his ideas have since been refined by the authors already mentioned, but I find the work quite accessible for beginners.

• [ ] Paragraphs 11-13: both gazetteers and GIS are based on spatial data, structured in particular formats. The distinction that gazetteers are dataset based, while GIS are map based may be confusing to the unfamiliar reader. To make the distinction clearer, I would suggest adding that the focus of GIS is primarily on the projection geospatial geometries in the form of points, lines and polygons - and while gazetteer may contain geographical information, its primary focus is on structuring the humanistic complexities of place. Some authors argue that digital gazetteers are in fact GIS. For example, Hastings (2008) states that a “free-standing DG [digital gazetteer] is the quintessential geographic information system (GIS), in fact”. But to discuss the relationship between GIS and (digital) gazetteers in such detail may be too far from the focus of this lesson.

• [ ] Paragraph 16: “There is no objective way to decide whether to group these names together as references to a single place.” While it is true that there is no objective way, there may be value in reaching a shared consensus on disambiguation principles for the interoperability and reusability of gazetteers. Within the historical discipline, some work has been done in this regard (Garbacz et al., Identity of historical localities in information systems, 2021; Jenstad, Urban gazetteer design: principles for disambiguating places and toponyms, 2020). It would be helpful for the reader to indicate which properties of a place are used in this lesson to disambiguate places. (e.g. describe why Montpellier is considered an alternative name to Har Gaash).

• [ ] Paragraph 18: I would suggest moving the paragraph about the Linked Places format and adding it to paragraph 23. Introducing the paragraph on building a gazetteer from a historical source before discussing gazetteer data models would create a more coherent flow.

• [ ] Paragraph 29: typos, ‘correspodning’, ‘pargraph’.

• [ ] Paragraph 33: typo ‘the the’.

I have no additional comments for paragraphs 34-59. In general, I whole-heartedly support this lesson as it provides a valuable introduction to digital gazetteers in historical research.

[rmostern]

Thank you for these helpful comments. Can you please provide a complete citation for Hastings (2008)?

[rmostern]

...and also the full citation to the 2020 Janelle Jenstad article? Many thanks.

[grunewas]

Hi Yann,

Will we also have another reviewer? If so, do you know when we might receive comments so that we can think about when to make time in our schedules for revisions?

Best, Susan

On Mon, Oct 16, 2023, 11:08 AM Yann Ryan @.***> wrote:

The first reviewer for this lesson will be @VincentDucatteeuw https://github.com/VincentDucatteeuw, who aims to complete the review by mid-November. Thanks so much Vincent!

— Reply to this email directly, view it on GitHub https://github.com/programminghistorian/ph-submissions/issues/580#issuecomment-1764815849, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJTTIOHJ2ZWPD3QGBSWHCTX7VLXPAVCNFSM6AAAAAA2VKVIVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTONRUHAYTKOBUHE . You are receiving this because you were mentioned.Message ID: @.***>

[yann-ryan]

Thanks so much for your thoughtful review, @VincentDucatteeuw!

@grunewas and @rmostern, there will be a second reviewer, so please don't make any edits until both reviews have been received. At that point, I'll summarise both and we'll put together a concrete set of steps to continue. Unfortunately I don't have an exact time for when you'll get the second review, but I am hopeful it will be within a month at the very most.

[grunewas]

Hi Yann,

Perfect. Thank you very much.

Best, Susan

On Mon, Nov 13, 2023, 4:16 PM Yann Ryan @.***> wrote:

Thanks so much for your thoughtful review, @VincentDucatteeuw https://github.com/VincentDucatteeuw!

@grunewas https://github.com/grunewas and @rmostern https://github.com/rmostern, there will be a second reviewer, so please don't make any edits until both reviews have been received. At that point, I'll summarise both and we'll put together a concrete set of steps to continue. Unfortunately I don't have an exact time for when you'll get the second review, but I am hopeful it will be within a month at the very most.

— Reply to this email directly, view it on GitHub https://github.com/programminghistorian/ph-submissions/issues/580#issuecomment-1809222768, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJTTIJPL6HT4VSUWNXZFMDYEKL2ZAVCNFSM6AAAAAA2VKVIVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBZGIZDENZWHA . You are receiving this because you were mentioned.Message ID: @.***>

[VincentDucatteeuw]

J. T. Hastings (2008) Automated conflation of digital gazetteer data, International Journal of Geographical Information Science, 22:10, 1109-1127, DOI: 10.1080/13658810701851453

I refer to an talk given by Dr. Janelle Jenstad for the Pelagios Network Gazetteer Activity group. A recording of it can be found here: https://medium.com/pelagios/janelle-jenstad-on-urban-gazetteer-design-698852e55bea. Unfortunately, no article has been published about it yet.

For a general overview of Early Modern London gazetteer Janelle Jenstad. “Building a Gazetteer for Early Modern London, 1550-1650.” Placing Names: Enriching and Integrating Gazetteers. Ed. Merrick Lex Berman, Ruth Mostern, and Humphrey Southall. Bloomington: Indiana UP, 2016. 129-145.

[rmostern]

Thank you.

From: Vincent Ducatteeuw @.> Sent: Tuesday, November 14, 2023 3:45 AM To: programminghistorian/ph-submissions @.> Cc: Mostern, Ruth @.>; Mention @.> Subject: Re: [programminghistorian/ph-submissions] Working with Named Places: How and Why to Build a Gazetteer (Issue #580)

J. T. Hastings (2008) Automated conflation of digital gazetteer data, International Journal of Geographical Information Science, 22:10, 1109-1127, DOI: 10.1080/13658810701851453https://doi.org/10.1080/13658810701851453

I refer to an talk given by Dr. Janelle Jenstad for the Pelagios Network Gazetteer Activity group. A recording of it can be found here: https://medium.com/pelagios/janelle-jenstad-on-urban-gazetteer-design-698852e55bea. Unfortunately, no article has been published about it yet.

For a general overview of Early Modern London gazetteer Janelle Jenstad. "Building a Gazetteer for Early Modern London, 1550-1650." Placing Names: Enriching and Integrating Gazetteers. Ed. Merrick Lex Berman, Ruth Mostern, and Humphrey Southall. Bloomington: Indiana UP, 2016. 129-145.

- Reply to this email directly, view it on GitHubhttps://github.com/programminghistorian/ph-submissions/issues/580#issuecomment-1809765106, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AHLCEQNLAHVHFJJ5GPGOYQTYEMVQ5AVCNFSM6AAAAAA2VKVIVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMBZG43DKMJQGY. You are receiving this because you were mentioned.Message ID: @.**@.>>

[yann-ryan]

Our second reviewer will be Andy Janco (@apjanco), who aims to complete the review before December 21. Thanks Andy!

[apjanco]

Dear @grunewas and @rmostern,

Thank you for the chance to read this post. I'm meeting it late in the editorial process, so most of the low lying fruit have already been addressed and this feels like a very polished post.

I really like the section on "Gazetteer or GIS?" I think it could be helpful to share links to an example of a project where GIS is clearly the better option and where a gazetteer is the better place to start. Complicated place names are probably not the only reason one would choose one over the other. This is discussed in the conclusion in some detail, so I'd recommend moving that here to catch your reader as not everyone makes it all the way to the end and this is a key contribution of the post.

Furthermore, it would help to be very specific about your intervention. If I understand right, you're pushing back against the tendency to start with ArcGIS or QGIS. I agree that they're not always the best place to start and everything needs good data, so start with the data. If that's true, you might come out and say this more directly.

It would also be helpful to have some bearing on how creating a gazetteer opens new research possibilities with the Itinerary of Benjamin of Tudela. I'd just make it clear to the reader what we gain from having this resource and what doors it opens. For example, we cannot map map of the journey unless we can normalize changing and contested places across materials, which is only possible with a gazetteer. It makes it possible to distinguish between places visited and places simply mentioned in the text.

I'd also keep in mind that this a case of a historical traveling person. This will help many readers, but will be incomplete for other. If I'm studying a fictional work, for example, how can I map places that can't be geocoded because they don't exist, or don't exist on this planet? A gazetteer would still be a useful form of close reading even if we don't get lat/long points. However, given that we're in Programming Historian, I think it's a great example.

Thank you again for the chance to read this in advance and please feel free to add follow up questions here.

[yann-ryan]

Hi @apjanco, many thanks for this thoughtful review! @grunewas and @rmostern: next I will make a suggested list of changes based on the two reviews above. I'll aim to finish this by Friday 29 December. Looking forward to moving this onto the next stage!

[yann-ryan]

Hi @grunewas and @rmostern,

First of all sincere apologies for the delay in summarising the reviews! Both reviewers have suggested mostly small changes to the text, for clarification and readability. I suggest going through each of the comments of @VincentDucatteeuw in turn and making the suggested changes (I'll paste them below). I have also turned the suggestions from @apjanco into a set of actionable tasks.

• [ ] Paragraph 2: perhaps a distinction between historical gazetteers and digital gazetteers is needed to make it clear to the reader that while there are historical documents that are considered gazetteers, this lesson focuses on the development of their digital equivalent.

• [ ] Paragraphs 7-10: relevant introduction to the topic of place for readers unfamiliar with the concept. Prominent authors are mentioned, which is great. I understand that it is not possible to refer to every author who has discussed the concept, but if possible I would suggest referencing the work of Yi-Fu Tuan (Space and Place, 1977). Of course, his ideas have since been refined by the authors already mentioned, but I find the work quite accessible for beginners.

• [ ] Paragraphs 11-13: both gazetteers and GIS are based on spatial data, structured in particular formats. The distinction that gazetteers are dataset based, while GIS are map based may be confusing to the unfamiliar reader. To make the distinction clearer, I would suggest adding that the focus of GIS is primarily on the projection geospatial geometries in the form of points, lines and polygons - and while gazetteer may contain geographical information, its primary focus is on structuring the humanistic complexities of place.

• [ ] Paragraph 16: “There is no objective way to decide whether to group these names together as references to a single place.” While it is true that there is no objective way, there may be value in reaching a shared consensus on disambiguation principles for the interoperability and reusability of gazetteers. Within the historical discipline, some work has been done in this regard (Garbacz et al., Identity of historical localities in information systems, 2021; Jenstad, Urban gazetteer design: principles for disambiguating places and toponyms, 2020). It would be helpful for the reader to indicate which properties of a place are used in this lesson to disambiguate places. (e.g. describe why Montpellier is considered an alternative name to Har Gaash).

• [ ] Paragraph 18: I would suggest moving the paragraph about the Linked Places format and adding it to paragraph 23. Introducing the paragraph on building a gazetteer from a historical source before discussing gazetteer data models would create a more coherent flow.

• [ ] Paragraph 29: typos, ‘correspodning’, ‘pargraph’.

• [ ] Paragraph 33: typo ‘the the’.

Based on comments from @apjanco:

• [ ] At the beginning, could you share links to an example of a project where GIS is clearly the better option and where a gazetteer is the better place to start?
• [ ] If you agree - be more specific in pushing back against starting with ArcGIS etc.
• [ ] Provide some clarity on the research opportunities of creating a gazetteer from a journey such as the one used in the tutorial.
• [ ] I think the suggestion to add that it is still possible to create a gazetteer without lat/long points (such as a fictional person or journey) is a really good one, and would broaded the appeal of the lesson.

These are the main substantial revisions, for now, I think. Could you reply and let me know when you would hope to complete them by?

[grunewas]

Hi Yann,

Thanks for compiling the feedback for us. Ruth and I have met to discuss the revisions. We should have a revised draft for you by the end of January.

Best, Susan

On Fri, Jan 5, 2024, 7:46 AM Yann Ryan @.***> wrote:

Hi @grunewas https://github.com/grunewas and @rmostern https://github.com/rmostern,

First of all sincere apologies for the delay in summarising the reviews! Both reviewers have suggested mostly small changes to the text, for clarification and readability. I suggest going through each of the comments of @VincentDucatteeuw https://github.com/VincentDucatteeuw in turn and making the suggested changes (I'll paste them below). I have also turned the suggestions from @apjanco https://github.com/apjanco into a set of actionable tasks.

-

Paragraph 2: perhaps a distinction between historical gazetteers and digital gazetteers is needed to make it clear to the reader that while there are historical documents that are considered gazetteers, this lesson focuses on the development of their digital equivalent.

Paragraphs 7-10: relevant introduction to the topic of place for readers unfamiliar with the concept. Prominent authors are mentioned, which is great. I understand that it is not possible to refer to every author who has discussed the concept, but if possible I would suggest referencing the work of Yi-Fu Tuan (Space and Place, 1977). Of course, his ideas have since been refined by the authors already mentioned, but I find the work quite accessible for beginners.

Paragraphs 11-13: both gazetteers and GIS are based on spatial data, structured in particular formats. The distinction that gazetteers are dataset based, while GIS are map based may be confusing to the unfamiliar reader. To make the distinction clearer, I would suggest adding that the focus of GIS is primarily on the projection geospatial geometries in the form of points, lines and polygons - and while gazetteer may contain geographical information, its primary focus is on structuring the humanistic complexities of place.

Paragraph 16: “There is no objective way to decide whether to group these names together as references to a single place.” While it is true that there is no objective way, there may be value in reaching a shared consensus on disambiguation principles for the interoperability and reusability of gazetteers. Within the historical discipline, some work has been done in this regard (Garbacz et al., Identity of historical localities in information systems, 2021; Jenstad, Urban gazetteer design: principles for disambiguating places and toponyms, 2020). It would be helpful for the reader to indicate which properties of a place are used in this lesson to disambiguate places. (e.g. describe why Montpellier is considered an alternative name to Har Gaash).

Paragraph 18: I would suggest moving the paragraph about the Linked Places format and adding it to paragraph 23. Introducing the paragraph on building a gazetteer from a historical source before discussing gazetteer data models would create a more coherent flow.

Paragraph 29: typos, ‘correspodning’, ‘pargraph’.

Paragraph 33: typo ‘the the’.

Based on comments from @apjanco https://github.com/apjanco:

• At the beginning, could you share links to an example of a project where GIS is clearly the better option and where a gazetteer is the better place to start?
• If you agree - be more specific in pushing back against starting with ArcGIS etc.
• Provide some clarity on the research opportunities of creating a gazetteer from a journey such as the one used in the tutorial.
• I think the suggestion to add that it is still possible to create a gazetteer without lat/long points (such as a fictional person or journey) is a really good one, and would broaded the appeal of the lesson.

These are the main substantial revisions, for now, I think. Could you reply and let me know when you would hope to complete them by?

— Reply to this email directly, view it on GitHub https://github.com/programminghistorian/ph-submissions/issues/580#issuecomment-1878611264, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJTTIKXPDAOYE7CC3GPL4TYM7Y2PAVCNFSM6AAAAAA2VKVIVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZYGYYTCMRWGQ . You are receiving this because you were mentioned.Message ID: @.***>

[yann-ryan]

@hawc2 @anisa-hawes @charlottejmc I've just uploaded a revised version of the lesson to the drafts folder. I've also requested that @rmostern and @grunewas list the changes made, provide author information, the copyright form, and think about an image to represent the lesson. Looking forward to moving this to the next stage!

[yann-ryan]

- name: Susan Grunewald
  orcid: 0000-0003-1275-4101
  team: false
  bio:
    en: |
      Susan Grunewald is an Assistant Professor in the Department of History at Louisiana State University.

- name: Ruth Mostern
  orcid: 0000-0001-8219-7174
  team: false
  bio:
    en: |
      Ruth Mostern is a Professor in the Department of History at the University of Pittsburgh.

Summary of changes made:

--distinguishing digital gazetteers from print gazetteers in paragraph 2

--small changes to wording and new footnotes in “What is a Place”

--small changes to wording and new footnote at the end of “Considerations.”

-- links to example projects where GIS is better and where gazetteer is better starting point added plus more explicit push back against starting with ArcGIS in paragraph 11

-- More explicit references to research opportunities of creating a research gazetteer in paragraph 19

-- discussion of open data standards moved entirely to paragraph 25

-- various awkward wordings or spelling mistakes fixed throughout

[anisa-hawes]

Many thanks, @yann-ryan.

Thank you for all your work through the process of revision Susan @grunewas and Ruth @rmostern.

--

Hello @hawc2,

Over to you for a read-through to approve the authors' final revisions before I move this lesson forward to copyedit and sustainability + accessibility checks.

With thanks, Anisa

[hawc2]

Thanks @grunewas and @rmostern for this lovely lesson. I've enjoyed reading it, and found it very elucidating. I've done a round of line editing, mostly breaking up long paragraphs and streamlining some of the language. You'll see I reshaped the intro section slightly, making sure you define gazateer before you get into the affordances of digital gazateers.

Most of the advice for revision I've provided below involves minor changes to formatting and style, I hope it won't take long for you to address these. As you fix things, please check off the changes in this comment, and let us know if there's any additional thoughts you have about the revisions. Once you get back these additional revisions, I'll read it over once more before sending it on for copyediting and publication preparation.

• [ ] I wasn't sure the best way to restructure this element, but it's a little odd that it's not really until paragraph 13 that you provide a simple definition of Gazateer ("In its simplest form, a gazetteer is an index or dictionary of place names"). Ideally those sentences could be brought up earlier, and not need simple repeating in paragraph 13.

• [ ] Around paragraph 25, you introduce concepts more fully about LP and LP-TSV. I've tried to make sure you introduce those acronyms the first time you mention the concept, but you should go back over my edits and make sure I didn't incorrectly abbreviate something. It wasn't always clear to me if you we're referring to both or just LP-TSV. Ideally you'd introduce this concept the first time you bring it up - as of now, it's cited once, and then explained more fully five paragraphs later.

• [ ] On this topic, just before the Conclusion, you define Linked Open Data, but you introduced the concept much earlier, and should define it at the start, rather than the end of the lesson).

• [ ] I'd also recommend adding more subheadings to guide the reader. For instance, alot happens in the Building Spreadsheets Field section, and it might help guide the reader to have a subsection called LP-TSV to frame that part of the section.

• [ ] One stylistic thing to be mindful of, ideally the lesson is more oriented around second person than first person plural. Can you try to change some of your sentences from 'we will' to 'you will' or the like? I've done this in some places, but it would be good to have you go over the lesson one last time before we send it to copyedits, not least to make sure these changes haven't lost any of your intended meaning.

• [ ] The note that begins "As a note, we are formatting our column headers" strikes me as multiple notes, each very important. Could they be separated? Could they be integrated into the lesson commentary more clearly, rather than as a Note? Right now it looks pretty odd in the lesson preview, two very long paragraphs separated out in a different color. Notes like that should be kept to a few sentences maximum. As you break up those notes and integrate them more cohesively into your sentence, I'd recommend breaking up the paragraphs. As you'll see, I've made this sort of line edit throughout, ensuring paragraphs are short (well-suited to the web) and each beginning with clear topic sentences. These notes seem to contain two-three paragraphs each, many of which are disconnected points.

• [ ] As you think about integrating these notes, try to find ways to break the monotony of paragraphs that provide a series of steps with phrases like "Next, we need to". Ideally the lesson is in second person, and in cases where there are a series of sequential steps, consider using bullet points and succinct sentences to get the information across more clearly. I'm thinking of the section, Adding Historical Data to a Spreadsheet. It is a good opportunity to talk about a specific example, the challenges to this process when translating qualitative to quantitative data, or in other words annotating/coding a text. In addition, adding more subheadings will make sections like this with lots of steps and caveats easier to follow. So be liberal with the subheadings here, don't let any section run on too long without a signpost...

• [ ] Another stylistic thing to be mindful of, that became more apparent near the end, was sentences that don't transition very clearly between each other. The paragraph that talks about the WHG involves a series of sentences that begin with the word "This" and in each case it's not quite clear what "This" refers to.

• [ ] In the Conclusion section, the bullet points don't really help make that section easy to follow. Is there a different way to structure these sentences? Like, the following situations are appropriate for GIS, and then the second set are for Gazatteer or something like that?

• [ ] My main other thought is that it remains a little buried at the end how this lesson connects to other Programming Historian lessons. The final section, Related Programming Historian Lessons for Future Study, could be moved up above the Conclusion, and you could say a little more about the extensions of this lesson for further analysis.

• [ ] In addition, it is really buried in here that you have another PH lesson that is deeply relevant to this one. Ideally that would be forecast early on, and you'd make more of a case for how the two lessons connect and can be read together.

• [ ] One question I had is do the Tables require as many rows as you input? They take up alot of space on the page as images, and I could see it appearing better if they we're shorter. Other figures don't appear to be rendering correctly yet @anisa-hawes

I think that's pretty much everything. The overall structure, argument, and narrative of this lesson work really well. Now it's just about clarifying the language and making sure you bring into relief the most important instructions and observations.

Thanks for all your work thus far and for making these revisions. Please let us know if you'll need more than a couple weeks to address these changes. Looking forward to seeing this published!

[grunewas]

Hi Alex,

Thanks for the feedback. Ruth and I will meet and work to incorporate the changes you suggested.

Best, Susan

On Tue, Feb 6, 2024, 6:44 PM Alex Wermer-Colan @.***> wrote:

Thanks @grunewas https://github.com/grunewas and @rmostern https://github.com/rmostern for this lovely lesson. I've enjoyed reading it, and found it very elucidating. I've done a round of line editing, mostly breaking up long paragraphs and streamlining some of the language. You'll see I reshaped the intro section slightly, making sure you define gazateer before you get into the affordances of digital gazateers.

Most of the advice for revision I've provided below involves minor changes to formatting and style, I hope it won't take long for you to address these. As you fix things, please check off the changes in this comment, and let us know if there's any additional thoughts you have about the revisions. Once you get back these additional revisions, I'll read it over once more before sending it on for copyediting and publication preparation.

-

I wasn't sure the best way to restructure this element, but it's a little odd that it's not really until paragraph 13 that you provide a simple definition of Gazateer ("In its simplest form, a gazetteer is an index or dictionary of place names"). Ideally those sentences could be brought up earlier, and not need simple repeating in paragraph 13.

Around paragraph 25, you introduce concepts more fully about LP and LP-TSV. I've tried to make sure you introduce those acronyms the first time you mention the concept, but you should go back over my edits and make sure I didn't incorrectly abbreviate something. It wasn't always clear to me if you we're referring to both or just LP-TSV. Ideally you'd introduce this concept the first time you bring it up - as of now, it's cited once, and then explained more fully five paragraphs later.

On this topic, just before the Conclusion, you define Linked Open Data, but you introduced the concept much earlier, and should define it at the start, rather than the end of the lesson).

I'd also recommend adding more subheadings to guide the reader. For instance, alot happens in the Building Spreadsheets Field section, and it might help guide the reader to have a subsection called LP-TSV to frame that part of the section.

One stylistic thing to be mindful of, ideally the lesson is more oriented around second person than first person plural. Can you try to change some of your sentences from 'we will' to 'you will' or the like? I've done this in some places, but it would be good to have you go over the lesson one last time before we send it to copyedits, not least to make sure these changes haven't lost any of your intended meaning.

The note that begins "As a note, we are formatting our column headers" strikes me as multiple notes, each very important. Could they be separated? Could they be integrated into the lesson commentary more clearly, rather than as a Note? Right now it looks pretty odd in the lesson preview, two very long paragraphs separated out in a different color. Notes like that should be kept to a few sentences maximum. As you break up those notes and integrate them more cohesively into your sentence, I'd recommend breaking up the paragraphs. As you'll see, I've made this sort of line edit throughout, ensuring paragraphs are short (well-suited to the web) and each beginning with clear topic sentences. These notes seem to contain two-three paragraphs each, many of which are disconnected points.

As you think about integrating these notes, try to find ways to break the monotony of paragraphs that provide a series of steps with phrases like "Next, we need to". Ideally the lesson is in second person, and in cases where there are a series of sequential steps, consider using bullet points and succinct sentences to get the information across more clearly. I'm thinking of the section, Adding Historical Data to a Spreadsheet. It is a good opportunity to talk about a specific example, the challenges to this process when translating qualitative to quantitative data, or in other words annotating/coding a text. In addition, adding more subheadings will make sections like this with lots of steps and caveats easier to follow. So be liberal with the subheadings here, don't let any section run on too long without a signpost...

Another stylistic thing to be mindful of, that became more apparent near the end, was sentences that don't transition very clearly between each other. The paragraph that talks about the WHG involves a series of sentences that begin with the word "This" and in each case it's not quite clear what "This" refers to.

In the Conclusion section, the bullet points don't really help make that section easy to follow. Is there a different way to structure these sentences? Like, the following situations are appropriate for GIS, and then the second set are for Gazatteer or something like that?

My main other thought is that it remains a little buried at the end how this lesson connects to other Programming Historian lessons. The final section, Related Programming Historian Lessons for Future Study, could be moved up above the Conclusion, and you could say a little more about the extensions of this lesson for further analysis.

In addition, it is really buried in here that you have another PH lesson that is deeply relevant to this one. Ideally that would be forecast early on, and you'd make more of a case for how the two lessons connect and can be read together.

One question I had is do the Tables require as many rows as you input? They take up alot of space on the page as images, and I could see it appearing better if they we're shorter. Other figures don't appear to be rendering correctly yet @anisa-hawes https://github.com/anisa-hawes

I think that's pretty much everything. The overall structure, argument, and narrative of this lesson work really well. Now it's just about clarifying the language and making sure you bring into relief the most important instructions and observations.

Thanks for all your work thus far and for making these revisions. Please let us know if you'll need more than a couple weeks to address these changes. Looking forward to seeing this published!

— Reply to this email directly, view it on GitHub https://github.com/programminghistorian/ph-submissions/issues/580#issuecomment-1931034274, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJTTIIXU7IVWHDKGAEBOI3YSLE77AVCNFSM6AAAAAA2VKVIVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZRGAZTIMRXGQ . You are receiving this because you were mentioned.Message ID: @.***>

[anisa-hawes]

Please let us know if you need any practical support making the revisions, @grunewas. You can work directly on your Markdown file here: /en/drafts/originals/space-place-gazetteers.md.

Thank you for drawing my attention with the problem rendering the replacement images, @hawc2. Apologies for missing this. Both display as they should now. I've also added a snippet of code above and below each table so that they are scrollable widthways (they were previously displaying with truncated columns at the right margin).

[grunewas]

Thanks, Anisa. If I have a problem directly editing the file, I'll let you know.

On Wed, Feb 7, 2024 at 3:52 PM Anisa Hawes @.***> wrote:

Please let us know if you need any practical support making the revisions, @grunewas https://github.com/grunewas. You can work directly on your Markdown file here: /en/drafts/originals/space-place-gazetteers.md https://github.com/programminghistorian/ph-submissions/blob/gh-pages/en/drafts/originals/space-place-gazetteers.md .

Thank you for drawing my attention with the problem rendering the replacement images, @hawc2 https://github.com/hawc2. Apologies for missing this. Both display as they should now. I've also added a snippet of code above and below each table so that they are scrollable widthways (they were previously displaying with truncated columns at the right margin).

— Reply to this email directly, view it on GitHub https://github.com/programminghistorian/ph-submissions/issues/580#issuecomment-1932862253, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEJTTIMHRBNNIJABIZPDVQTYSPSRRAVCNFSM6AAAAAA2VKVIVWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMZSHA3DEMRVGM . You are receiving this because you were mentioned.Message ID: @.***>

[grunewas]

We are surprised that our article has received a round of editing in between the external reviews and copy editing. Nevertheless, we are grateful for the attention, and we are happy to address many of your recommendations. It is too bad that it has been challenging to work with github as you have set it up. Hopefully this has not compounded any confusion. We have lightly revised our lesson as per the attached document, which explains how we have engaged with your advice.

@anisa-hawes I made the changes but it appears to have been done in a fork again. Please let me know if you need to me to do something else for the changes to integrate.

• ISSUE 1: I wasn't sure the best way to restructure this element, but it's a little odd that it's not really until paragraph 13 that you provide a simple definition of Gazetteer ("In its simplest form, a gazetteer is an index or dictionary of place names"). Ideally those sentences could be brought up earlier, and not need simple repeating in paragraph 13. o RESPONSE: We have added a short definition of gazetteer to paragraph 1.

• ISSUE 2: Around paragraph 25, you introduce concepts more fully about LP and LP-TSV. I've tried to make sure you introduce those acronyms the first time you mention the concept, but you should go back over my edits and make sure I didn't incorrectly abbreviate something. It wasn't always clear to me if you we're referring to both or just LP-TSV. Ideally, you'd introduce this concept the first time you bring it up - as of now, it's cited once, and then explained more fully five paragraphs later. o RESPONSE: We moved the explanation based on comments from earlier reviewers. If you think it should be returned to its original location in the lesson or read differently, we defer to you.

• ISSUE 3: On this topic, just before the Conclusion, you define Linked Open Data, but you introduced the concept much earlier, and should define it at the start, rather than the end of the lesson). o RESPONSE: We have moved it from paragraph 83 to paragraph 5.

• ISSUE 4: I'd also recommend adding more subheadings to guide the reader. For instance, a lot happens in the Building Spreadsheets Field section, and it might help guide the reader to have a subsection called LP-TSV to frame that part of the section. o RESPONSE: We have changed the subheadings a few times already based on previous reviewer requests. If you see additional places to put subheadings, please do so. We have also made some structural changes, see response to ISSUE 7.

• ISSUE 5: One stylistic thing to be mindful of, ideally the lesson is more oriented around second person than first person plural. Can you try to change some of your sentences from 'we will' to 'you will' or the like? I've done this in some places, but it would be good to have you go over the lesson one last time before we send it to copyedits, not least to make sure these changes haven't lost any of your intended meaning. o RESPONSE: I think we have finally caught all the instances of first person and changed them to second person.

• ISSUE 6: The note that begins "As a note, we are formatting our column headers" strikes me as multiple notes, each very important. Could they be separated? Could they be integrated into the lesson commentary more clearly, rather than as a Note? Right now it looks pretty odd in the lesson preview, two very long paragraphs separated out in a different color. Notes like that should be kept to a few sentences maximum. As you break up those notes and integrate them more cohesively into your sentence, I'd recommend breaking up the paragraphs. As you'll see, I've made this sort of line edit throughout, ensuring paragraphs are short (well-suited to the web) and each beginning with clear topic sentences. These notes seem to contain two-three paragraphs each, many of which are disconnected points. o RESPONSE: We removed the note formatting for both and created a new subheading for Best Practices for Data Formatting and Data Interoperability.

• ISSUE 7: As you think about integrating these notes, try to find ways to break the monotony of paragraphs that provide a series of steps with phrases like "Next, we need to". Ideally the lesson is in second person, and in cases where there are a series of sequential steps, consider using bullet points and succinct sentences to get the information across more clearly. I'm thinking of the section, Adding Historical Data to a Spreadsheet. It is a good opportunity to talk about a specific example, the challenges to this process when translating qualitative to quantitative data, or in other words annotating/coding a text. In addition, adding more subheadings will make sections like this with lots of steps and caveats easier to follow. So be liberal with the subheadings here, don't let any section run on too long without a signpost... o RESPONSE: We have bolded instructions for steps so that readers can make sure they are clearly noted, while also keeping the explanatory rhetoric of how and why each of these steps are done in the way that they are done.

• ISSUE 8: Another stylistic thing to be mindful of, that became more apparent near the end, was sentences that don't transition very clearly between each other. The paragraph that talks about the WHG involves a series of sentences that begin with the word "This" and in each case it's not quite clear what "This" refers to. o RESPONSE: We believe that we have fixed the specific issue you raise. We look forward to the copyediting stage to flag any other instances like this.

• ISSUE 9: In the Conclusion section, the bullet points don't really help make that section easy to follow. Is there a different way to structure these sentences? Like, the following situations are appropriate for GIS, and then the second set are for Gazetteer or something like that? o RESPONSE: We find the bullet points to be the best way to succinctly summarize these major points behind the lesson, and we would like to leave this section as-is.

• ISSUE 10: My main other thought is that it remains a little buried at the end how this lesson connects to other Programming Historian lessons. The final section, Related Programming Historian Lessons for Future Study, could be moved up above the Conclusion, and you could say a little more about the extensions of this lesson for further analysis. o RESPONSE: We have followed the template of other lessons, including ([https://programminghistorian.org/en/lessons/finding-places-world-historical-gazetteer][(https://programminghistorian.org/en/lessons/finding-places-world-historical-gazetteer), where related lessons or additional readings are given their own section after the conclusion. If you think they should go elsewhere, please move them.

• ISSUE 11: In addition, it is really buried in here that you have another PH lesson that is deeply relevant to this one. Ideally that would be forecast early on, and you'd make more of a case for how the two lessons connect and can be read together. o RESPONSE: See above.

• ISSUE 12: One question I had is do the Tables require as many rows as you input? They take up alot of space on the page as images, and I could see it appearing better if they we're shorter. Other figures don't appear to be rendering correctly yet @anisa-hawes o RESPONSE: Per your earlier point of " translating qualitative to quantitative data, or in other words annotating/coding a text," we need these tables to remain as they are. They illustrate just three short paragraphs from the sample text, and they reflect key aspects of creating the building blocks of a functional and shareable historical gazetteer. We agree that they look too large. We recommend that you use a format that renders them in a more compact way if possible.

[anisa-hawes]

Dear @grunewas,

I'm sorry to hear that you've had difficulties editing the file directly. I'm afraid that I can't see your edits on the lesson from our side, and so I'd like to ask if you could share a link to your fork with me? I'm happy to integrate your changes from there.

I'd also be very happy to connect at a time that suits you, so that I can better understand how you've experienced the set up and make adjustments as necessary. Please let me know if you feel this would be useful.

Thank you for your detailed notes (above) which annotate your revisions. Alex and I can review these in more detail when have the changes integrated into the file here on our repo: /en/drafts/originals/space-place-gazetteers.md.

In answer to the query about the scale of the tables: as far as I know, there isn't a facility to reduce the size of the Markdown tables, but what we could consider is providing fewer sample rows of data in each case. For example, we could provide the first 5 rows only (rather than 10 rows). What do you think?

Looking forward to working through these final stages with you ahead of publication.

Thank you for your patience, Anisa

[grunewas]

@anisa-hawes If I click edit, I get an option to edit in a fork. There is a drop-down that says "edit in place." If I choose that, I get the following message, "You’re making changes in a project you don’t have write access to. Submitting a change will write it to a new branch in your fork grunewas/ph-submissions, so you can send a pull request." In theory the changes I made are somewhere within this fork: https://github.com/grunewas/ph-submissions, I'm just not sure how to find it again within the path structure of the project. If it's lost, I copied and pasted everything into my text editor and can email someone a markdown file if necessary as a backup.

Regarding the tables, we need all ten rows to illustrate different important aspects of building the gazetteer. They will have to remain that way.

[anisa-hawes]

Thank you, @grunewas. I think the problem is that the invitation I sent you to provide the Write access you need to edit this file has expired.

I've located your recent edits in a branch of your fork, so I've applied the edits on your behalf: https://github.com/programminghistorian/ph-submissions/commit/cd06a389900bcb5aa290a673f16c3e25ca35e97f

Thank you for clarifying that all ten sample rows in the tables are necessary for the lesson. Everything on the live site is slightly more compact and more streamlined than in our Preview, so my sense is that the proportions will be fine upon publication.

All best, Anisa

[hawc2]

@grunewas thanks for going through all my feedback so carefully.

As Managing Editor, I review lessons before they go to copyedit, and most of my efforts focus on trying to help improve the readability of the lessons in keeping with the styling and other conventions we are trying to practice in our recent and future publications. This stage of review and feedback also gives the authors one last chance to think over the lesson and make any final edits before we move into copyedits, after which it can be difficult to make substantial changes.

Now that you've incorporated most of the remaining revisions, the lesson can go into copyedits. I'll hand it off to @anisa-hawes and @charlottejmc to begin. I'll also review the lesson one last time as its prepared for publication. You'll have a last chance to look it over as well, and then publication!

There are a few issues, 2, 9, 10, 11, that I'll let @anisa-hawes decide as part of the copyediting stage. @anisa-hawes in terms of where Prerequisites are usually listed in lessons (issue 10 and 11), personally speaking, I find it helpful when they are briefly stated up front, even if just sign posting to particularly relevant lessons we've published. It can be odd to read to the end of a lesson only to then find out what you should have read before starting.

[charlottejmc]

Thank you @hawc2,

I'll now begin my copyedits, and I aim to complete the work by Friday 15 March.

@grunewas and @rmostern, please note that you won't have direct access to make further edits to your files during this phase.

Any further revisions can be discussed with your editor @yann-ryan after copyedits are complete.

Thank you for your understanding.

[charlottejmc]

Hello @grunewas, @rmostern and @yann-ryan, I've prepared a PR with the copyedits for your review.

There, you'll be able to review the 'rich-diff' to see my edits in detail. You'll also find brief instructions for how to reply to questions or comments which came up during the copyedit.

When you're both happy, we can merge in the PR.

[anisa-hawes]

Hello @hawc2,

This lesson's sustainability + accessibility checks are in progress.

• Preview:

http://programminghistorian.github.io/ph-submissions/en/drafts/originals/lesson-slug

Publisher's sustainability + accessibility actions:

• [x] Copyediting
• [x] Typesetting
• [x] Addition of Perma.cc links
• [x] Check/resize images
• [x] Check/adjust image filenames
• [x] Receipt of author(s) copyright agreement Hello @grunewas and @rmostern, Our authorial copyright declaration form is an opportunity to acknowledge copyright and grant us permission to publish the lesson. Could you download this, complete the details, and email it to Charlotte (publishing.assistant [@] programminghistorian.org)? Many thanks.
• [x] Add doi
• [x] Add all contributor names to our list of Unique Contributors

Authorial / editorial input to YAML:

• [x] Define difficulty:, based on the criteria set out here
• [x] Define the research activity: this lesson supports (acquiring, transforming, analysing, presenting, or sustaining) Choose one
• [x] Define the lesson's topics: (api, python, data-management, data-manipulation, distant-reading, get-ready, linked-open-data, mapping, network-analysis, web-scraping, digital-publishing, r, machine-learning, creative-coding, or data-visualization) Choose one or more. Let us know if you'd like us to add a new topic
• [x] Provide alt-text for all figures
• [x] Provide a short abstract: for the lesson
• [x] Agree an avatar (thumbnail image) to accompany the lesson

The image must be:

• copyright-free
• non-offensive
• an illustration (not a photograph)
• at least 200 pixels width and height Image collections of the British Library, Internet Archive Book Images, Library of Congress Maps as well as their Photos/Prints/Drawings or the Virtual Manuscript Library of Switzerland are useful places to search

• [x] Provide avatar_alt: (visual description of that thumbnail image)

• [x] Provide author(s) bio for ph_authors.yml using this template:

• name: Susan Grunewald orcid: 0000-0003-1275-4101 team: false bio: en: | Susan Grunewald is an Assistant Professor in the Department of History at Louisiana State University.

• name: Ruth Mostern orcid: 0000-0001-8219-7174 team: false bio: en: | Ruth Mostern is a Professor in the Department of History at the University of Pittsburgh.

Files we'll prepare for transfer to Jekyll:

EN:

• .md file: /en/drafts/originals/space-place-gazetteers.md
• images: /images/space-place-gazetteers
• assets: /assets/space-place-gazetteers
• original avatar: /gallery/originals
• gallery avatar: /gallery

Promotion:

• [x] Prepare announcement post (using template)
• [ ] Prepare evergreen posts – @hawc2, could you please provide x2 posts for future promotion via our social media channels? You can add these directly to the ph-evergreens-twitter-x spreadsheet that has been shared with you, or email them to Charlotte at publishing.assistant[@]programminghistorian.org.

[grunewas]

@anisa-hawes We already sent all, if not most, of the requested additional YAML information to @yann-ryan via email a while ago.

[yann-ryan]

Hi @grunewas and @rmostern. I've looked through our email conversations and I don't have anything for these missing pieces of metadata, only the author bios which are posted above. My suggestions are:

difficulty: 1
activity: acquiring
topics: data-management, linked-open-data, mapping
abstract: A digital gazetteer records information associated with specific places. This lesson teaches you how to create a gazetteer from a historical text, using the Linked Places Delimited (LP-TSV) format. 

I suppose transforming could also work as an activity.

For the avatar I suggest we use this image of a compass, from the Library of Congress (no known copyright restrictions).

@grunewas, as the lead author, has signed the author agreement. I can send another copy if you'd like to let me know where it should go (@anisa-hawes currently has a copy).

[rmostern]

I am fine with your suggestions for the missing pieces of metadata.

I would rather not use the European compass image. Here is an alternative LOC (rights free) image that I would prefer: https://www.loc.gov/resource/g3860.ct000734/ - either the whole image, or cropped in to the network of names.

Ruth

[charlottejmc]

Hello @rmostern,

I have added in the metadata and uploaded your proposed avatar to our gallery. We're just missing one final element, which is the alt-text for this avatar. Could you please provide a visual description of the image, phrased in a way that would allow our visually impaired readers to grasp what it portrays? I would add it in myself, but I'm not exactly clear what the image shows. Just one short sentence would be perfect.

Thank you!

[anisa-hawes]

Thank you for suggesting the metadata @yann-ryan. Thank you for adding it + preparing the avatar @charlottejmc!

--

Hello @rmostern and @grunewas,

I have double-checked but I haven't received the authorial copyright declaration form. I'd be grateful if you could re-send this to us. Please email it to Charlotte: (publishing.assistant [@] programminghistorian.org). With thanks.

Anisa

[rmostern]

Here you go - a bit of a caption as well as a visual description.

This eighteenth century Map of the Several Nations of Indians to the Northwest of South Carolina depicts a network of Indigenous settlements connected by transportation routes, which was drawn on deerskin by a Native diplomat and subsequently annotated with English-language place names and other information by Francis Nicholson, the Governor of South Carolina.

Ruth

[rmostern]

Hello @anisa-hawes and cc @grunewas , Thank you for removing the links to Wikipedia from Susan’s and my lesson. I happened to see James Baker @drjwbaker and Riva Quiroga @rivaquiroga at a workshop here in Pittsburgh on another topic the last two days. We talked about the Wikipedia problem and the competing values that it raises. For lesson authors who are members of history faculties (at least in the United States), links to Wikipedia articles will be considered highly unprofessional. However, for readers, they’re a convenient and stable connection to basic information about a topic. James and Riva said that they would make it into a Topic on Github that the Programming Historian community could discuss; one compromise position that I suggested was that there could be a Glossary, offset from any lesson, that includes keywords and links and therefore makes it clear that the links are not part of an authored presentation of the material. I think that Susan and I would both be happy to chime in if there were a discussion thread about this policy, so if and when it starts, please tag us or otherwise let us know.

[anisa-hawes]

Thank you for your willingness to discuss this with us @rmostern and @grunewas.

I have created an Issue within our Jekyll repository to continue the conversation: /jekyll/issues/3207 .

[rmostern]

Thank you! I'll respond to the thread soon, but I want to wait first and hear what others have to say, especially since you summarized Susan's and my position well and linked to the discussion of our lesson.

Ruth

[anisa-hawes]

Hello @hawc2,

This lesson's sustainability + accessibility checks are now complete. It is ready for your final read-through ahead of publication.

• author(s) bio for ph_authors.yml

• name: Susan Grunewald orcid: 0000-0003-1275-4101 team: false bio: en: | Susan Grunewald is an Assistant Professor in the Department of History at Louisiana State University.

- name: Ruth Mostern
 orcid: 0000-0001-8219-7174
 team: false
 bio:
   en: |
     Ruth Mostern is a Professor in the Department of History at the University of Pittsburgh.

• .md file: /en/drafts/originals/space-place-gazetteers.md
• images: /images/space-place-gazetteers
• assets: /assets/space-place-gazetteers
• original avatar: /gallery/originals
• gallery avatar: /gallery

Promotion:

• [x] Template announcement posts (Prepared by Charlotte)
• [ ] Prepare evergreen posts – @hawc2, could you please provide x2 posts for future promotion via our social media channels? You can add these directly to the ph-evergreens-twitter-x spreadsheet that has been shared with you, or email them to Charlotte at publishing.assistant[@]programminghistorian.org.

[hawc2]

@anisa-hawes this looks good to go to me! I'll do a final look over once it's previewable on the Jekyll repo