BUG/ERROR? No "Place" Entry for "Athens" in Flyout Menu for Acts 18:1

Page 1 of 1 (13 items)
This post has 12 Replies | 0 Followers

Posts 789
Richard Lyall | Forum Activity | Posted: Sun, Jun 10 2018 4:31 PM

There seems to be no entry for "Athens" as a "Place" when right clicking "Athens" in Acts 18:1 in NIV84 or NIV2011.

However, other proper nouns in the same passage e.g. "Corinth", "Pontus" do have entries under the Place section in the flyout menu.

Surely this is not intended behaviour? Athens appears in the Factbook, as does Corinth, but this word is not tagged as a Place for some reason.

Posts 405
Lewis Harper | Forum Activity | Replied: Sun, Jun 10 2018 5:12 PM

Richard,

It is working properly for me both in the NIV2011 and NIV1984.

Posts 23283
Forum MVP
Dave Hooton | Forum Activity | Replied: Sun, Jun 10 2018 6:00 PM

If you are up-to-date with datasets (in Help > About..., below)

Check Resource Information > Support:-

NIV 2011 (all three) - 2018-02-14

NIV84 (all three) - 2018-02-27

If not so, try the commands Update Now and Update Resources

Dave
===

Windows & Android

Posts 789
Richard Lyall | Forum Activity | Replied: Sun, Jun 10 2018 6:34 PM

Thanks - I'll have a check. but I do receive automatic updates so would expect to be up to day with s/w and resources.

Posts 789
Richard Lyall | Forum Activity | Replied: Sun, Jun 10 2018 6:57 PM

Yes, my version numbers\dates are all identical to yours for those datasets and also for NIV84\2011.

I noticed that in Acts 18:1, Athens is tagged as a Place in the ESV, LEB, NKJV, REB, but also missing as a Place tag in NLT, RSV, NRSV.

Stranger still ... in the NIV84, "Corinth" is tagged as a Place in Acts 18:1 but not in 18:18.

EVEN STRANGER  still ... if I highlight "Athens" in Acts 18:1 in NIV84, using click+drag, THEN right click on it, "Athens" does appear in the flyout as a Place. But if I right click on "Athens" without highlighting first, it does not appear.

Also, if I set "Smart Selection" to "character" (it was set to "Smart" originally), then Athens does appear as a place in Acts 18:1/NIV84 when I right click without highlighting first.

In 18:1/NIV84, Paul is not tagged as a Person, but he is tagged as a Person in 18:18

I thought it might be a Wacom tablet issue, about but this happens with mouse as well.

There is definitely something very odd going on here, This feature/data is not behaving consistently and I haven't identified the pattern yet.

Posts 23283
Forum MVP
Dave Hooton | Forum Activity | Replied: Mon, Jun 11 2018 8:59 PM

Richard Lyall:
Stranger still ... in the NIV84, "Corinth" is tagged as a Place in Acts 18:1 but not in 18:18.

Richard Lyall:
In 18:1/NIV84, Paul is not tagged as a Person, but he is tagged as a Person in 18:18

<Person>, <Place>, <Thing> etc.  will only appear in a translation if the word comes from the original Greek (SBLGNT to be precise).  In these cases, the words Corinth and Paul were inserted for clarity. Check the Interlinear panel to see if there is a Greek word.

Richard Lyall:
I noticed that in Acts 18:1, Athens is tagged as a Place in the ESV, LEB, NKJV, REB, but also missing as a Place tag in NLT, RSV, NRSV.

Not so in my bibles!

Richard Lyall:

EVEN STRANGER  still ... if I highlight "Athens" in Acts 18:1 in NIV84, using click+drag, THEN right click on it, "Athens" does appear in the flyout as a Place. But if I right click on "Athens" without highlighting first, it does not appear.

Also, if I set "Smart Selection" to "character" (it was set to "Smart" originally), then Athens does appear as a place in Acts 18:1/NIV84 when I right click without highlighting first.

