[request] Bradley: Please expose the 'traits' column in collections

Very interesting, Mark.

has-reverse-interlinear doesn't distinguish those with NT only, for which I have a tag.

contains-cross-reference-footnotes would appear to answer a query recently debated!

equivalent-version:xxxx has possibilities

versified-text also has possibilities

And others which are quite useful.

https://community.logos.com/discussion/comment/491792#Comment_491792

has-reverse-interlinear doesn't distinguish those with NT only, for which I have a tag.

True, but you can combine it with supports-lbs-morph+el and supports-lbs-morph+he.

https://community.logos.com/discussion/comment/491793#Comment_491793

True, but you can combine it with supports-lbs-morph+el and supports-lbs-morph+he.

Ahh, yes!

Tim Hensler

[Y] [Y]

Perhaps, as an experiment, it might be possible for now, to just allow filtering by that field (i.e. don't change the UI if that's extra work).

By "filtering", do you mean extending the query syntax in Library and Collections to search against these values? If so, that's unfortunately not a simple change due to the way the data is stored, and the presence of embedded punctuation characters inside the trait names.

Additionally, exposing the internal, undocumented trait names directly to you is probably not the right approach. (We don't make you filter by "text.monograph.dictionary" for example.) It's also not usable by non-English-speaking customers.

I can understand the desire to be able to filter by these traits so I'll send this thread to our interaction designers to see if we can design what the "right" way to expose this data is.

https://community.logos.com/discussion/comment/491897#Comment_491897

By "filtering", do you mean extending the query syntax in Library and Collections to search against these values?

Yes, that's what I meant — to add a new library filter field called 'traits' or 'trait'.

Additionally, exposing the internal, undocumented trait names directly to you is probably not the right approach.

I know that, but I was trying to make your job easier for you [:)] by suggesting you add an undocumented feature that requires no front end changes. If we start doing useful things with it, then perhaps you could add a UI in future releases to widen its appeal.

If so, that's unfortunately not a simple change due to the way the data is stored, and the presence of embedded punctuation characters inside the trait names

I know only power users will use this, so forcing us to use quotation marks around the traits is no problem if that's what's needed (although type:bible-commentary works fine). There is a trait column in the Records table already, so it "only" requires you to convert trait:"has-reverse-interlinear" to AND Traits LIKE "%has-reverse-interlinear".

I can understand the desire to be able to filter by these traits so I'll send this thread to our interaction designers to see if we can design what the "right" way to expose this data is.

Thanks!

https://community.logos.com/discussion/comment/491921#Comment_491921

I know that, but I was trying to make your job easier for you by suggesting you add an undocumented feature that requires no front end changes. If we start doing useful things with it, then perhaps you could add a UI in future releases to widen its appeal.

Unfortunately, undocumented features have a way of becoming critical parts of customers' workflows, preventing us from ever changing them in the future. (I'm guessing you wouldn't be happy if a hypothetical Logos 5.5 took away this feature because of some unrelated internal change, and none of your traits collections worked anymore.) So we would be locked in to supporting whatever 5-minute hack we came up with today to get an undocumented feature in the hands of our power users.

I know only power users will use this, so forcing us to use quotation marks around the traits is no problem if that's what's needed (although type:bible-commentary works fine). There is a trait column in the Records table already, so it "only" requires you to convert trait:"has-reverse-interlinear" to AND Traits LIKE "%has-reverse-interlinear".

Library Catalog filtering is not implemented with SQL queries, so "unfortunately [it's] not a simple change".

https://community.logos.com/discussion/comment/491947#Comment_491947

Unfortunately, undocumented features have a way of becoming critical parts of customers' workflows, preventing us from ever changing them in the future. (I'm guessing you wouldn't be happy if a hypothetical Logos 5.5 took away this feature because of some unrelated internal change, and none of your traits collections worked anymore.)

Guilty as charged!

Library Catalog filtering is not implemented with SQL queries, so "unfortunately [it's] not a simple change".

That's a surprise, and does put a different complexion on things.

https://community.logos.com/discussion/comment/491978#Comment_491978

Bradley, my initial concern was to be able to identify the resources in the "implied collection" used by the Guide sections so I could subtract them out of my personal collections to identify similar material e.g. themes or outlines

Keep Smiling 4 Jesus :)

https://community.logos.com/discussion/comment/491897#Comment_491897

I can understand the desire to be able to filter by these traits so I'll send this thread to our interaction designers to see if we can design what the "right" way to expose this data is.

