BUG?: Available Search fields
I notice fields in Search (under Search Fields) that are usually associated with book metadata rather than the book's text e.g.
- My Rating, My Tag
- Alternative Title, Abbreviated title and others when "title" is entered
- Community Rating/Community Tag
Is this correct?
Dave
===
Windows 11 & Android 13
Comments
-
Which type of search are you seeing this in?
Andrew Batishko | Logos software developer
0 -
Books Search > Downloaded Books
Dave
===Windows 11 & Android 13
0 -
We are unable to recreate this issue. Can you post a screenshot?
Andrew Batishko | Logos software developer
0 -
We are unable to recreate this issue. Can you post a screenshot?
Actually, these are from Verbum 32 Beta 4, not Logos 31. Apologies.
.......
Dave
===Windows 11 & Android 13
0 -
Do those fields show up if you switch from Downloaded Books to Personal Books? Is it possible you have Personal Books that use those fields?
Is there any chance you could zip up and make available to us your Data\<random>\LibraryIndex\index.fld and Data\<random>\PersonalBookIndex\index.fld files?
Andrew Batishko | Logos software developer
0 -
Do those fields show up if you switch from Downloaded Books to Personal Books? Is it possible you have Personal Books that use those fields?
That reminded me I had been experimenting with field names in one PB after a recent update (Rev 29) of the Search Fields List wiki where these fields had been included. The PB was only updated on Verbum 32, and I tried a large number of fields:
Field Name Info Name Info Description
abbreviated Abbreviated Form Morphology specifies use of an abbreviated form...
abbrev Abbreviated Title No description
alttitle Alternative Title No description
collection Collection Title Collection Title ?
color Not listed i.e. not on Information page ?
communitytag Community Tag No description
communityrating Community Rating No description
bodyofwater Not recognised by compiler
base Not listed ?
bull Not listed ?
editor Editor Publisher Title ?
edition Edition No description
editions Editions Editions ?
inv In Volume In volume ?
keydevelopment keydevelopment No description
updateddate Last Updated Date No description
livre Livre Title No description
livretype Livre Type No description
mytag My Tag No description
myrating My Rating No description
paralleltitle Parallel Title Parallel Title ?
publisher Publisher No description
recommendedreading recommendedreading No description
topiclevel Topic Level No description
The red fields are Library fields. The other fields should have a description. Ones with a ? are a puzzle to me
I noticed that fields after myrating were not listed on Info page, but were listed when I removed earlier fields from the text of the PB (and recompiled)
Dave
===Windows 11 & Android 13
0 -
The other fields should have a description. Ones with a ? are a puzzle to me
The bigger problem is the Search Field Names in the Help as i found many to be incorrect based on field names returned in the Search Box e.g. by typing lectionary and scrolling down for the fields. I updated the wiki based on this.
Dave
===Windows 11 & Android 13
0 -
I had been experimenting with field names in one PB after a recent update
Did your PB actually tag text with those fields? If so, it would explain why they are showing up in your list when searching PBs. This would be the expected behavior.
Andrew Batishko | Logos software developer
0 -
The bigger problem is the Search Field Names in the Help as i found many to be incorrect based on field names returned in the Search Box e.g. by typing lectionary and scrolling down for the fields. I updated the wiki based on this.
I checked your example, and they all seem to be there. The help file appears to be listing a different alias for the same field compared to the alias inserted in Search, but either option still works (at least from the testing I did). I request an update of our help file to make this more clear.
Andrew Batishko | Logos software developer
0 -
Did your PB actually tag text with those fields? If so, it would explain why they are showing up in your list when searching PBs. This would be the expected behavior.
Yes, I explained that above.
However, I trust that you can answer the questions I raised i.e.
- bull compiled as a field but it produced "Orthographic Variants" on the Information page when its Search field name is orthVar:
- base compiled as a field but it produced "Stem Form" on the Information page when its Search field name is stem:
- colon compiled as a field but it produced "Variant Punctuation" on the Information page when its Search field name is variantPunctuation:
- the compiled names came from Logos Help but needed the field. modifier to work in a Search
- the suggested Search field names for the above did not compile, yet they produced Search results in the PB!
- How should this be handled in the documentation?
- bodyofwater did not compile yet it is a valid field name??
- Should Library field names be documented e.g. mytag when there is a Tag field; the Community fields when they make no sense in a book.
Dave
===Windows 11 & Android 13
0 -
All of the things you listed are aliases of each other (bull and OrthVar; base and Stem; colon and VariantPunctuation). They can be used interchangeably when marking up the PBB, although in the Personal Book the syntax is case sensitive (unlike in the search string). Note the alterations to capitalization in what I listed above. BodyOfWater is an alias with water.
the suggested Search field names for the above did not compile
I don't know what this means. I built a Personal Book with all eight of the fields mentioned above. The Personal Book compiled, and I was able to successfully search for all eight. Perhaps you weren't using the correct capitalization.
the compiled names came from Logos Help but needed the field. modifier to work in a Search
Yes, that is expected. The shortcut without the field. modifier is only available for some of the more common fields.
I have made a request for the Help documentation to be updated for more clarity in this area.
Andrew Batishko | Logos software developer
0 -
All of the things you listed are aliases of each other (bull and OrthVar; base and Stem; colon and VariantPunctuation). They can be used interchangeably when marking up the PBB,
The following comes from my PB:
The word before "field" is exactly what I used in {{field-on}}/{{field-off}}
- Search with base:stem is not OK but field.base:stem works
- Search with stem:stem works but stem does not compile
- Which is the alias?
- Similar for Variant Punctuation and Orthographic Variants i.e.
- field.colon:variant or variantpunctuation:variant work, and
- field.bull:Orthographic or orthvar:Orthographic work
- Exactly where does capitalization affect matters e.g.
- field.Bull has no results in Search but orthVar is not affected by it.
- original is provided in Logos Help (as is base, bull and colon) but it does not compile?
- original: is also provided in the Search box
BodyOfWater is an alias with water.
When used as the field definition, water is compiled. But it is not documented!
As above field.Water has no results whilst field.water works.
bodyofwater is case insensitive in Search.
OK, I'm getting the sense of Capitalization and alias. But the field definition (water) has to be documented and clarified as case sensitive. But do you document the alias (BodyOfWater) or encourage use of the Search box to find it whilst clarifying that it is case insensitive? Or do you recommend global use of the field. modifier?
Dave
===Windows 11 & Android 13
0 -
In my experience, the fields in the word document are case sensitive. Where I failed to use the correct capitalization, the PBB tool failed to interpret the text as field markings.
Also in my experience (using the same book), the Search syntax is not case sensitive.Andrew Batishko | Logos software developer
0 -
In my experience, the fields in the word document are case sensitive. Where I failed to use the correct capitalization, the PBB tool failed to interpret the text as field markings.
Yes. water must be used in the field markings. Water is not recognised, and the field name bodyOfWater is not recognised. So water is the alias? Is this your understanding?
Also in my experience (using the same book), the Search syntax is not case sensitive
Yes, the field name bodyOfWater is not case sensitive, and it does not require the field. modifier.
However, field.water is case sensitive and does require the field. modifier.
Dave
===Windows 11 & Android 13
0 -
Interesting. It does appear that while the aliases are case insensitive in the search query, the base field names are case sensitive (all of them are all lower case).
I'll pass that along to the search team.
water is the field. BodyOfWater is the alias.
Andrew Batishko | Logos software developer
0
