Hi I think I mentioned this before, but the files that JSword use are here: https://github.com/crosswire/jsword/tree/master/src/main/resources/org/crosswire/jsword/versification
It would indeed be nice if we could use the same format specifications. The documentation lines 80-ff of the following file outlines the semantics that we adopted for JSword: https://github.com/crosswire/jsword/blob/master/src/main/java/org/crosswire/jsword/versification/VersificationToKJVMapper.java The following file outlines some simple use cases: https://github.com/crosswire/jsword/blob/master/src/test/java/org/crosswire/jsword/versification/VersificationToKJVMapperTest.java We mainly use the range notations at present (not the offsets). Shout if things are not clear. Chris On 4 March 2014 20:26, Костя Маслюк <kostyamasl...@gmail.com> wrote: > > 28.02.2014 23:42 пользователь "Troy A. Griffitts" <scr...@crosswire.org> > написал: > > > > > Костя, > > > > > > IOn 02/28/2014 08:14 AM, Костя Маслюк wrote: > >> > >> Ok. > >> > >> I have got following: > >> http://crosswire.org/~kalemas/work/v11nmapping/paralleldisplay.html > > > > > > Amazing! This looks really great! Daniel 3 is a nice test chapter. > Your output looks very nice. I will play around with your updates to the > test and send mine. > > > > > >> /me cant get rid of feeling that Troy still did not disabled his > >> screen filter that rips everything i write to him > > > > > > Костя, no, I'm sorry for not replying inline in my last email. Much of > what I wrote was in response to your emails, but it wasn't obvious because > I did not post inline. (notice the repentance with this email) > > I read everything you wrote and was excited to start the conversation > again, and concluded that if we can just prove that one implementation CAN > handle pretty well a majority of the cases, then we can move forward and > commit to this API interface we're trying. The theoretical conversation > wasn't going anywhere and a proof of concept seemed to be the best way > forward. As far as the implementation, I am concerned about your same > points, that SWORD and JSword need to have a common set of mapping data and > ideally a common storage format for that data. I'm not concerned about the > size and speed immediately as we can always improve the implementation. > > > > I had noticed that you answering directly to my message and had addressed > me, but only after i sent message. > > > I just would like the programming interface and how we intend for it to > be used by consumers to be solid; I don't want frontend developers to have > to change their code. I think our proof of concept should satisfy this. > > > > As for the shared mapping data and storage mechanism, we need to > collaborate with JSword. > > > > Conceptually, I have always been leery of a 'superset meta v11n' concept > to do this mapping. It seems the most straightforward way if we can > establish this superset, but conceptually it practically prevents things > like mappings between the different versifications of Josephus-- which is a > very real problem we'd like to solve with the same mechanism. > > > > I believe you are going from X -> KJV+ -> Y right now. > > > > I think this logic is fine but was hoping for the internal data to be > boiled down generically to optimized deltas somehow,e.g.,: X->KJV { > verseShift(Ps.9.21-:10.1); chapterShift(Ps.10-112:+1) ... } > > and then when asked to map from X -> Y, we could look at our mappings > and find the most optimized path. It may still be X->KJV->Y, but it may > also be X->Y or JosephusLoeb -> JosephusWhiston. > > I think no need to flow down implementation details. Generally i agree > that we could add mapping sets. So there will be several sets available as > well as KJVA set, that is default and implementation will select shortest > path to find corresponding data. > > But i suggest to delay this as it will complicate whole system, that is > undesired at this stage. I would like to make current implementation to > work correctly on current module set. We could create improvement request > in jira as we commit this. > > > > > If we force the concept of a superset KJV+ v11n scheme into our mapping > concept, I am afraid it will limit us and we will continually have to > update this meta v11n when we create new modules and find new strange > things. > > We are foredoomed to meet new strange places. I think it is normal to > solve problems as they have place to be. > > > > > Chris can comment, but simply mapping the various LXX editions to each > other, alone, can be daunting to think about. > > I m too hope on his participation. > > > > > This all is aside from the API mechanism on which we are working > presently, but just offered for discussion between JSword and SWORD and > others when considering how we wish to represent and persist these mappings. > > I m too would like to hear thoughts about of how JSword people would like > mapping data to persist, because if we ever supply mapping data with > module, i want that data to be convenient to work with for them. > > Blessings. > > _______________________________________________ > 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