+1 [Y] for the "right" exposure. Personally have a variety of tags for morphology and interlinear.

Keep Smiling [:)]

Jon

https://community.logos.com/discussion/comment/491947#Comment_491947

Unfortunately, undocumented features have a way of becoming critical parts of customers' workflows

That is brilliant [:D]

https://community.logos.com/discussion/comment/491897#Comment_491897

I can understand the desire to be able to filter by these traits so I'll send this thread to our interaction designers to see if we can design what the "right" way to expose this data is.

Here's another real-world example of someone needing this data exposed, that's was asked in the last few days. They wanted to be able to do a morphology search of the NT and LXX simultaneously, so needed a collection for resources with the same morphology. They also wanted to know if there was a version of LXX which had root data.

https://community.logos.com/discussion/comment/492385#Comment_492385

bump for Verbum collection purposes

Anthony H

https://community.logos.com/discussion/comment/492385#Comment_492385

100% behind Marks' traits request

Tim Hensler

https://community.logos.com/discussion/comment/548438#Comment_548438

100% behind Marks' traits request

Me too, again. This would be even more helpful in light of resources tagged for specific L6 functions. Here's an example of where this could be helpful: https://community.logos.com/forums/p/98729/682010.aspx

https://community.logos.com/discussion/comment/682028#Comment_682028

Another real life example https://community.logos.com/forums/p/98590/681047.aspx#681047

Note it would also help identify guide sections that would most benefit from additions to my library.

Harry Hahne

https://community.logos.com/discussion/comment/492385#Comment_492385

Here's another real-world example of someone needing this data exposed, that's was asked in the last few days. They wanted to be able to do a morphology search of the NT and LXX simultaneously, so needed a collection for resources with the same morphology.

I want to do this type of search quite often. I believe Libronix let you do this with Serial Resource Associations. I set up the LXX and NA27 in Libronix so I could easily jump to a NT or OT verse in Greek.

I have a similar collection for searching Greek words in the LXX and GNT. I don't see any way to browse through the Greek Bible and jump from Romans to Isaiah as I did in Libronix.

A minor problem is that Logos sorts the resources in the collection by alphabetical order, so the NT appears before the LXX in the search results. Not an earth shaking problem.

https://community.logos.com/discussion/comment/682092#Comment_682092

I want to do this type of search quite often. I believe Libronix let you do this with Serial Resource Associations.

You can do this in L5/L6 with custom series. However, a resource can only be in one series. Personally, I'd put your my main Greek Bible (NA27/8?) in a series with the Lexham Hebrew Bible, and another Greek Bible (perhaps an interlinear with the interlinear lines turned off) in a series with the Septuagint.

A minor problem is that Logos sorts the resources in the collection by alphabetical order, so the NT appears before the LXX in the search results. Not an earth shaking problem.

You could, of course, rename the Greek Bible you use in your Septuagint/NT series.

Keep Smiling 4 Jesus :)

https://community.logos.com/discussion/comment/682095#Comment_682095

Personally, I'd put your my main Greek Bible (NA27/8?) in a series with the Lexham Hebrew Bible, and another Greek Bible (perhaps an interlinear with the interlinear lines turned off) in a series with the Septuagint.

Thanks, created two custom series:

2012:LHB + 2012:NA28

1909:LXX Swete + 2010:SBLGNT

Note: personally added year prefix to many Bible resources. Custom series name is a concatenation of abbreviated titles in alphabetic sort order. Logos 6 clause search currently has three choices: 2010:SBLGNT, 2012:LHB, & 1909:LXX Swete so one series has LXX and NT Greek with clausal tagging.

Keep Smiling [:)]

https://community.logos.com/discussion/comment/682127#Comment_682127

Here's another real-world example. The user wanted to know which resources where searched in the "Textual Searches" section of the BWS, and therefore also which resources where in certain system collections.

https://community.logos.com/forums/t/103750.aspx

SineNomine

https://community.logos.com/discussion/comment/718021#Comment_718021

Another real-world example is a user who wants to find resources with milestone tagging for lectionaries. Unfortunately, there's no field to show Milestone tagging, touched up or raw.

https://community.logos.com/discussion/comment/847138#Comment_847138

I might be flogging a dead horse here, but here are two more examples of customers needing this functionality:

https://community.logos.com/discussion/comment/874632#Comment_874632

