BUG?: Available Search 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?

Dave Hooton

https://community.logos.com/discussion/comment/1286563#Comment_1286563

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 Hooton

https://community.logos.com/discussion/comment/1286584#Comment_1286584

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.

Andrew Batishko

https://community.logos.com/discussion/comment/1286584#Comment_1286584

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

https://community.logos.com/discussion/comment/1286691#Comment_1286691

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.

Dave Hooton

https://community.logos.com/discussion/comment/1286767#Comment_1286767

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.

Andrew Batishko

https://community.logos.com/discussion/comment/1286775#Comment_1286775

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.

Dave Hooton

https://community.logos.com/discussion/comment/1286784#Comment_1286784

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?

Andrew Batishko

https://community.logos.com/discussion/comment/1286826#Comment_1286826

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.

Dave Hooton

https://community.logos.com/discussion/comment/1286872#Comment_1286872

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.

Andrew Batishko

https://community.logos.com/discussion/comment/1287042#Comment_1287042

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.