[sword-devel] Semantic problem: real module names vs. Abbreviation=XYZ

[Peter von Kaehne]

Karl, can I summarise :

1) Abbreviations need to be bidirectional

2) Uniqueness needs to happen at user-level for bidirectionality to
work. Not above. 

3) Both across repos and internal to repos we can have one, some and
many modules which carry the same abbreviation - KJV being the most
notorious. It will be (see 2) up to the user to resolve this - but we
should make an effort to create sensible defaults. 

4) Apart from all that, we should try and eliminate genuine
duplications and ensure that we do not confuse users more than
necessary. E.g. to have many KJV (English language 1769 King James
Bibles) modules is not desirable. 

I think this is sensible and good.

Peter


On Wed, 2015-09-02 at 08:28 -0400, Karl Kleinpaste wrote:
> On 09/01/2015 09:45 PM, Kahunapule Michael Johnson wrote:
> > The uniqueness of an abbreviation is not required as long as you 
> > never try to look up which module corresponds to that abbreviation. 
> > If all you do is use the abbreviation as a short way to display 
> > which text is selected, i.e. just looking up the abbreviation given 
> > the module name, collisions are no big deal.
> "If all you do is..."
> 
> That's entirely the problem: That is not all we (need to) do.  You 
> are proceeding from false assumption.  As DM said, you're wrongly 
> insistent on demanding uni-directional "output" use, as a mere 
> eyeball convenience.  And that is simply not the case in the real 
> world, and actually hasn't been so for a long time, if it ever was.  
> Joe Average wants to type "KJV" in many contexts.  Module authors 
> want to cross-ref into "KJV" in their content as a matter of routine.
>   Network protocols want to ship "KJV" as a commonly-understood 
> reference name.
> > Module ID -> abbreviation is OK.
> > abbreviation -> Module ID is not OK.
> But it must be made OK.
> 
> You said to me in private email that you "live in a wider world than 
> Crosswire."  I suppose that's true along one axis of consideration.  
> I live in a wider world than Crosswire along a different axis: I am a 
> network head, and absolutely positively anything that threatens to 
> share data from Hither to Yon (or from Alice to Bob) must be not 
> merely handled, but expected all the time.  You cannot expect that 
> Bob will tell Alice -- the nature of whose Bible app is unknown to 
> Bob -- that her app should locate a module absurdly named 
> "engKJV2006."  It is entirely unreasonable to believe that other 
> software producers will name any module that way, and Alice's app may 
> not be from Crosswire.  So common abbreviations are the way to 
> achieve generality across software architectures, and they must be 
> accepted as input that way.  If Bob likes engKJV2006 as his KJV 
> implementation, great, and he should tell Alice that he's using (what 
> he thinks of as) "KJV," but Alice wants the official version as 
> supplied for her software.  They must interoperate.
> 
> A cardinal rule of the Internet since the ARPAnet days has been "be 
> conservative in what you send, and liberal in what you accept."  
> Conservatively, "KJV" is the correct way to identify the King James 
> Version to anyone on the planet.  Liberally, "KJV" is a correct 
> identification of a Bible to be provided by someone else, yet it is 
> not unique in a (Crosswire or any other) world where KJV and 
> (something like) engKJV2006 try to co-exist.
> >  language ID + abbreviation -> Module ID is OK.
> No, it is not.  At very best, you could claim that you have reduced 
> the breadth of conflict, but sometime next week someone else will 
> produce a different "Thai KJV" module that they want to show up in 
> our module selector lists, and so again conflict resolution is needed 
> because yours is not necessarily special to Thai speakers any more 
> than Crosswire's KJV is necessarily special to English speakers.  
> This example conflict just happens to become localized to the subset 
> of modules specific to Thai.  One cannot expect that there is always 
> and forever exactly one module implementation of XYZ in any language 
> group.
> > Stop doing that, and always require a full module ID whenever you 
> > want to find a module. (Requires some software rewriting and 
> > distribution.)
> Absolutely impossible, for all the reasons discussed above.  Users 
> type Bible names, common names with which they've been familiar since 
> childhood.  Commentary authors mention those same common Bible names.
>   Networks transport those same common Bible names.  The programmatic 
> handlers of these names must resolve such references to something in 
> the user's (local) real world.  So Alice will tell Bob via BSP to 
> find a certain verse in "KJV" and Bob's preference for engKJV2006 as 
> his "KJV" means he'll get what he wants.
> > Require that all module abbreviations are globally unique across 
> > well over 1,000 translations.
> > Let the user assign abbreviations and disallow assignment of a 
> > duplicate.
> This is the solution needed, in combination: Abbreviations must be 
> unique, and conflicts must be resolved as they are encountered.
> > Personally, I don't like the idea of burdening the user with 
> > managing unique abbreviations, unless you have working defaults so 
> > that this level of customization is not required.
> It is a mighty small burden: "By the way, your set of modules has 1 
> naming conflict.  Here's how to fix..."  As far as I know, at this 
> moment, there are exactly 2 actual conflicts, KJV and WEB.  You have 
> already made the former go away by removing engKJV2006 from eBible; 
> Crosswire will make the latter go away by removing WEB from Crosswire 
> main.  But the problem is general and could re-present itself 
> tomorrow with some other name.
> 
> The alternative is for abbreviation references literally not to work 
> as input, yet they must.
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page