I agree that Athens does not appear as a Place with Smart Text Selection (with Athens as the Selection in the Context menu)! Corinth does, though. The difference appears to be that Athens is translated from two Greek words. But it does not hold true in Acts 17:16, nor does it happen in the ESV!

This (bug) appears to be unique to this occurrence of Athens in NIV84. It sometimes does not appear if I select the word with Character Text Selection!

Dave
===

Windows & Android

Posts 789
Richard Lyall | Forum Activity | Replied: Tue, Jun 12 2018 6:04 AM

Hi Dave ... thanks for looking into this.

I did some digging also and realised that it did have some bearing on the underlying text, but from a user experience point of view, it should be based on the surface text for consistency, regardless if it was translated or added ad sensum. If "Paul" appears in the translation, then right clicking it really should behave in a consistent way, but I can understand from a technical point of view why it behaves as it does.

Technologies do exist in Logos to find references to characters whether they are mentioned in name or not, so maybe this needs to be applied here too.

As for the Smart Selection issue\bug that adds to the confusion as now it depends not only on the base text, but also how you select, so what should be a simple, consistent user experience is obfuscated by two layers of technical complication, which seems to work against the Logos philosophy of putting information at the user's fingertips.

I hope someone from Logos will take a look at this thread and pass the information on to the relevant parties. I have also sent an email to tech support so we'll see what they way.

Posts 23283
Forum MVP
Dave Hooton | Forum Activity | Replied: Wed, Jun 13 2018 5:38 AM

Richard Lyall:
Technologies do exist in Logos to find references to characters whether they are mentioned in name or not, so maybe this needs to be applied here too.

What I described is that technology! Right click a pronoun (also verb, adjective) in a Reverse Interlinear to establish that. Note that NT Saul = Paul. Translators make their own choice of where to insert words (or omit words!), so using a Greek text as the base for occurrences of names and referents is advantageous. There are some idiosyncrasies, like "did" = Paul in HCSB Acts 9:9, so if you want "counts" search a Greek bible for <Person Paul>, <Place Athens>, etc.

Dave
===

Windows & Android

Posts 789
Richard Lyall | Forum Activity | Replied: Wed, Jun 13 2018 10:44 AM

We're talking at cross purposes here I think. I think you're maybe coming at it from a data perspective, whereas I'm addressing things from a user experience angle.

If the word "Paul" appears in the surface text of a translation, regardless if it is directly translated from Greek or added ad sensum (to make up the sense), the s/w should inform the flyout menu to add "Paul" as a "Person" when right clicked. Likewise for "Athens" being included as a Place. In other words, the data layer which should be used to construct the flyout menu should be the surface text, not the underlying data.

The user should be offered a consistent user experience based on what they see on screen, not on the underlying data structure that produces it. Features such as "Factbook" are aimed at enhancing the study of all users, so it should behave consistently without users needing to understand translational mechanics, or wonder which screen instance of  the word "Paul" will trigger the study features they expect. I don't want to have to click on 3 different "Paul" instances to find one which leads to the flyout menu entry appearing.

The current implementation is inconsistent, and can only be understood by delving into the inner workings of the software, and this is not leading to a consistent user experience.

Posts 24255
Forum MVP
MJ. Smith | Forum Activity | Replied: Wed, Jun 13 2018 12:42 PM

Richard Lyall:
I think you're maybe coming at it from a data perspective, whereas I'm addressing things from a user experience angle.

While I understand why the user would like to see "added ad sensum" words, it is impractical without building a far more expensive system than Logos. Why? Because words can carry multiple meanings, refer to multiple people etc. Each and every translation would have to be disambiguated OR an artificial intellegience disambiguation system would need to be built and trained. Either solution adds to the possibility of errors and would make the cost increase significantly. By tagging only the underlying Greek, new translations can be added at significantly less cost and the results are guaranteed to be consistent across translations.

For the user, the solution is to select a longer string of words so that at least one occurrence of the desired entry is included and therefore on the flyout context menu. Unfortunately one cannot add a community tag to resolve the issue if my testing was correct; that would be the feasible option.