I'll bring this up internally again, but one of the problems is that this metadata isn't affected by your licenses. For example, HCSB now has the "has-reverse-interlinear" trait, but only Logos Now subscribers actually have the HCSB NT reverse interlinear. It seems wrong (or at least not useful) to automatically update dynamic collections to include the HCSB if you don't actually have the reverse interlinear functionality available.

This specific problem (building a dynamic collection of reverse interlinears) may need to be handled specially, not just by indexing the traits.

https://community.logos.com/discussion/comment/874897#Comment_874897

this metadata isn't affected by your licenses

That is a complicating factor, certainly. Nonetheless, I'm convinced that power users would find traits enormously helpful in building collections.

https://community.logos.com/discussion/comment/874897#Comment_874897

It seems wrong (or at least not useful) to automatically update dynamic collections to include the HCSB if you don't actually have the reverse interlinear functionality available.

A complication - but it can be handled by wording e.g. liberal use of the word "potentially" or "conditionally". It would certainly be a step up from the current situation where we can run searches and guides without (a) knowing what we are running it against (b) knowing what should have been searched and was omitted and (c) no way of reconciling between the two. Remember I am still dealing with resources that don't recognize 1 Maccabees as a Bible reference to remind yourself how unsatisfactory the current situation is.

https://community.logos.com/discussion/comment/874897#Comment_874897

For example, HCSB now has the "has-reverse-interlinear" trait, but only Logos Now subscribers actually have the HCSB NT reverse interlinear.

Is there another trait that distinguishes which RI's are available where a resource like HCSB could have two?

It seems wrong (or at least not useful) to automatically update dynamic collections to include the HCSB if you don't actually have the reverse interlinear functionality available.

LN and the L7 Feature Sets will give you RI datasets without having the resources[:)] The nature of collections is that you won't get results from all the resources, and there are enough queries about not getting OT results from some resources that a few more about the HCSB NT would be expected! The extreme is where a user has a (Starter) library with appropriate resources but no RI datasets, but we still get queries about a lack of results in lemma searches. In short, building collections with any (dynamic) criteria can produce disappointing/unexpected search results whether it includes too many resources or otherwise.

https://community.logos.com/discussion/comment/874953#Comment_874953

Is there another trait that distinguishes which RI's are available where a resource like HCSB could have two?

You've asked that before [:)].

https://community.logos.com/discussion/comment/875033#Comment_875033

Is there another trait that distinguishes which RI's are available where a resource like HCSB could have two?

You've asked that before .

Ahh, yes (3.5 years ago)! In which case a rule like has-reverse-interlinear AND supports-lbs-morph+el is license dependent, because the supports.. trait comes from the RI datasets. A more general rule would be has-reverse-interlinear AND (supports-lbs-morph+el OR supports-lbs-morph+he).

https://community.logos.com/discussion/comment/875088#Comment_875088

Here's a question: in principle, can one add tag by writing to the db directly?

If so, this problem is solved, with the caveat that we all understand writing to db is not encouraged nor supported by Faithlife/Logos.

Sharing a collection would be more difficult, because that depends on a tag that others might not have. In this case we can release a simple command line tool to write tags from the traits, and if there's enough people doing that, those tags becomes CommunityTag then a community collection is possible.

SineNomine

https://community.logos.com/discussion/comment/1039064#Comment_1039064

Would it be possible to expose the Traits data in Beta versions only? Then you're making it accessible almost exclusively to power users who are OK with things being broken. It might sometimes help Beta testers find bugs, too.

https://community.logos.com/discussion/comment/1039064#Comment_1039064

in principle, can one add tag by writing to the db directly

No, don't modify your databases.

we all understand writing to db is not encouraged nor supported by Faithlife/Logos

Do we? [:D]

In this case we can release a simple command line tool to write tags from the traits

Please do not write or distribute a tool for other customers to corrupt their databases.

There is only one supported way to modify databases on customers' systems: https://faithlife.com/careers [:)]

https://community.logos.com/discussion/comment/1039410#Comment_1039410

Would it be possible to expose the Traits data in Beta versions only? Then you're making it accessible almost exclusively to power users who are OK with things being broken. It might sometimes help Beta testers find bugs, too.

