[ACK] BUG in parallel resources - 1 Clement / 2 Clement

I was checking the patristic parallel resources and noticed how nicely the parallel resources list was pared down to those that actually had parallels. So I decided to experiment with the ultimate parallel resources collection and found some problems.

Create a collection of all your Logos/verbum resources. It excludes most of Perseus and Vyrso.[Actually one gets the same erroneous results from an all patristics collection]
Choose a text - I chose ii Clement 1 in Lake as a starting point.
Go down the list of parallel resources testing. I have marked items that open to the home page or incorrect location with arrows and given resource information below.

Jackson, George A. The Apostolic Fathers and the Apologists of the Second Century. Edited by George P. Fisher. Early Christian Literature Primers. New York: D. Appleton and Company, 1879.

Roberts, Alexander, James Donaldson, and A. Cleveland Coxe, eds. The Apostolic Fathers with Justin Martyr and Irenaeus. Vol. 1. The Ante-Nicene Fathers. Buffalo, NY: Christian Literature Company, 1885.

These contain1 Clement rather than 2 Clement.

Brannan, Rick. Greek Apocryphal Gospels, Fragments and Agrapha: Introductions and Translations. Bellingham, WA: Lexham Press, 2013.

Brannan, Rick. "Greek Apocryphal Gospels, Fragments and Agrapha: Texts and Transcriptions." Bellingham, WA: Lexham Press, 2013.

Penner, Ken, and Michael S. Heiser. "Old Testament Greek Pseudepigrapha with Morphology." Bellingham, WA: Lexham Press, 2008.

Find more posts tagged with

Comments

Doc B

I thought maybe you found a weevil in your spaghetti.

Mark Barnes

This has been an issue since L4 days, because accuracy was sacrificed for the sake of speed. The same problem occurs in the commentary section of the Passage Guide.

IMO, it's due to poor design of the milestone index, which is spread across thousands of files instead of contained in one file. You may remember that version 4.0 of Logos didn't even have a parallel resource menu, and clearly the index was designed before this need was realised.

Every time we have a new version, I hope they'll fix it, but I've almost given up now.

Eli Evans (Logos)

https://community.logos.com/discussion/comment/732250#Comment_732250

TL;DR: Not due to a systemic design flaw, but missing or innacurate resource metadata.

As you know, milestone indexes may contain thousands of references. In many cases, those references can be summarized broadly with just one or two references. For example, a Bible has tens of thousands of verses, but many of them can be summarized by one reference: { Gen-Rev } or two { Gen-Mal; Matt-Rev } if the apocrypha/deuterocanon are not included. We call these milestone supersets, and each resource with milestones has them. It's then very fast to compare a candidate location such as John 3:16 against the few references in the superset to see if it is covered by the resource rather than having to tediously compare them all. It's actually quite elegant, IMO.

The breakdown here: We allow content production some editorial leeway to summarize the milestones in a resource manually because it is sometimes useful to deviate. The ESV, for example, doesn't have Matthew 18:11. If we keep that one verse out of the milestone supersets, then ESV will drop out of the parallel texts on that verse, which would keep you from opening the ESV and discovering why. (You might argue that it should; other users disagree.)

Many commentaries comment on every verse except a handful here or there; some users get very annoyed when the PG Commentaries section doesn't list their favorite commentary (which they may have painstakingly included via resource priority). Let's agree that the Commentaries section hasn't been updated in a very long time, and the problems observed there could (should) be fixed in a number of ways.

I didn't check all of the resources in MJ's list, but I did check Brannan's Agrapha. The milestone superset for that resource claims that it includes 1 Clem 13.2 through Ep. Barnabas 7.11 inclusive, which correctly identifies the lower and upper boundaries of what is covered in that volume but leaves out the many gaps. That volume does include some fragments of 2 Clement, but only a few scant verses, the earliest of which is in chapter 3. (I'm sure someone thought that it would be strange to see this volume appear and disappear in various program contexts and so instead of creating a sparse superset, created an inclusive one. Or it may have been thoughtless -- but it's Rick so I doubt it. In any event, that is a judgement call that is open to critique.)

I'm not at my desk right now, but I'm going to do an experiment by updating the supersets for that resource to see if it fixes the specific problem that MJ observes. If it does, I'll recommend that we do a comprehensive programmatic review of that data and reconsider our approach that leaves this sort of decision in human hands. (As I've posted before, we're in the midst of a sort of tools and workflow audit in that area now.)

And then we won't have to re-design milestone indexes from the ground up. [;)]

Eli Evans (Logos)

https://community.logos.com/discussion/comment/732897#Comment_732897

Kyle updated the metadata for Agrapha, and that should fix this specific problem when your library catalog is next updated.

MJ. Smith

https://community.logos.com/discussion/comment/732960#Comment_732960

Thank you for the explanation and the fix. I see how the supersetting works well on fixed canons with set orders. Unfortunately these two works are often (correctly) treated very differently.

Eli Evans (Logos)

https://community.logos.com/discussion/comment/732966#Comment_732966

Right. The compiler creates ranges based on the data types (which are in a fixed order) from the resource milestones (which can be in some other order) in a fairly naive straightforward way. If the resource is in a different order than the data type, then hilarity can ensue if you don't manually correct the compiler-generated superset.

I forgot to mention that one other reason why we sometimes intentionally gloss over gaps in the resource in the reference superset is that it helps to smooth out synchronous panel linking, that is, it fixes a number of annoying bugs that used to happen when linking a Bible to a commentary with sparse milestones.

Dave Hooton

https://community.logos.com/discussion/comment/733016#Comment_733016

it fixes a number of annoying bugs that used to happen when linking a Bible to a commentary with sparse milestones.

One of my (long standing) reasons why it shouldn't be a commentary[:)] But making it type "Bible Notes" doesn't escape this issue.

Mark Barnes

https://community.logos.com/discussion/comment/732897#Comment_732897

And then we won't have to re-design milestone indexes from the ground up.

I'm not suggesting you re-design milestone indexes from the ground up. I'm suggesting you keep the existing index format, but merge all the individual indexes into one. From a design perspective this keeps everything the same, but moves the resourceID/datestamp into additional columns in the database. It would be massively more efficient, and if you've abstracted out looking up milestones/headwords (which I'm sure you have), it ought to be a relatively simple change — or at least a worthwhile change given the magnitude of performance improvement it would make possible.