rlskoeser
commented
2 years ago Also, if there is a url on the footnote, let's make the "see pages" text a link
Closed blms closed 2 years ago
rlskoeser
commented
2 years ago Also, if there is a url on the footnote, let's make the "see pages" text a link
blms
commented
2 years ago Also, if there is a url on the footnote, let's make the "see pages" text a link
Curiously, there are actually only a handful of cases where both url and location are defined:
Edition of ENA 1822a.46 (PGPID 11235)
Edition of T-S 13J21.17 (PGPID 1025)
Edition of ENA 3974.3 + … (PGPID 19304)
Edition and Translation of Moss. I,40 (PGPID 26639)
Edition and Translation of T-S 12.70 (PGPID 9469)So I'll make sure all combinations of those are handled properly.
rlskoeser
commented
2 years ago We should have more urls once we import the links database (#325)
I forgot about the case where we have a url and no location; we should still make the link available! So we may want to get wording from the team for that case.
blms
commented
2 years ago For now, I'm thinking if there's a footnote URL but neither a source URL nor a footnote location, I'll make the source title link to the footnote URL. In the case where there's a footnote URL and a source URL but no footnote location—maybe we just make "includes" a link? Though, I do recall we had some question about whether or not "includes" was a good word to use, and not sure we came up with an alternative.
It also might not make sense to have the source title ever link to the footnote URL… I think I only started doing that because it was prior behavior.
rlskoeser
commented
2 years ago Do you want to do a quick check for how common it is to have source url and footnote url? (although we may not get accurate results without the links data). I think there are links to the whole item and links to the specific part, but that's likely more common in the links data (or maybe should only happen there?). If there are discrepancies now, it could be a result of a) not knowing which url it should be when we migrated from google sheets b) source url not currently editable in admin
blms
commented
2 years ago Yes, right now there are no source URLs! Probably because it was missing in the admin view. I wonder if a lot of the footnote URLs should actually be source URLs. Here's a small sampling:
source: Lévi Israël, "Document relatif à la «Communauté des fils de Sadoc»" (in French), Revue des études juives 65, n°129 (1913)
footnote.url: https://www.persee.fr/doc/rjuiv_0484-8616_1913_num_65_129_5149
source: Adalbert Merx, Documents de paléographie hébraïque et arabe (in French) (1894)
footnote.url: https://archive.org/details/documentsdepalo00merxgoog.
source: Ṣabīḥ ʿAodeh, "Eleventh Century Arabic Letters from the Cairo Geniza" (in Hebrew), Teʿudah 14 (1998)
footnote.url: https://humanities.tau.ac.il/sites/humanities.tau.ac.il/files/media_server/Jewish%20History/Teuda/Teuda-%20vol%2014-%20English/Teuda-%20Vol%2014-%2010-%20Aodeh.pdf
source: Judith Olszowy-Schlanger, "La lettre de divorce caraïte et sa place dans les relations entre Caraïtes et Rabbanites au Moyen Age (Une étude de manuscrits de la Geniza du Caire)" (in French), Revue des Etudes Juives 155:3–4 (1996)
footnote.url: https://www.academia.edu/38307649/Judith_Olszowy-Schlanger_La_lettre_de_divorce_cara%C3%AFte_et_sa_place_dans_les_relations_entre_Cara%C3%AFtes_et_Rabbanites_au_Moyen_Age_Une_%C3%A9tude_de_manuscrits_de_la_Geniza_du_Caire_Revue_des_Etudes_Juives_155_3-4_July-December_1996_261-285
richmanrachel
commented
2 years ago It works, but still isn't quite as clear as I would have hoped... I know that it would be challenging to create a rule about whether to put "See pp." or "See document #" because it's unclear, but I'm not sure how legible this is to the average user:
richmanrachel
commented
2 years ago For example, I'm not sure it's immediately obvious that 348-50 is the page range for that article. But when I clicked another document (3504), this information was supplied (and was clearer):
rlskoeser
commented
2 years ago @richmanrachel I see what you mean. Can we come up with an easy and accurate way to determine when to add 'pp.'? If it starts with numbers, can we always add pp? Do we need to distinguish between pp. and p. ? I did a quick look at the locations in the database, and we have some numbers with ranges, some with ff., some with commas. We also have locations like 49ב — would that be prefixed with a p/pp?
richmanrachel
commented
2 years ago @rlskoeser - I'm not sure if there is an easy way, because my guess is that the entries to this field are quite varied. For ex. 49ב is a document number (rather than a page number). Would it be easy to run a script to see the variety of entries to get a sense of what we're dealing with?
The other faster/less elegant solution is to just put "See pp./document #" and allow there to be some redundancy for self-named "doc. 68," etc. My guess is that most page entries will be more than a page, so I don't mind if occasionally there's a mismatch between pp and a single number.
rlskoeser
commented
2 years ago @richmanrachel here's a list of all the footnote locations that start with a numeric (click to expand). I think we can come up with a regex that will work for most cases, especially if we don't have to distinguish between pp and p.
Is this a deal-breaker? I'm inclined to make this a separate feature because I don't want to delay bigger things.
92 347–48 400 - 409 80-84 92-98 340 146-147 248–49 201–05 119 264–65 61-63 27–28 233–34 113–16, 120 200 19, 46 252 55-60 44-46 70-73 48 25 182-84 104 321 156-159 166-69 265 18-19 163 4:106–07, doc. 633 171 278–79 213–16 468-470 137-45 34-35 740-743 206–07 (#121) 86 411 65-88 106 45 60-64 171–72 89–90 92–93 95–96 456-459 36 82 88-90 2016–2018 240–41 416 - 425 22, 24, 267 173–77, #96 105 326 - 389 197–98 6-7 433 - 439 215-236 21 117–18 119ff 153-154 256–57 172 138-143 279 364-366 43-44 70-71 48-49 17–18, 20–22 111 300-301 389–90 107 254 581-586 83 76-78 87-88 218-221 404 622–23 381-385 49–58 175-177 128 410-411 361–65 278ff 371-374 235-236 113 72-74 81 244–45 120-125 274–75 175–82 84 183–85, #99 95 320-386 55 95, 229 248 88 102 222-23 175 14–17 175f 216-17 274–77 20, n53; 45, n. 143 173-174 198 41–42 309-311 215 239–42 85-86 67-104 90 109 197ff, 200f 352–53 114 105-106, 387 411 - 415 76–80 431–34 514–16, doc. 290 268 - 278 87–90 409 385-389 115 202 311-313 3–7 194-195 348–50 341–47 314–15 160 148-151 65–66 334–37 1–27 218-219 173 23 182–84 460 - 465 583-585 49ב 150-53 103 263–70 78-80 112 186-88 399-408 109-113 64–67 93-94 471 463–66 91–92 162-65 117 237
blms
commented
2 years ago @richmanrachel @rlskoeser Yes, for the time being I'd left this deliberately vague so that the exact type of location could be specified in data work. But looking at it now, that would be a lot of data work. I agree with Rebecca that this makes sense as a separate feature and we can work out the particularities of the regex. Here's the full (really long!!) list of entries.
richmanrachel
commented
2 years ago @blms and @rlskoeser - I agree that this seems like too much data work. How do you feel about "See pp./document #"? The other option (but would need @gissoo's approval) is to indent the gray box slightly so that it's clearer that these numbers fall under that scholarship record.
blms
commented
2 years ago That could work! I could see it getting redundant, with entries like these:
Edition and Translation of T-S Ar.38.28 (PGPID 16248) doc. 45, p. 235
Discussion of T-S Ar.39.52 (PGPID 20988) p. 15, n.28; p. 19, n. 49
Edition and Translation of T-S Ar.41.65 (PGPID 8282) p. 279, document 61
But redundancy is definitely better than missing info.
Either way, I'm also inclined to automate some data work with a data migration, just to standardize all the existing data so that they are more consistent with each other. But maybe that's still going to be too much. We can also make a note in the admin panel to show where this will be displayed and the expected format.
richmanrachel
commented
2 years ago @blms - I agree that the redundancy is better for now, maybe even especially where both pages and doc #'s are listed.
Perhaps for a bigger standardization we'll have to separate location into two categories (which is fine by me).
rlskoeser
commented
2 years ago @blms data migration makes sense to me! I'd forgotten some of the locations already include pp. indicators. That way we could improve it in an automated pass, but then the team could refine it.
fwiw, I think this is close to the regex we need:
^\d+[-–\bf,\s]?
(one more digits, followed by a dash, word boundary, whitespace, or the character f)
I can't figure out how to exclude the hebrew document indicator in the same regex, but we could exclude those in a separate pass; I think this is the character range we need (?![\u0590-\u05fe])
rlskoeser
commented
2 years ago I don't love the redundancy option because we'll have to undo it later. @richmanrachel are you comfortable with a simple data migration to add pp. to locations that start out numeric? We can track that as a separate issue.
richmanrachel
commented
2 years ago @rlskoeser - sure! I trust you :)
rlskoeser
commented
2 years ago @richmanrachel ok! new issue created. And I basically already know how to do it. Are we ready to close this one?
richmanrachel
commented
2 years ago Yep! Thanks!
Testing notes
To test, visit any scholarship records page, such as https://test-geniza.cdh.princeton.edu/en/documents/9469/scholarship/
Dev notes
Currently, the footnote "location" (typically a specific page range or document number in a source) is only visible on the Document Detail View page. In our 12/02 meeting, we decided that this should also be visible in the Scholarship Record view, reworking this "includes" section:
such that instead of "includes," the header would read, "see [pages #-## or doc #] for:".