Troy, With all of these questions, possibilities and alternatives, perhaps it would help if you were to write up some sort of formal specification or even a Design Document for the code as you see it. Even something as basic as an outlined header file including just the interface methods and some documentation for those methods would allow people to focus their thoughts and avoid the floundering in ideas. When I hear and think of this project I come up with thoughts such as:
--There should be no restriction on the names of books, the numbers of chapters and/or verses, or even the need to have discretized verses. These should be taken directly from the input OSIS file itself when the work is imported under the new scheme. --Since there is no restriction on the names of books, non-standard books (as-in, those not in the standard Protestant or Catholic scriptures), books like 3rd and 4th Maccabees, The Gospel of Thomas, the various books in the Book of Mormon, etc, would need to have allowable abbreviations specified in a configuration file distributed with the module --Any attempt at mapping verses from the KJV versification to the module's versification would also need to be encoded into a configuration somewhere so that the module creator would have control over this, rather than allowing the program to try to figure that out on its own. This wouldn't have to be a large file, but could just contain differences between the two, and could even employ formula, such as "Ps 78-151 -> chapter-1" or some such thing for compact notations. These are just some of the points as to how I have thought that some of these technicalities could be defined to make some sense of issues. If you were to stringently define these, then a design and implementation could be put together much easier. Cheers! On 3/12/07, Jeremy Brown <[EMAIL PROTECTED]> wrote: > sword-devel@crosswire.org on Sunday, March 11, 2007 at 11:00 AM -0800 > wrote: > >> which is currently imported as a SWORD General Book (General Books use > >a > >> TreeKey index, as you can see from the left navigation) and to make it > >> accessible via a new specialized VerseKey descendant (VerseKey is what > >> SWORD Bibles use). The new TreeKey subclass will be implemented to > >> merely walk the existing TreeKey index of the General Book module > >format > >> to get it's data (books, chapter max, verse max, etc) and will position > >> the TreeKey to the appropriate node when it is positioned to, say, > >"John > >> 3:16". > > Is the goal in the new VerseKey to > 1. display and interact with Bibles in their original versification scheme? > 2. also allow two Bibles with different versifications to accurately > display their verses in parallel? > > It seems like it is at least accomplishing #1, I don't know if you are > trying to accomplish #2 or not at this point. It is something that can > probably be tacked on later, but #1 is probably critical to accomplish > before you can do anything with #2. > > If you are trying to work on #2, then I have some tools that might be > useful, maybe I would need to rewrite them in a useful format for you > though. I would like to help if it is needed, but if you aren't working > on #2, you probably don't need these. > > One is a tool (currently a web app) that looks at the verses in the NRSVA, > and the verses in some other version, and shows where verse mismatches > occur (i.e. a verse that is in the NRSVA does not exist in the second > version, or vice versa.) It then lets you look at those chapters, find out > where the verse misalignment occurs, and add custom verse mappings, until > every verse in one version is mapped to a verse in the other. I can then > export these verse mapping rules, and know the correspondences between > verses in NRSVA and the other version. This is used in the Unbound Bible > to show versions in parallel - the NRSVA verse scheme is used as the > default, and then all the other versions (that have been mapped) are shown > in parallel using these custom verse mappings. > > The second tool is modified from a set of Microsoft published perl scripts > for comparing translated texts. It takes Bible input in an Unbound Bible > format (book, chapter, verse, subverse) for two Bible versions, and tries > to find mismatches in the parallelity of the verses. This can help find > places where the verses do not match up from one translation to the other. > >From that data, a person can start examining both translations around the > areas of mismatch and decide what verses in one version really match up to > verses in the other. > > So I'd be happy to try to share these tools, if you think they are > relevant. > > Jeremy > > > _______________________________________________ > 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 > _______________________________________________ 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
