Versification mapping sounds very useful. Is there any agreement/design/plan for what it would actually entail? >From my uninformed perspective, it seems like there could be lots of ambiguity or disagreement about the "use cases" and priorities especially if there needed to be a staged implementation.
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? There may even deeper questions like: - Can or should all v11ns be defined normally in such detail that all possible mappings to other v11ns becomes a purely mechanical inference process? - 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? - 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..."). 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? Maybe another way of asking these questions is: 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. 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. 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. --paul On Fri, Jan 6, 2012 at 8:54 PM, Daniel Owens <dcowen...@gmail.com> wrote: > 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. > > 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). > > Daniel > > > On 01/07/2012 07:54 AM, DM Smith wrote: > >> I agree with Chris. >> >> It will take a lot of work in the SWORD and JSword engine to implement it. >> >> 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. >> >> In Him, >> DM >> >> On Jan 6, 2012, at 6:31 PM, Chris Little wrote: >> >> On 1/6/2012 1:29 AM, David Haslam wrote: >>> >>>> Extending Peter's concept, might we also make the book order something >>>> that >>>> can be worked with by front-end developers? >>>> >>>> e.g. For the NT in Eastern Canonical order we might have: >>>> >>>> Scope=Matt-Acts James-Jude Rom-Heb Rev >>>> >>>> i.e. with the General Epistles ordered prior to the Pauline Epistles. >>>> >>> 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.) >>> >>> 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. >>> >>> 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. >>> >>> This would be a further step towards "canon neutrality" as expounded by >>>> Neil >>>> Rees ("Studge") at BibleTech 2010. >>>> >>> I'm also not clear on how this would achieve canon neutrality. >>> >>> --Chris >>> >>> ______________________________**_________________ >>> sword-devel mailing list: sword-devel@crosswire.org >>> http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel> >>> Instructions to unsubscribe/change your settings at above page >>> >> >> ______________________________**_________________ >> sword-devel mailing list: sword-devel@crosswire.org >> http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel> >> Instructions to unsubscribe/change your settings at above page >> >> > ______________________________**_________________ > sword-devel mailing list: sword-devel@crosswire.org > http://www.crosswire.org/**mailman/listinfo/sword-devel<http://www.crosswire.org/mailman/listinfo/sword-devel> > Instructions to unsubscribe/change your settings at above page >
_______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page