-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[book] indicate l. if only lines differ #284
Comments
Ordering the abbreviations by number of references there are:
I'd suggest to concentrate on the most common abbreviations to figure out what the predominant patterns are. Initial results for IGLS show that majority of entries matching
|
As a preparatory step I extended our xml template to store the line number explicitly declare namespace tei="http://www.tei-c.org/ns/1.0";
for $bibl in collection('/db/apps/lgpn-data/data/persons')//tei:bibl[not(@type='volume')][not(tei:note[@type='line'])]
let $add := <note xmlns="http://www.tei-c.org/ns/1.0" type="line"/>
return
update insert $add following $bibl/tei:ref and adjusted the input form accordingly; please note that the Linking field has been moved up and now is placed in the same row with Line |
@michaelzellmann I have prepared a conversion list, in the first instance tackling just most popular entries with simple cases that just ends with |
Many thanks, Magdalena, the three lists look ok to me. Should I be able to see anything by clicking on the links at right? Right now I see only this error:
[cid:A84A17A2-1A1C-4F76-A010-797F0D60670C]
On Apr 22, 2020, at 12:13 PM, Magdalena Turska <[email protected]<mailto:[email protected]>> wrote:
@michaelzellmann<https://github.com/michaelzellmann> I have prepared a conversion list, in the first instance tackling just most popular entries with simple cases that just ends with , number pattern. If you could have a glance at the conversion suggestions below if they look reasonable and let me know
IGLS<http://clas-lgpn4.classics.ox.ac.uk:8080/exist/apps/lgpn-editor/modules/tools/biblLines.xq?bibl=IGLS>
SEG<http://clas-lgpn4.classics.ox.ac.uk:8080/exist/apps/lgpn-editor/modules/tools/biblLines.xq?bibl=SEG>
IG<http://clas-lgpn4.classics.ox.ac.uk:8080/exist/apps/lgpn-editor/modules/tools/biblLines.xq?bibl=IG>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#284 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AE55QHEFFZLNXIPUSXF6A7LRN3GN5ANCNFSM4LEEUEGA>.
|
Thanks, I've fixed the link so it leads to the person input form. I will run the conversion now for IGLS, SEG and IG and attach the logs here. |
After running the conversion other cases containing comma but not matching the pattern of final comma and number
Could you please confirm if following handling is appropriate
|
|
IG very few remaining cases like IG XI (4) 772, 3, 15 (same as SEG case 2) and the rest could be handled manually |
Please see below for answers between lines
On Apr 22, 2020, at 1:58 PM, Magdalena Turska <[email protected]<mailto:[email protected]>> wrote:
After running the conversion other cases containing comma but not matching the pattern of final comma and number
SEG<http://clas-lgpn4.classics.ox.ac.uk:8080/exist/apps/lgpn-editor/modules/bibl-lines.xq?bibl=SEG>
1. SEG XLVIII 1868, [1] Μαρώνις (comma and [number])
2. SEG XLI 1530, 8, 75 Ζώη (multiple commas)
3. SEG LV 1053 A, 9; B, 15 Οὐεττινιανός
4. SEG XLIII 1026B, D Μαρῖνος
Could you please confirm if following handling is appropriate
1. treat number in [] as a line number -> l. [1]
Correct
1. treat final comma-separated numbers as line number -> l. 8, 75
Correct
1. split into two bibl. entries? LV 1053 A l. 9 and LV 1053 B l. 15
Correct
1. leave as is, I suspect B and D are not line numbers?
Correct, B and D are part of the “details” and not the line number
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#284 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AE55QHAUGYNFRA2JMIQK66TRN3SXVANCNFSM4LEEUEGA>.
|
Correct, thanks. I am still working through your list of the Yes / Maybe / No entries.
On Apr 24, 2020, at 11:56 AM, Magdalena Turska <[email protected]<mailto:[email protected]>> wrote:
As we're slowly converting database entries, I'm now working on the LaTeX generating scripts
Here's a test case for Γέμελλα, in Heliopolis we should have
(2) IGLS vi 2751, 3
(3) ib. l.4
Original bibl. entry for (3) is IGLS vi 2751, 4
[image]<https://user-images.githubusercontent.com/449468/80205340-bb755a00-862a-11ea-80e9-205333040d47.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#284 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AE55QHH772JVE33VSX4Y4BTROFV6JANCNFSM4LEEUEGA>.
|
Might be worth checking with Richard but I believe there should be a space after l., i.e. here “ib. l. 4"
|
Thanks to Michael's list I could convert further entries matching the final comma-number pattern
Here are counts of entries for each abbreviations that have line filled currently:
|
After converting the single comma-number pattern matches for selected abbreviations yesterday, today I've prepared the conversion for patterns where there are multiple comma-separated numbers at the end and/or some numbers are in brackets (cases 1 and 2 as discussed here) I've run the would-be conversion (generating new values but without applying) for a handful of most common abbreviations Looking at these results, I'd suggest to
There are no matches for other most common abbreviations: "ChLA", "RE", "Meimaris_Chronological_Systems", "FRA", "SchiefferACOIndexProsopogr", "DCB", "IPalTertia", "PLRE", "Justi", "IMoab", "PIR2" |
Thanks, this looks ok for 1. Definitely not “J” in 2. as that is a literary text, it has no line numbers. PDura and PNess will be mostly long strings with many line numbers separated by commas, which can be done manually if not automated.
On Apr 29, 2020, at 12:19 PM, Magdalena Turska <[email protected]<mailto:[email protected]>> wrote:
After converting the single comma-number pattern matches for selected abbreviations yesterday, today I've prepared the conversion for patterns where there are multiple comma-separated numbers at the end and/or some numbers are in brackets (cases 1 and 2 as discussed here<#284 (comment)>)
I've run the would-be conversion (generating new values but without applying) for a handful of most common abbreviations
biblLines.pdf<https://github.com/eXistSolutions/LGPN/files/4551310/biblLines.pdf>
Looking at these results, I'd suggest to
1. go ahead applying this pattern for "IGLS", "SEG", "CIIP", "IG", "TEAD", "ISyrie", "IMnBeyrouth", "AAES"
2. but refrain doing so on "PDura", "PNess", "J"
There are no matches for other most common abbreviations: "ChLA", "RE", "Meimaris_Chronological_Systems", "FRA", "SchiefferACOIndexProsopogr", "DCB", "IPalTertia", "PLRE", "Justi", "IMoab", "PIR2"
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#284 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AE55QHCUPNS7TCMTPTYBPELRPAEMNANCNFSM4LEEUEGA>.
|
Thanks for super-fast response, I will run it in the evening then (after 6pm in Oxford and after triggering backup, as usual) |
I've just ran the conversion for Current numbers for entries with line field filled
|
IGLS XXI.5 29, 1 -> IGLS XXI.5 29, 1
IGLS XXI.5 29, 2 -> ib. l. 2
The text was updated successfully, but these errors were encountered: