[bt-devel] Announcing the Open Scriptures Morphological Hebrew Bible module
Troy A. Griffitts
scribe at crosswire.org
Tue Apr 13 15:25:05 MST 2010
Eeli Kaikkonen wrote:
> The user should also be able to select the default versification used in
> the application. That would be very polite towards Eastern Orthodox,
> Hebrew readers etc. who don't use the RSV/KJV versification natively.
> The engine should do the mapping and give automatically the right
> content.
Agreed. The conversion point is isolated in the engine, but no
implementation is yet coded. We've thrown around a few theories of how
to best store/perform the conversion, given:
a b c d e f versifications, how to get from any to any.
We've discussed:
A master superset; but this presumes we collect all (or very close to
all) schemes up front
Direct mappings from each a-b a-c a-d a-e a-f ad nauseum; but the
disadvantages are obvious.
A variation of the previous with logical multi-iteration conversion;
e.g. a-k and k-b would eliminate the need for a-b.
Before we get to the coding on this, we need to finish the external v11n
storage (currently only the initial phase of av11n is complete, which
has each v11n compiled into the engine). Most of the coding is complete
on this, but we may decide to use a simpler, human readable storage
format rather than the initial binary treekey Bible format we had
planned. The work Chris has done to produce easy to read v11n schemes
and convert those to C arrays we compile in the engine could easily just
be read in by the engine, and this would be much easier to maintain than
a binary format, and easy for a module wishing to provide a custom v11n
scheme to copy and modify.
Once this external storage is finalized, adding the v11n translation
storage format should have a more obvious path.
Any ideas/discussions on optimized logic algorithms per above would be
most appreciated.
Troy
More information about the bt-devel
mailing list