SUGGESTION: Plea for priotitzation relief

I have some basic principles of prioritization:

I want links in a Bible translation to go to that translation not my preferred Bible
I want links in a Commentary to go to the Bible translations(s) on which they are commenting
I want links in monographs to go to the Bible translations(s) they are using

If you do the math, you can figure out why I never get Logos set up correctly.. Things that could help - overlapping possibilities:

if Bible referring to itself was a settable program feature ... no additional metadata needed
if the translations used by commentaries was copied from the copyright page into metadata and using that metadata as the default priority was a setting
letting user manually enter preferences into metadata so it was easier to keep track of what was and was not done - which would decrease the number of steps to set a priority.
allowing the current method to assign priorities to series and collections which would provide much of the advantages of metadata with minimal disruption to the current implementation.
instead of a Christmas sale, allow the users to describe what prioritization scheme they really want and on Christmas the Logos elves deliver them as a download ... okay space, time and training probably kills this idea
instead of a Christmas sale give the users option 4 above as the "free pickle" mentioned in another thread.

Find more posts tagged with

Comments

Mark Barnes

Your prioritizing can be done manually at the moment, it would just take some time. But if you just added Bibles with advanced prioritization as you consulted them, it would only take a few seconds each time.

Assigning priorities from a series, in additional to from a single resource would be a positive step, and would be relatively easy to code. Unfortunately, I don't think it likely that we'll ever be able to do it from collections given their dynamic data. Collections have the potential to change to often to allow them to be used for prioritization. You couldn't recalculate and rewrite the keylinking table every time there was a metadata update or a resource was tagged.

MJ. Smith

https://community.logos.com/discussion/comment/426441#Comment_426441

Your prioritizing can be done manually at the moment, it would just take some time.

Lots of time as I have found ... including time figuring out where I left off in a series as the display for advanced setting is spaced consuming. Not to mention that for my medium sized library this works out to about 2,500 entries - not including the standard defaults.

You couldn't recalculate and rewrite the keylinking table every time there was a metadata update or a resource was tagged.

I'd think one would only have to recalculate deltas if one goes the keylink table route. One could also take translation priorities to be a property of a resource plus a generic default priority. It's a balancing of generalization level vs. performance.

Mark Barnes

https://community.logos.com/discussion/comment/426728#Comment_426728

I'd think one would only have to recalculate deltas if one goes the keylink table route

The way that Logos does it at the moment is that your prioritisation rules are translated into two keylink tables (one for data types, one for headwords). Each resource you own has at least one entry, and some resources have multiple entries (if they have multiple datatypes or support multiple languages). Each entry has a rank, which is set according to the prioritisation order. In my case, the keylink table has 12,694 rows. When Logos needs prioritisiation, it does something like SELECT * FROM DataTypeMilestoneIndexes WHERE DataType="xxx" ORDER BY Rank, which in most cases will return only a handful of rows (except for Bible datatypes and Plutarch, if you have Perseus).

Anyway, the point is that at the moment, when you change your prioritisation, this entire database needs to be recreated. Any other system would probably require very significant architecture changes.

MJ. Smith

https://community.logos.com/discussion/comment/426756#Comment_426756

Any other system would probably require very significant architecture changes.

Quite true ... which tells me something about their initial analysis.