[sword-devel] Alternate Versification

[DM Smith]

On Apr 26, 2009, at 3:52 PM, Jonathan Marsden wrote:

> Jonathan Morgan wrote:
>
>> I think that the versification should be shown as part of the module
>> information (after all, it is part of the module configuration), and
>> possibly it should have a more presentable name or more information
>> about a versification.  If so, this should also be available from the
>> API in some form, and it seems to me that it would be useful to have
>> similar things in osis2mod, so that you don't just get:
>
>> Available versifications:
>> KJV
>> Leningrad
>> Luther
>
> OK.  Are you proposing a new .conf file field, something like:
>
> VersificationDescription=A sentence or two about this  
> versification ...
>
> which would mean that every module could include this description  
> info,
> and that different modules with the same versification could have
> differing VersificationDescription text?  This is a simple change, but
> is not ideal because of the duplication that results, and the ensuing
> difficulty in obtaining a single description per versification system
> from the set of installed .conf files.
>
> Or, are you suggesting in effect some sort of "Versification  
> Information
> Database" which is more central to the SWORD library setup, that has  
> one
> (optional) description per versification system, and to which this
> information would be added at the time versifications are registered?

I think there are a few different audiences and perhaps different needs:
1) The module developer -- I think such a person needs help  
identifying which of the plethora of av11n to use. I'll be changing  
osis2mod to output the different versifications. If the developer runs  
the module through osis2mod, it will identify if the module contains  
references that are not in the requested canon. With the list of  
supported ones, they can try another and another, .... until one  
works. It might not be "correct" but it will work.

Ultimately, I think we need someone to write an analyzer that will  
recommend an alternate versification if one exists and will output a  
skeletal definition otherwise. As a diagnostic, it should give for  
each versification, what is in the text that is not in the  
versification and what is in the versification that is not in the  
text. My thought would be to write it for OSIS input.

2) The front-end developer - I think such a person needs to know what  
scope of the module given it's versification, at least at a book  
level. (I have seen some apps declare that a verse is missing when it  
is not part of the module.) If the versification includes the  
apocrypha, but the module does not, it should not present those books  
as missing. This also applies for NT only and OT only modules.

3) The end user - I don't think it should be at all obvious to an end  
user that we are using one versification or another. I don't think  
they should care and I think the app should help them not care. If a  
user is a theologian, they might have an academic interest. In this  
case, they probably know what Luther's or Leningrad Codex or the LXX  
versification is by name, though not detail.

With this, I think that 1) is what we have been talking about. If so,  
sword-devel and the wiki will have to stand in as a proxy for adequate  
tooling. I think it will be sufficient for now.


>
>
> The latter approach seems more logical to me, but needs more work and
> probably requires a (minor) API change to allow an extra optional
> parameter to the registerVersificationSystem() method, as well as a  
> way
> to get this info back out again, perhaps a listVersificationSystems()
> method.  Presumably these strings would be internationalized, so you  
> get
> a locale-appropriate result.
>
> Could each versification system also have a URL associated with it  
> that
> points to a web page describing it in more detail??  Or is that  
> overkill
> -- would it be better to make that "very" optional, by including any
> such URLs in the VersificationDescription string concerned?
>
> This kind of API definition and enhancement is IMO something that  
> should
> probably have happened a while ago, early in the av11n design stage,
> well before 1.6.0RC* releases started to emerge :)  I've not seen the
> av11n design documentation, so I have no idea if something like this  
> was
> considered earlier and has already rejected.
>
> The window of opportunity for SWORD 1.6.0 API changes is probably
> already closed.  So realistically, I'd think this should wait for  
> 1.6.1.
> For 1.6.0, adding a few fprintf()s to osis2mod is (IMO again) probably
> sufficient?

It will be added shortly. Troy has just committed the routine I need  
to finish a first cut at it.

>
>
> Could someone please propose the one-or-two-sentence descriptions of
> each versification system?  That would be a helpful step forward with
> this, I think.

A good place for this would be: www.crosswire.org/wiki/Alternate_Versification 
.

Just add a section that gives:
The name of the versification, the description of the versification  
and the date that it was added to the SWORD engine.


In Him,
	DM