That's not really a viable option if it's desirable for "power users" to build collections that would be shared with "regular users" (who aren't running the beta).

The hold-up here is determining how to expose traits in a way that works for all users in all locales. See my earlier replies on p1 of this thread for why we don't want to add a quick solution e.g., just for beta users.

Reuben Helmuth

https://community.logos.com/discussion/comment/1039419#Comment_1039419

The hold-up here is determining how to expose traits in a way that works for all users in all locales.

Seems to me that a facet in the library would be a decent place to start!

Fred Chapman

https://community.logos.com/discussion/comment/1039418#Comment_1039418

There is only one supported way to modify databases on customers' systems: https://faithlife.com/careers

[Y]

https://community.logos.com/discussion/comment/1039421#Comment_1039421

The hold-up here is determining how to expose traits in a way that works for all users in all locales.

Seems to me that a facet in the library would be a decent place to start!

There are thousands of different traits, the majority of which are in English. Quite a lot of them have quite 'unfriendly' names exposing them all in the UI wouldn't be helpful in my opinion.

That said, if the problem of subjects can be solved in the various locales, I don't see why traits can't be treated in the same way. I don't think it matters if someone in the German UI has to enter merkmal:supports-bible, rather than merkmal:unterstützt-Bibel.

https://community.logos.com/discussion/comment/1039418#Comment_1039418

No, don't modify your databases.

Are you saying that’s not how the tag are stored, or are you just discouraging writing the db? i.e. is it “physically impossible” or just “please don’t while possible”?

Do we? Big Smile

Ok, may be some don’t. But it is a common sense among many free and/or open-source softwares. e.g. MIT license:

THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

While this warning is against the use of the open-source software, similar warnings can be applied to the db that it's modifying. And these kinds of warning is often not light. The one who hit the button to perform whatever is the one responsible for anything. They are on their own.

There is only one supported way to modify databases on customers' systems: https://faithlife.com/careers Smile

That's very limiting because not everyone has the luxury of becoming a Faithlife employee, nor might they want to have a career there. The better middle ground will be e.g. embedding a full programming language (lua is the common choice, while I like Python more) so that the amount of damage can be minimized/controlled. Example is Adobe's Lightroom which has a catalog also in SQLite database while they provide an embedding lua interpreter for scripting and plugins. A whole Lightroom plugin community exists, and there are some for fee plugins as well that people sell. These plugins often provide functionality that end users might need while Adobe didn't provided yet, and might even eventually provide later. The existence of plugins there liberates one to not have to stick to whatever tools/workflows that Adobe provided. For some softwares, e.g. Microsoft Office, Logos, there's a paradigm on workflows, that either it fits the users well or annoyed them to their gut, without a way to not to be conformed into their mentality. A plugin will change that to some extent. In the case of Adobe Lightroom, most of the stuffs can be done through Lightroom plugin through lua. There are exceptions, but better than not having that option at all. Back to modifying db, it's not as scary as it seems. Perhaps the easiest way to safely perform trial and error is to set up a VM, disconnect its internet, snapshot the image, modify, restore to the snapshot and repeat.

Just to brainstorm, may be release a Logos Developer Edition that comes with no warranty and CS, etc., with quarantined cloud interactions, etc.

I think the point is to differentiate the expectation from Logos between 2 kinds of usage patterns. One is fully supported, with custom service, phone call, online chat, even remote control, etc. Another is just, you know, RTFM where F stands for Faithlife.

Andrew Batishko

https://community.logos.com/discussion/comment/1039545#Comment_1039545

he better middle ground will be e.g. embedding a full programming language

may be release a Logos Developer Edition that comes with no warranty and CS, etc., with quarantined cloud interactions, etc.

Neither of these things is going to happen in the foreseeable future.

Bradley is trying to tell you that modifying your databases has the potential to be a spectacularly bad idea. We could subtly change the format or usages of that data at any time.Your tool which used to work now may be writing bad data that gets synced up to our servers, leaving you with corrupted data that could prevent your use of the software, and which can't be fixed, because the corrupted data will always try to download to your application. In this event, you are not likely be receiving much (or any) support for fixing things, given the explicit warnings not to make such changes.

I don't know how to state this any more plainly that Bradley did.

don't modify your databases.

https://community.logos.com/discussion/comment/1039545#Comment_1039545

But it is a common sense among many free and/or open-source softwares.

Kolen, there are a number of people in the forums who have the skills necessary to update databases, extract data etc. in the ways you insist is necessary. May I suggest that you consider why people with first-rate skills and decades of experience, chose not to follow your suggested path and have not jumped in to support your requests?

I think the point is to differentiate the expectation from Logos between 2 kinds of usage patterns.

As with most purchased, licensed software Faithlife has made the distinction - choosing to support only the first category.

https://community.logos.com/discussion/comment/1039552#Comment_1039552

leaving you with corrupted data that could prevent your use of the software, and which can't be fixed, because the corrupted data will always try to download to your application. In this event, you are not likely be receiving much (or any) support for fixing things, given the explicit warnings not to make such changes.

In this imaginary scenario, while I don't expect you guys can recover my database in the cloud, can't you just reset my data so that I can start over? Are you saying you guys will refuse to even reset the database (which related to my documents, metadata etc. but keeping all my licensed resources)?

IANAL, but it seems illegal to not support that (simply resetting the data, not recovering it). e.g. Apple tried to provide no support/warranty to people fixing their own batteries (or 3rd party unauthorized sellers fixed them), they lost the lawsuit and they have to support that scenario. (And even jailbreak isn't made illegal even if Apple want it to.)

don't modify your databases.

The more you guys say it, the more I want to. Have you ever play the "never think about a black elephant" trick? Joke aside, statement like that are challenging the customers/users' wit thinking they are not adequate to do the right job.

Using an analogy about cars. Some people buy a car, whenever they needs servicing, they take it to the original manufacturer's service center. Some others, they fix it themselves because they want to save money and/or they want to understand their car and think they will do a better job at servicing it (just because its their own car so they will pay more attention rather than time limited.) Some might take it apart and modifies things just because they can and enjoy. Some morons might get themselves killed by doing it themselves.

All these scenarios are possible and supported (e.g. the user manual in principle has everything you need to service your own car.) Dangers can happen, but they themselves are mostly responsible for that (well if the car manufacturer put a bomb there in case anyone open it up then of course the manufacturer is responsible.)

So what I'm saying is that things like that are bound to happen. If a supported way is provided, great and much appreciated. But if not, some people are going to do it anyway, albeit not as efficient nor safe. The economy of that is determined by time. e.g. if something laborious required one do spent 15 min. clicking, etc. to get done, they aren't going to spent 15 days to reverse engineer / understand a certain feature/spec/etc. But if something gets too big to be handled manually, either they gave up or they might spend time starting to do just that.

For example, one of the thing I want to do requiring the knowledge of the spec of logo4/etc. resources is personal book with interlinear. The supported way would be providing a PBB with interlinear feature, unsupported way might be understanding the spec of logos/lsbpbb/ls.... and see if there's anyway to provide a file with the same spec while making sure Logos won't think I don't have a license to read that. The later is very difficult, while the first doesn't exist and don't seem to be ever supported, making the later the only way.

May be someone has already been doing it, just that they don't say it in forum because they know it is discouraged here.

(P.S. I can almost hear someone saying "There is only one supported way to write to Logos resource format: https://faithlife.com/careers". I hope that's not true and everyone can "self-publish" to Logos format, even interlinear!)

https://community.logos.com/discussion/comment/1039567#Comment_1039567

But it is a common sense among many free and/or open-source softwares.

Kolen, there are a number of people in the forums who have the skills necessary to update databases, extract data etc. in the ways you insist is necessary. May I suggest that you consider why people with first-rate skills and decades of experience, chose not to follow your suggested path and have not jumped in to support your requests?

The response to the quote is taking it out of context. What was the original quote about?

Edit: hints: the quote was replying to another quote "Do we?", and now what that was referring to then?

https://community.logos.com/discussion/comment/1039567#Comment_1039567

As with most purchased, licensed software Faithlife has made the distinction - choosing to support only the first category.

That exactly is the root of the problem. It makes any thing that cannot be supported to the "lay-est" layperson not supported at all. See my car analogy above (that probably written after your reply.)

https://community.logos.com/discussion/comment/1039568#Comment_1039568

can't you just reset my data so that I can start over?

And how does this trickle through the shared data? No, one cannot simply reset data back to your initial state ... it must back you out of all shared data and statistics.Backing out corrupted data is not trivial.

https://community.logos.com/discussion/comment/1039571#Comment_1039571

That exactly is the root of the problem.

Having spent a career in IT with a brother a research engineer for Techronic, a son-in-law and grandson in IT, I see it a bit differently. I suspect you don't have sufficient experience to understand why your approach is generally avoided except in very specific applications. For example, on my machine you would find very open-source applications for (a) running model simulations for a particular class of models and (b) for constructing the most compact chart of entity-by-attribution differentiation concept chart. Open source works here because all installations are completely independent, input and customization have an appropriate granularity and creator contact information, and no one would run into the applications or understand their documentation if they were not seriously into model theory. For Logos, the various installations have different levels of integration, the application does not fit into neat granularity, and the intent is for people of all levels of knowledge to be able to use the application. But I'm bowing out of your discussions as I don't see it as a effective use of my time.

https://community.logos.com/discussion/comment/1039572#Comment_1039572

it must back you out of all shared data and statistics.Backing out corrupted data is not trivial.

I don't care if they need to wipe my existence in the cloud database as long as I got to keep my licenses to my resources (i.e. the books, etc.) I don't keep much data in Logos anyway except when there's no choice (i.e. collections, tags, priorities, highlights, etc.) Yes it would be very inconvenient to start even only these over, but I can accept the consequence of this in case I "killed myself" in the experiment.

Since you don't represent Faithlife, I won't read too much into the technical side. (Along the lines of what you said almost suggested a vulnerability in their design that can result in an attack to their server database.) What I want to hear is from Faithlife if they at least support "wiping me clean while preserving my licenses."

https://community.logos.com/discussion/comment/1039574#Comment_1039574

But I'm bowing out of your discussions as I don't see it as a effective use of my time.

Best of your move yet, because, you know, you have a tendency to turn everything into an argument. [;)]

Keep Smiling 4 Jesus :)

https://community.logos.com/discussion/comment/1039568#Comment_1039568

For example, one of the thing I want to do requiring the knowledge of the spec of logo4/etc. resources is personal book with interlinear.

Curious what Reverse Interlinear(s) are desired ?

In this imaginary scenario, while I don't expect you guys can recover my database in the cloud, can't you just reset my data so that I can start over?

A start over possibility (completely loses your notes/highlights, documents, reading progress, collections, tags, priorities, ...):

Create new Faithlife account with new email
Pay $ 20 to Faithlife for transfer of all Library resource licenses from old account to new account
Have Faithlife disable (lock) old account

FYI: this start over also loses your order history.

Using an analogy about cars.

Cars lack complexity of data synchronization with servers (and other devices), which has a number of nuances. Spectacular data corruption could cause your Faithlife account not to be usable on any device (desktop and mobile), which would be a synchronized mess.

Keep Smiling [:)]

