Well, thanks Nic. I was testing this with the KJV and Packard and Robinson modules. I've posted in this forum thread myself but I couldn't remember. If this is so then I will also return a information message as you suggested. I'm wondering however why the SWORD API returns a valid result while the error flag is unset if this key doesn't exist in the module?
Cheers, Manfred Am 20.02.2010 um 05:49 schrieb Nic Carter: > > Hi Manfred, > > I'm curious as to what module you are using to look up these keys? I'm under > the understanding that looking up values like "TH8804" won't return a valid > result, as we don't have a lexicon containing these keys? > > I'm using this forum thread to justify my answer: > http://www.crosswire.org/forums/mvnforum/viewthread_thread,772 > > On this note, I'm going to show an error message in PocketSword when someone > tries to look up one of these Morphology codes, and the error message will be: > > "Unfortunately, Morphological Analysis Codes are only currently available for > Greek words. If you have the language ability and are willing to help bring > this feature to PocketSword, please take a look at <br /> > openscriptures.org<br />and join the discussion group there." > > Is anyone who is active with openscriptures.org able to comment on this? :) > I don't want to use this text if it's not correct, but if I'm able to refer > some possible volunteers to help with the work there, I'm hoping that would > be constructive? :) > > Thanks all, ybic > nic... :) > > ps: Manfred, I'll check in my code to SVN later today & you can check out how > I'm going to do Morph stuff. :) > > pps: Thanks for your reply, Troy, it helps with what I'm doing :) > > ---- > Nic Carter > PocketSword Developer - an iPhone Bible Study app > http://crosswire.org/pocketsword > http://itunes.apple.com/app/Pocketsword/id341046078 > > On 18/02/2010, at 11:05 PM, Manfred Bergmann wrote: > >> Hi guys. >> >> Now, I stumbled over an issue regarding morphs while working on MacSword: >> >> The morph value code in the link URL data is something like this: >> value=TH8804 >> When I set this as a key in SWModule with setKey() the correlating text is: >> "Part of speech: pronoun, relative Case: nominative Number: singular Gender: >> masculine" >> >> In the Packard module when I do an index search for this I get: >> Ra Nsm: >> Part of speech: pronoun, relative Case: nominative Number: singular Gender: >> masculine >> Rd Nsm: >> Part of speech: pronoun, relative Case: nominative Number: singular Gender: >> masculine >> Ri Nsm: >> Part of speech: pronoun, relative Case: nominative Number: singular Gender: >> masculine >> Rp Nsm: >> Part of speech: pronoun, relative Case: nominative Number: singular Gender: >> masculine >> Rr Nsm: >> Part of speech: pronoun, relative Case: nominative Number: singular Gender: >> masculine >> Rx Nsm: >> Part of speech: pronoun, relative Case: nominative Number: singular Gender: >> masculine >> >> Those "Rs Nsm" etc. kind of codes are in fact the keys that we collect in >> order to display them as a table of content for the user to choose from or >> click on in the a dictionary view. >> Now the problem is that I can't actually find a relation other than the text >> itself of the key ("Ra Nsm") for the morph code of TH8804. >> How do I get to "Ra Nsm" etc. for a code of TH8804 via SWORD API? >> >> >> >> Cheers, >> Manfred >> >> >> Am 17.02.2010 um 18:13 schrieb Troy A. Griffitts: >> >>> Nic, >>> >>> There are currently 2 primary ways frontends have implemented strongs/morph >>> functionality: >>> >>> 1) show the numbers in the text as clickable links; >>> 2) have the word itself be a clickable link which has both >>> strongs/morph/other data attached. >>> >>> These 2 methods usually dictate, at a lower level, 2 different methods: >>> >>> 1) have the lookup information embedded directly in the link, e.g., >>> action=showMorph&type=Greek&value=5589 >>> >>> 2) have the word id embedded in the link, and then do an entry attributes >>> lookup to obtain the relevant information, e.g., >>> >>> <span onclick="showWordData(1)">In</span> >>> >>> To see the data you can obtain from entry attributes once you have the word >>> id, have a look at sword/examples/cmdline/lookup, e.g., >>> >>> ./lookup KJV jn.1.1 >>> >>> >>> Basically, what it comes down to is WHERE you want the work to happen. All >>> of this information comes out of entry attributes at some point: either the >>> filter obtains it and puts it in the link, or your app obtains it and does >>> what it sees fit with it. >>> >>> You can see code which implement the lemma/morph/interlinear lookups in a >>> filter, located under sword/bindings/corba/orbitcpp/webmgr.hpp. This Word >>> Javascript filter set does the lookup from entry attributes and adds a tag >>> around words with linguistic markup. Here is the pertinent line of code >>> from the filter: >>> >>> text.appendFormatted("<span class=\"clk\" >>> onclick=\"p('%s','%s','%s','%s','%s','%s');\" >", lexName.c_str(), >>> lemma.c_str(), wordID.c_str(), morph.c_str(), page.c_str(), >>> modName.c_str()); >>> >>> This is how swordweb does word-click lookups and shows strongs, morph, >>> interlinear data, etc. (page, is the image page number for the Tregelles >>> GNT scans). >>> >>> I know this doesn't answer all of your questions, but hope it gets you >>> started. >>> >>> Troy. >>> >>> >>> Nic Carter wrote: >>>> Hi team :) >>>> I'm currently implementing morphology tags at the same time as Strong's in >>>> PocketSword & I have a question about the HTML filters. >>>> for THML (thmlhtmlhref.cpp) >>>> we have "passagestudy.jsp?action=showMorph&type=Greek&value=%s" (line >>>> 178) >>>> so, the "type" is hardcoded to "Greek". >>>> for GBF (gbfhtmlhref.cpp) >>>> we have "passagestudy.jsp?action=showMorph&type=Greek&value=" (line 207) >>>> so, the "type" is hardcoded to "Greek". >>>> for OSIS (the one we're mostly interested in now-a-days: osishtmlhref.cpp) >>>> we have "passagestudy.jsp?action=showMorph&type=%s&value=%s" (line 150) >>>> so, the "type" is variable, with an example from the KJV being: >>>> "passagestudy.jsp?action=showMorph&type=robinson%3AN-ASN&value=N-ASN" >>>> [note: %3A is the URL encoding of the ":" character, as this is coming >>>> from the OSIS w tag, where morph="robinson:N-ASN" is found, so we are >>>> simply passing through the "morph" attribute to the "type" attribute in >>>> this html link, after running it through URL::encode().] >>>> http://www.crosswire.org/wiki/OSIS_Bibles#Marking_with_Morphology is also >>>> a good place to read up on this, from an OSIS point of view. >>>> http://n4.nabble.com/new-morphology-td354696.html#a354696 has a previous >>>> thread about Morphology tags >>>> http://n4.nabble.com/KJV-OT-morphology-td351093.html#a351093 mentions OT >>>> Morph tags & how they were broken back then (are they still? if the >>>> situation is still the same today, then that may help answer question #1 & >>>> some of #2!) >>>> http://n4.nabble.com/Fwd-GnomeSword-developers-Hebrew-WLC-Text-with-Strongs-numbers-and-Morphology-td358831.html#a358831 >>>> mentions that there was no Hebrew Morphological Analysis Codes module as >>>> of March 2009, is that still the case? (that may also help answer >>>> question #1?) >>>> Given all of the above: >>>> 1) do we only support Morphology of Greek words? Looking in the KJV >>>> (OSIS), it seems they appear in the OT (hence, also for Hebrew words), and >>>> the "type" attribute is "strongMorph". For example, >>>> "passagestudy.jsp?action=showMorph&type=strongMorph%3ATH8804&value=TH8804" >>>> from Micah 1:16 (from the word "captivity", with the Strong's Hebrew >>>> Number of 01540). >>>> 2) should the OSIS version, above, have the "type" attribute actually >>>> being "robinson" (in the KJV example above) rather than >>>> "robinson%3AN-ASN"? or should it instead be hard-coded to be "Greek" like >>>> with the THML & GBF versions? I'm assuming it should be "robinson", given >>>> that's what the OSIS module says... so I'm guessing that the >>>> "strongMorph", found in question #1 is actually referring to a non-public >>>> (or non-existing?) module that has the Hebrew Morphology. >>>> 3) do other front-ends simply assume that we only call the "showMorph" >>>> action on Greek words & hence ignore the "type" attribute? Or do they (as >>>> I am currently thinking of doing) treat "Greek" to use a module with >>>> "Feature=GreekParse" & showMorph actions that start with "robinson" or >>>> "packard" to also be Greek & anything else to be Hebrew? Or do they treat >>>> "Greek" as Greek & anything else they parse the "type" attribute until >>>> they get to the ":" & then try to use that module, falling back to an >>>> error dialogue if that module isn't installed? >>>> 4) I am assuming that any module with "Feature=GreekParse" in it is able >>>> to handle Greek Morphology codes, so when we encounter a "showMorph" with >>>> a "type" containing "robinson", do we NEED to use the "robinson" module >>>> (which is the technically correct thing to do) or can I allow the user to >>>> select any module they have installed which has the "GreekParse" feature >>>> in it (the same as we do with Strong's Numbers)? But, then, linking with >>>> question #1, there is no equivalent for "Feature=HebrewParse"? at least, >>>> I can't find any modules from the CrossWire or CrossWire Beta repos with >>>> that in it? >>>> ok, I think that's about it! I enjoy trying to figure out fun SWORD >>>> things (well, now I do -- at first it was overwhelming, but I was learning >>>> the SWORD APIs & the CocoaTouch APIs & Obj-C all at the same time!), but >>>> I'd love clarification on this before I code it :) >>>> Thanks heaps for even reading this far. If you have read this far and can >>>> actually understand it all, you deserve a medal & you're probably also >>>> equipped enough to answer all my questions! ;) :) >>>> ybic >>>> nic... :) >>>> ---- >>>> Nic Carter >>>> PocketSword Developer - an iPhone Bible Study app >>>> http://crosswire.org/pocketsword >>>> _______________________________________________ >>>> sword-devel mailing list: [email protected] >>>> http://www.crosswire.org/mailman/listinfo/sword-devel >>>> Instructions to unsubscribe/change your settings at above page >>> >>> >>> _______________________________________________ >>> sword-devel mailing list: [email protected] >>> http://www.crosswire.org/mailman/listinfo/sword-devel >>> Instructions to unsubscribe/change your settings at above page >> >> >> _______________________________________________ >> sword-devel mailing list: [email protected] >> http://www.crosswire.org/mailman/listinfo/sword-devel >> Instructions to unsubscribe/change your settings at above page > > > _______________________________________________ > sword-devel mailing list: [email protected] > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
