[sword-devel] Concerns about Alternate Versification
jonmmorgan at gmail.com
Tue Jan 6 23:30:17 MST 2009
On Wed, Jan 7, 2009 at 11:49 AM, Greg Hellings <greg.hellings at gmail.com> wrote:
> On Tue, Jan 6, 2009 at 11:58 PM, Jonathan Morgan <jonmmorgan at gmail.com> wrote:
>> On Tue, Jan 6, 2009 at 3:08 PM, Jonathan Morgan <jonmmorgan at gmail.com> wrote:
>>> On Tue, Jan 6, 2009 at 2:51 PM, Greg Hellings <greg.hellings at gmail.com> wrote:
>>>>> 4. Bible references from commentaries, etc. use this master versification.
>>>> Then the module creator needs to go through and convert all of their
>>>> references to that master versification. Why would we do that when we
>>>> can just tell them they have the right to specify a preferred module?
>>>> One front-end might decide that the user is free to over-ride that, to
>>>> their own possible confusion, but that allows the module creator to
>>>> create the module correctly, instead of having to transfer it to a
>>>> master versification. Think of how confused a user would be if they
>>>> click on a reference that says, "Matthew 3:17" and are taken instead
>>>> to their favorite Bible module to the key "Matthew 2:27." Sure, it
>>>> might have the right content, but they would think the system was
>>>> broken - and I don't blame them. Likewise if I see a print copy of
>>>> Matthew Henry's that refers me to Psalm 150:1 and then open SWORD and
>>>> want to read the passage there some other day and it has been changed
>>>> to Psalm 151:1 because of the differences in Psalm numbering - I'd be
>>>> utterly confused and would report invalid module content.
>>> Think how confused they would be likewise if the verse didn't say
>>> anything like what the commentary said it did. Which would you
>> Also, it is quite possible to overcome this by displaying a status
>> message somewhere informing the user that it has gone to Psalm 151:1
>> because it is equivalent to Psalm 150:1 in the other versification.
>> The status message could even allow them to go to Psalm 150:1 in that
>> module if they decide that is really what they want (it isn't, unless
>> the module author encoded it badly, but that's besides the point).
>> The exact form of such a message is open to debate, but the fact
>> remains that this way is the only way to overcome both forms of
>> confusion (Psalm 150:1 doesn't say what the commentary said, and I
>> didn't want to go to Psalm 151:1).
> And I keep advocating that there's lots of untapped potential in the
> config files. You could put this together as the front-end developer,
> and communicate to the module developer the config entry to have.
> From what I understand the engine exposes every entry in the config
> file, whether or not its part of the standard SWORD entries. If you
> want them to point you to a file that maps out differences between
> their version and any other version, you could have them put that
> entry in the config file, and then read it into your own front end.
> The question of course, exists as to why you wouldn't make a patch for
> the library itself to expose the functionality and conversion to
> everyone else's front ends - which is something I think most people
> would advocate for. That seem the most simplistic and straightforward
> method of doing it to me - though not necessarily the best. Then,
> perhaps, include a flag in the config file that indicates something
> like "Versification=KJV" or "Versification=Luther" or have some
> standards that are built-in to the library for a module which adheres
> to a "standard." Then you could have "Versification=Custom" along
> with "VersificationSpec=modules/text/ztext/myversion/myspec.conf" and
> that conf file could specify that it maps differences between the
> module and, say, the Vulgate (or LXX or whatever other one of the
> built-in versions the module creator chooses). They could include
> omissions, duplications, divisions, combinations, etc. That leaves
> the module creator free to use any versification they want, and free
> to specify how it deviates from the nearest "standard" if they wish,
> for maximum interoperability with other SWORD content. This also
> means that backward compatibility is maintained (a big issue, it would
> seem, for SWORD modules, for some reason incomprehensible to me) with
> modules, by not adding anything to the actual module format itself,
> but exposes the issue of mapping between different modules and
> versions and versifications.
As to why backwards compatibility is maintained: in general, I would
agree with you, but if a person has a CD with lots of modules on or
several hundreds of megabytes of modules installed they aren't going
to be too happy upgrading them all when they get a new copy of the
There are two related questions:
1. How do you register the versification of the module? Your way
sounds fine to me (it's probably worth at least considering using the
format of http://www.ccel.org/refsys/refsys.html).
2. How do you refer to a verse in a particular versification? (again,
I would use the extensions to osisref from the above link, probably
extending to bible:module.ref to refer to a module's versification).
As to why I don't do it: I don't like C++ (though I used to use it a
lot) and I have enough work for BPBible to keep me busy for months on
end which I view as far higher priority than alternate versification.
More information about the sword-devel