https://community.logos.com/discussion/comment/1039581#Comment_1039581

Please don't hijack this thread, which is about encouraging Faithlife to find a way to expose the 'traits' data within Logos Bible Software. Please start another thread if you want to talk about different things.

https://community.logos.com/discussion/comment/1039581#Comment_1039581

Curious what Reverse Interlinear(s) are desired ?

There are 2 Chinese Bible databases I knew about, from 2 old brothers. One is published somewhere else already, another is something of his lifetime work, but because of his insistence of publishing them freely, it is still hasn't been release. (For now let's focused on this later brother.) His has spent a small fortune hiring a Jewish person (interesting combination of gentile hiring Hebrews) building a half-finished Bible software, and unfortunately the state is so broken and that Jewish guy has found another job, with no documentation whatsoever, he has to give that up. Apparently he might have met Bob and in their conservation it seems Bob has told him in order to build a Bible software one need a million dollar (from verbal dialog so IRRC.) About a decade ago I asked Bob and he said that a reverse interlinear feature will be available soon on PBB. But as usual that hasn't been released (I don't blame them too much, it is easy to promise first until they found a ton of technical issues making it economically infeasible to deliver a working feature.) Recently I have a casual dialog with a Faithlife employee and he said they have no interests in releasing these 2 Chinese Bibles.

