The feature request is simple to state: provide a programable/scriptable interface to Logos Desktop. Example programming language are Python, Lua.
Has this ever been suggested before? And if so what’s the reception on this and Logos/Faithlife’s view on the matter?
One can formulate a formal proposal but we’re not yet there. Just name a few advantages and reasons:
- some routine stuffs can be done more effectively with a program. e.g.
- Let’s say from Wayback Machine I find the old listing of Logos 4 (LE) and want to create a custom collection on it, it is very tedious to drag and drop hundreds of resources to create a collection, but with scripting it is much faster and scalable (to any given list once data cleaned up.)
- grab definitions from https://wiki.logos.com/Canonical_Commentary_Collections and loop through them to create 100s of collections.
- write a script to get ratings from <bestcommentaries.com>, then add them as 5 star scale ratings in logos, updated routinely.
- listing out some information that is not shown through the software, e.g. in that list subjects such as O.T.Leviticus, O.T.Pentateuch exists but clicking on info panel doesn’t show this.
- to cook up some functionality not yet exist in Logos. e.g. there aren’t a tool to merge a few notebooks into one. But with a proper API one can again create a notebook consists of contents of the others easy.
- enabling data analysis using datasets available in Logos. e.g.
- I used to do stuffs like this manually a decade ago: counting no. of verses per book/testament/bible and doing statistics on it (e.g. total no. of original words, average no. of words per chapter, longest book by chapter/verse/words/etc.) These can be done easily, and repeated (say with a new resource or new update) if such API exists.
- e.g. one can analyze the graph of cross references between the resources and use that partly to determine a popularity of a resource and rates accordingly. (this depends on the no. of resources one has, so one could even think that’s a web API that Logos' server answering queries of stuffs like this, having access to the metadata of the whole Logos library. And this paid by hours of access like AWS.)
- This can enable some other form of research not often done yet. e.g. my advisor in the old days (more than a decade ago when terminology like “big data” doesn’t exist yet) had performed a research to study complexity between languages given Bible translated in those languages. With Logos' metadata one can ask similar but more advanced, correct questions: e.g. using the reverse interlinear datasets, one can construct matrices of “semantic clusters” between the original language and the translated language, and from this one can infer the complexity of the resulted translation, comparing to the original language. This is interesting to know, and can be used as some sort of index for Bible translations in terms of formal vs. dynamic correspondence.
- allowing one to combine tools from programming and Logos' dataset to perform unique kind of research. e.g. using natural language processing from a library together with Logos' datasets/internal resources.
- plugins can be written by the community to enhance Logos in various ways. e.g. one can imagine the automation on creations of PBBs, even not from docx by chaining tools such as pandoc.
- allow one to create resources that aren’t supported by PBB. Examples such as a interlinear / reverse interlinear Bible. I know a very old brother who has a database of that (in Chinese), which has been completed years ago. He insisted it should be given away for free. He hired a programmer to create a Bible software to show that interlinear tool (somewhat similar to Interlinear Scripture Analyzer in what it does.) But the programmer was too expensive, and left, and he’s left with a software only works in Windows XP and no documentation so no one to follow up to improve upon. I think he has talked with Bob years ago (who told him it took at least a million for create such software, sort of discouraging him to do so.) I asked Bob a decade ago if PBB would support the creation of interlinear / release interlinear and he answered yes but that feature never materialized yet. Even if that feature in PBB exist, it would be very tedious to convert a database into the Word format PBB required. It would be much easier if Logos instead open up the internals of generating a Logos resource through an API. This will democratize the creation of resources and Bible software (since now one don’t have to create their own in order to give away for free. Instead direct people to download free Logos engine, provide the resource for free as a file.) One can even create this resource and donate to Logos to give away for free (because without a way to create this on our own, Logos won’t invest his staffs' time to create it and give away.)
Out of the many reasons that one might want to reject this idea, I’ll only start to reply to this most important one I can think of: this would be extra work for Logos/Faithlife to provide such a feature for such a niche audience. The investment is not worth it. Now the counterpoint to this:
- Logos' employees has to have ways to touch the internals for various reasons. Such API, which might already exist in various forms for their internal use to debug stuffs, can be refactored to allow part of them to be public facing. Such release is only going to make their employees' experience so much better (because for something to be ready to the general public, it has to pass some sort of user-friendliness test). Such improvements would increase the productivities of their employees, and lower the cost to train new ones. (Ok, this is just my opportunistic guess.)
- capability to program was for the few elites but becomes part of the standard curriculum. i.e. the new generations (including mine to some extents) will all know programming as part of their common knowledge, just as Math, etc. For those it is incredibly time wasting to manually clicking dozens times when they know repetitive tasks should always be scripted and automated. i.e. this feature which might seem to be for niche can becomes the mainstream for the next generations. And Logos can again lead in innovations in this aspect. (More example: when I was undergraduate more than a decade ago, one can get a degree in Physics and Mathematics without programming knowledge at all. For now, not that it’s impossible, but it becomes very common for an undergraduate at least know Python to perform some simulations. Some University even choose to teach Introductory Physics with programming embedded in their course such that they can visualize the simulation of their theoretical equations and know how it translate into complex dynamics.)
- allow rapid prototyping some ideas. e.g. those wheels in Bible study, can be coded up easily given the access of APIs. Again this can benefits Logos internally, and also potentially some creative ideas from the community can becomes a feature in next version of Logos.
- not uncommon for softwares to provide a scriptable interface. e.g. macros in MS Office. Lua and/or Javascript scripting support in Adobe Lightroom, Photoshop, etc.
Regarding the programming language of choice, I would suggest providing a Python binding, allowing people to install it in their own environments such that they can use them with other libraries such as nltk, pandas, numpy, seaborn, etc.
Note that Python can be used as an embedded interpreter within Logos too, this is more self-contained for simple scripting but is inferior because one can’t use other than standard library. Also Lua is also a common choice as an embedded scripting language but I think it is too lightweight for doing anything really powerful together with Logos.
