Versification mapping sounds very useful. Is there any agreement/design/plan for what it would actually entail?<br>From my uninformed perspective, it seems like there could be lots of ambiguity or disagreement about the "use cases" and priorities<br>
especially if there needed to be a staged implementation. <br><br>Has the question "What kinds of differences can two v11ns or canons have and still be usefully mapped?" been discussed and resolved to any depth? <br>
<br>There may even deeper questions like:<br><br>- Can or should all v11ns be defined normally in such detail that all possible mappings to other v11ns becomes a purely mechanical inference process?<br><br>- If not, can or should the versification mapping process consist of an abnormally detailed independent analysis of each v11n, after which the mappings to other v11ns similarly analyzed becomes a purely mechanical inference process?<br>
<br>- If not, would each mapping between any 2 particular v11ns have to be hand authored and "coded" in some way (possibly something more like a conf file than a C++ header file, but "different arts for different parts...").<br>
<br>Or is there some compromise in which the mechanical inference does most of the work, based on details specific to each canon and v11n, with hints or customizations for any particular v11n pairing optionally coded by some author?<br>
<br>Maybe another way of asking these questions is:<br><br>Is there or could there be a v11n equivalent of the "Periodic Chart of the Elements" in which each element identifies an indivisible "atom" of scripture content so that each v11n could define (or be defined AS) a mapping to its component atoms? If so, it should be a simple matter to transitively map one v11n's arrangement of those atoms to another v11n's arrangement of those same atoms (each analyzed in isolation) to automatically infer the mapping between any 2 v11n's and to identify where there are no mappings due to canonical differences.<br>
<br>
Or is this approach impractical, and so we are better off with a less formal approach, like one that assumes that the number N of v11ns is small and will stay small and that the mappings between any 2 v11ns will mostly be simple and will follow common patterns, so someone (possibly even just the same C++ priesthood, bless 'em, that maintains those canon header files) could humanly keep up with N x (N-1) hand-coded mappings.<br>
<br>I just find it an interesting problem.  Maybe it's something a new volunteer with some programming skills could kick around, regardless of chickens or eggs.<br><br>--paul<br><br><div class="gmail_quote">On Fri, Jan 6, 2012 at 8:54 PM, Daniel Owens <span dir="ltr"><<a href="mailto:dcowens76@gmail.com" target="_blank">dcowens76@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Yes, mapping! I don't have strong opinion about how this works out on the engine side of things, but proper mapping between versifications for front-ends that support parallel display is essential for doing work with Old Testament Hebrew and Greek texts and with modern translations.<br>


<br>
I have happily used BibleTime frequently in my dissertation because it supports parallel display and effectively uses the mag window to display lemma and morphology, which I much prefer to the clutter of Strongs numbers in the main screen. But putting two Bibles side-by-side (which I do almost all the time) creates problems. When I put the ESV side-by-side with OSMHB or the forthcoming Wesminster Hebrew Morphology, it is a mess. Content invariably gets dropped at the end of the chapter. Add LXX and it is not workable (chapters are offset).<span><font color="#888888"><br>


<br>
Daniel</font></span><div><div><br>
<br>
On 01/07/2012 07:54 AM, DM Smith wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I agree with Chris.<br>
<br>
It will take a lot of work in the SWORD and JSword engine to implement it.<br>
<br>
If anything we should develop a v11n that can be read in from a resource file. But before that I'd like to see support for mapping from one v11n to another.<br>
<br>
In Him,<br>
        DM<br>
<br>
On Jan 6, 2012, at 6:31 PM, Chris Little wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 1/6/2012 1:29 AM, David Haslam wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Extending Peter's concept, might we also make the book order something that<br>
can be worked with by front-end developers?<br>
<br>
e.g. For the NT in Eastern Canonical order we might have:<br>
<br>
Scope=Matt-Acts James-Jude Rom-Heb Rev<br>
<br>
i.e. with the General Epistles ordered prior to the Pauline Epistles.<br>
</blockquote>
I am very much against this idea. (I have no problem with different book orders, and would happily add a new v11n system if the need can be proven to me and the data can be provided to me.)<br>
<br>
Scope/Coverage is very strongly dependent on the reference system (v11n) used. And other aspects of the library, such as verse reference resolution, are very dependent on the reference system as well. An osisRef such as "Matt-Jude" has to mean something within the context of a particular reference system. In the KJV v11n, this means all of the text of the NT except Revelation. If we were to support use of Scope/Coverage to re-order books, we would be creating new de facto v11ns. Under the above Scope, the osisRef "Matt-Jude" has a very different meaning from what would be expected, assuming the KJV v11n were still employed.<br>


<br>
Fundamentally, I think we should avoid adding new, complex methods of solving problems for which we already have solutions. In particular, the book-ordering issue can already be addressed by addition of new v11ns. The number of cases where two v11ns differ only in the ordering of their books is probably quite minimal and better served by adding a new v11n.<br>


<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This would be a further step towards "canon neutrality" as expounded by Neil<br>
Rees ("Studge") at BibleTech 2010.<br>
</blockquote>
I'm also not clear on how this would achieve canon neutrality.<br>
<br>
--Chris<br>
<br>
______________________________<u></u>_________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/<u></u>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/<u></u>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
<br>
</blockquote>
<br>
______________________________<u></u>_________________<br>
sword-devel mailing list: <a href="mailto:sword-devel@crosswire.org" target="_blank">sword-devel@crosswire.org</a><br>
<a href="http://www.crosswire.org/mailman/listinfo/sword-devel" target="_blank">http://www.crosswire.org/<u></u>mailman/listinfo/sword-devel</a><br>
Instructions to unsubscribe/change your settings at above page<br>
</div></div></blockquote></div><br>