Orthodox Bishop Hilarion Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."

Posts 789
Richard Lyall | Forum Activity | Replied: Wed, Jun 13 2018 3:07 PM

Again this is taken from a system and not a user perspective, which is fine, but it doesn't address the issue I was raising. If the best response is "you can't have it because it's too complicated" then we're stuck with a partial implementation in which users are going to be left wondering why the current system delivers a range of user experiences in response to the same operation.

For those of us who are original language aware and technically adept enough, this is fine, but some of the people I work with would be baffed by the inconsistency produced by the current approach, and rightly so. It does seem to belie the user-friendly aura that Faithlife is keen to propagate.

There's surely no need to create some overengineered AI behemoth that governs every possible circumstance. All that is needed is something which brings up the relevant Factbook entries for the entities present in the passage of interest, whether their monikers are named or implied.

Of course there can be multiple people or whatever with the same name, but this misses the point, when thinking systemically rather than thinking what the user needs. There might be several Pauls but each instance of Παῦλος only refers to one of them, so the tagging should know which one it is and deliver links to the pertinent Factbook or other resources. Much of this kind of disambiguation seems to happen all the time with existing datasets - someone has already decided which of the synonymous persons is being referred to so this information should be driving the code that populates the flyout menu etc.

Posts 24255
Forum MVP
MJ. Smith | Forum Activity | Replied: Wed, Jun 13 2018 3:53 PM

Richard Lyall:
Again this is taken from a system and not a user perspective, which is fine, but it doesn't address the issue I was raising.

My apologies if I did not make it clear that I do understand what you are saying from a user perspective. I also tried to make it clear that as a user, I am unwilling to foot the bill for what you consider "full implementation" and I consider "extension of implementation". You have no idea how many times I have told a departmental payroll clerk that they have to send the case to central payroll because the cost of automating the last 2% is not cost-effective. In this particular case, I would take the tack of stating that it is not cost effective to implement especially when there is an easy way to obtain what you need - make a longer selection.

Richard Lyall:
Much of this kind of disambiguation seems to happen all the time with existing datasets - someone has already decided which of the synonymous persons is being referred to so this information should be driving the code that populates the flyout menu etc.


Yes, this has been done ON THE UNDERLYING GREEK. You are correct that this is a piece of what populates the context menu (fly-out). We are discussing specifically those cases which have no underlying Greek. What I tried to say was this kind of dataset would have to be built for each translation rather than once for the Greek and mapped back on the translations. Yes, one would probably design it so that only those words without underlying Greek needed to be coded individually for each Bible - at the cost of either more resource space or more process time. I don't know the structure of Logos to even guess what the resource/process trade-off would be.

Yes, you are correct that this is something that the system designers should keep in mind as an unwanted limitation of the system. Then when/if the appropriate algorithms become available in the natural language processing/artificial intelligence arena, they will remember to note it and schedule implementation. 

Orthodox Bishop Hilarion Alfeyev: "To be a theologian means to have experience of a personal encounter with God through prayer and worship."

Posts 23283
Forum MVP
Dave Hooton | Forum Activity | Replied: Wed, Jun 13 2018 4:21 PM

Richard Lyall:
In other words, the data layer which should be used to construct the flyout menu should be the surface text, not the underlying data.

Richard Lyall:
The current implementation is inconsistent, and can only be understood by delving into the inner workings of the software, and this is not leading to a consistent user experience.

For translations with RI's, very little of the information on the RHS of the context/flyout menu is (or can be) based on the surface text, so one has to expect some inconsistencies and bugs. If you check a non-RI bible there is less information. You will see Person, Place, Thing applied to names, but not referents, and they have the same issue with the surface text. Other information is likely based on the verse, so it can be applied to any bible.

Based on the surface text alone you can't expect 'Saul' to be identified as person Paul, or even be identified as a person. Ditto for 'Athens' as a place. And how does software recognise non-capped words as a thing?

Dave
===

Windows & Android

Page 1 of 1 (13 items) | RSS