So the problem is, in order to enter the Logos ecosystem, one needs the sanction from Logos to be produced by them (often just business decision.) Or you publish via PBB giving people instruction to obtain Logos for free and compile their PBB. BUT, that doesn't work for reverse interlinear title. That makes indie Bible publishing in Logos very hard. (Just to make sure you don't get that wrong, indie here doesn't mean low quality. They are reputable among Chinese Christian circles. But, you know, how much quality Chinese Christian works are there, and how much of them are deemed valuable in the whole "Christian" world where the English / translated-in-English titles are the best? There ain't much good non-indie Chinese Bible anyway, and the 2 brothers I am referring to are pioneers among Chinese Christians to even have Strong number referencing in the Chinese Bible (the later brother's earlier work was together with another now-passed-away brother to produce the first Chinese NT Bible (CUV) with Strong numbers and concordance.).)

Another obvious use of reverse interlinear in PBB is personal Bible translation. I'm sure most people here has done it as an exercise. But as personal books one wrote should be compiled in Logos to use personally (I have a few Bible commentaries compiled and used personally only.) So why not also their own Bible translation, to not let their own notes/works wasted, but at least be their own resources (or even shared)?

Sadly, reverse interlinear in PBB has been requested repeatedly, but it seems at last there's an official statement from a Faithlife/Logos staff stating this feature won't be released.

That's not the end of the world. The first brother I mentioned released his work in a Chinese Bible software which I have bought a copy, but is next to unusable (a few clicks and it crashes!) He also released a web version which is much better (and free! I wish I hasn't purchased that Bible software.) Lately it is also released for free in another mobile app.

