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

Hi Bradley,

I've been doing some digging in catalog.db and realised that the Traits column of the Records table contains some very useful information that power users would like to use when creating collections. For example, the data in the traits column would allow us to create collections of:

All our reverse interlinears
All the morphologically tagged resources (which a specific morphology)
All the resources used in the Illustrations section of the SSG.
All the resources that have spoken audio

I'm sure we could find other uses, once we had time to play around with the data.

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). If people found it useful, it could then be added to the UI later.

For people who are interested, I've posted a list of traits to the Wiki. It only includes traits supported by resources in my library, so it's not complete: http://wiki.logos.com/Traits

Find more posts tagged with

Comments

Dave Hooton

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.

Mark Barnes

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.

Dave Hooton

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

Ahh, yes!

Tim Hensler

[Y] [Y]

Bradley Grainger (Logos)

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.

Mark Barnes

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!

Bradley Grainger (Logos)

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".

Mark Barnes

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.

Keep Smiling 4 Jesus :)

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

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

That is brilliant [:D]

Mark Barnes

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.

MJ. Smith

bump for Verbum collection purposes

Anthony H

100% behind Marks' traits request

Tim Hensler

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

Harry Hahne

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.

Mark Barnes

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 :)

For example, the data in the traits column would allow us to create collections of:

All our reverse interlinears

All the morphologically tagged resources (which a specific morphology)

All the resources used in the Illustrations section of the SSG.

All the resources that have spoken audio

Dreaming of a Faithlife supported exposure for interlinear(s):

Interlinear
Reverse
Bible Book range

An interlinear change since this thread began 5 years ago is Logos 8 Basic including free access to many Reverse Interlinear resources.

Also would appreciate a column showing Morphological tagging in resource that ideally matches Morph Search choices. One change since this thread began is the removal of one Greek Morphology (transitioned to Logos Greek Morphology). Work around for personal tagging is searching all resources for word(s) that frequently occur: e.g. the definite article.

Like idea of a Library column that shows which resource(s) have their own audio recording (while dreaming of a Hebrew Bible Read Aloud for Lexham Hebrew Morphology)

Keep Smiling [:)]

SineNomine

Like idea of a Library column that shows which resource(s) have their own audio recording

That would be great!

Kolen Cheung

I uses the trait from the resource metadata API to create search query string by title search. The collection rules are dumped in https://github.com/logos-extras/logos-meta-dump.

From collection_rules_all.yml I created a bunch of example public collections started with “Collection—”

And from collection_rules_traits.yml I created a bunch of example public collections started with “Trait—”, which is of interest in this thread. Examples are:

Collection Nested—Audio
Trait—media-type:audio
Trait—audio-target
Trait—audio-source
Trait—has-reverse-interlinear

Note that it is not perfect because it is limited by the features Logos currently offered and specifically uses a title search. E.g. ‘Trait—has-reverse-interlinear’ includes “中文聖經和合本修訂版（上帝版．繁體）” for example, although its reverse interlinear feature is still in pre-pub. Not to mention some license that one might not own while owning a title with that name (e.g. one might not own the reverse interlinear license or an audio license.)

Moreover, title search has some bug (in another thread) and not exact (e.g. different resource of the same title, or one has a longer title including the other might be included as well.)

But right now, it is the best way one can create collection rules based on trait. For example, if you want to have an OR match on different traits, you can create 3 collections with those trait individually and then apply an OR-collection search, as an example in “Collection Nested—Audio” above.

Also note that the performance is not great since it is not performing an exact search. But again it is the only way given the current feature available right now. If you own cared resources you own, then you can "collapse" that search by performing a library search and save that result as a collection and it will be collapsed into a collection with "add this resource" only, as noted by Mark from another thread.