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

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.

Jul 24 '23 09:07 yann-ryan

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

Jul 27 '23 21:07 anisa-hawes

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.

Lesson Overview (1-2) 1.1 Learning outcomes (3-4) 1.2 Prerequisites?
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)
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.

Aug 16 '23 13:08 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.

Aug 21 '23 09:08 yann-ryan

@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.

Sep 18 '23 18:09 grunewas

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.

Sep 20 '23 11:09 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

Oct 11 '23 09:10 anisa-hawes

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).

Oct 11 '23 09:10 yann-ryan

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

Oct 11 '23 10:10 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

Oct 12 '23 14:10 anisa-hawes

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

Oct 16 '23 16:10 yann-ryan

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: @.@.>>

Oct 16 '23 19:10 rmostern

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.

Nov 13 '23 08:11 VincentDucatteeuw

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

Nov 13 '23 18:11 rmostern

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

Nov 13 '23 18:11 rmostern

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: @.***>

Nov 13 '23 19:11 grunewas

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.

Nov 13 '23 22:11 yann-ryan

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: @.***>

Nov 13 '23 22:11 grunewas

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.

Nov 14 '23 08:11 VincentDucatteeuw

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: @.@.>>

Nov 14 '23 14:11 rmostern

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

Nov 24 '23 09:11 yann-ryan

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.

Dec 20 '23 15:12 apjanco

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!

Dec 21 '23 13:12 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?

Jan 05 '24 12:01 yann-ryan

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: @.***>

Jan 08 '24 20:01 grunewas

@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!

Jan 25 '24 15:01 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

Jan 28 '24 18:01 yann-ryan

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

Jan 31 '24 10:01 anisa-hawes

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!

Feb 07 '24 00:02 hawc2

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: @.***>

Feb 07 '24 13:02 grunewas

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).

Feb 07 '24 20:02 anisa-hawes