It is just very sad Logos-only users cannot make these resources available in the Logos ecosystem. Not only for personal use, but also as a promotion to others who might interested in this resource to start using Logos. It might be hard to imagine, but in my circle, I'm the only one using Logos and I want to change that. (And I've met quite a few different Chinese Christians from different churches. None of those I know uses Logos. I successfully referred to 1 friend to buy Logos though, when Logos still offer referral promotion where the friend get ~25% off discounts and I get like $25.)

Cars lack complexity of data synchronization with servers

Sadly analogy is never exact. I'm more referring to the desire to DIY. And that's (referring to what you said about cloud's complexity) why I hate the whole cloud thing in general. It takes away the control from the user. Worst kind of cloud is "magical cloud" where it try to be "just works" a.k.a. magical. As I often said, "When it works, it's magic; when it doesn't work, it's magic!" The better kind of cloud is something like Dropbox that gives you version control. i.e. it tries its best, but knows disasters might happen and give you a way to undo. And since the data (files) are transparent to users and nothing but a directory structure, one can always backup and restore. (Many apps relies on Dropbox for cloud sync benefits from the same safety. That's why mobile app cloud sync, whenever involving using a 3rd party cloud service, almost always provides Dropbox first if not the only sync solution. I'm not saying it's the best though.)

Thanks for your constructive input (especially on the worst case scenario to pay $20.) I'm smiling. [:)]

P.S. I'd really like to know if such disastrous situation can really happen, namely, a corrupted database, pushed to the cloud, sync everywhere, undoable disaster. I wonder if it is just Faithlife/Logos' tactics to discourage users to not do this, worrying in the end they are the one who need to fix the mess and took the blame. It is because (if it can be that disastrous,) it just seems to be a very fragile implementation, without validation, and without "snapshots". It seems to me either they don't implement it very well, or they're bluffing. Of course I won't know the answer here (unless one becomes a Faithlife employee and peek at the code!) But in principle there's an easy test here, just use a testing account to try one's best to corrupt the database and see what happens. (Everyone should knows that this is strongly discouraged however. But I'm a Theoretical Scientist meaning I focus on what can be tested in theory, not that one has to perform that experiment. i.e. this is a case that is falsifiable.)

https://community.logos.com/discussion/comment/1039608#Comment_1039608

Please don't hijack this thread, which is about encouraging Faithlife to find a way to expose the 'traits' data within Logos Bible Software. Please start another thread if you want to talk about different things.

I don't know if you include my theoretical solution to this (by writing traits to db as tags and working from there.) But I genuinely believe this is a possible theoretical solution. To recap I focus on if things are possible or not first. (That's why I started that question with "in principle".) You know, for theorists, theoretically possible means the problem is solved (i.e. logically.) Whether one want to start implementing the theory into an actual experiment is a separate matter.

Sadly, people keep digressing in a db-writing-phobia without really answering if in principle it can be done or not.

And then there's also a now vs future problem. Yes, they said they will expose it. But when? And even before asking that, will it really happens? As the example I've given a few times (the PBB interlinear feature promised by Bob himself and later cancelled), I don't trust their promise until it arrives. Before that happens, one should really ask how a certain goal can be achieved right now, even if there's no help from Faithlife/Logos whatsoever.

Also in case someone might think what I said isn't about "exposing" the traits. Recall my first post on this I did mention if one can get enough people to do this simultaneously such that it can be considered a community tag, then it is a kind of exposure. Yes I know Faithlife/Logos discourages that, so it is difficult to get a lot of people doing just that. But in principle, it works.