You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(14) |
Oct
(7) |
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2005 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Kairos <ka...@an...> - 2005-01-10 12:14:11
|
Hi, ich habe unter folgenden Link im mybible /ZephaniaXML-Forum gepostet. http://forum.mybible.de/viewtopic.php?p=3D2510#2510 doch damit ihr es auf eurern Rechner zum Nachschlagen habt kommt hier nochm= als=20 die Mail. Besonders du, Carsten, k=F6nntest mal dr=FCberschauen. Ich will Siebie auch= noch=20 drauf ansprechen - aber vor der GrIII Pr=FCfung wird das wohl nichts. Au=DFerdem habe ich noch drei Fragen ge=E4u=DFert, hier sind sie: 1) W=FCrdet ihr es in Ordnung finden, wenn die Auszeichung der Sprachen mit= ISO=20 639 erfolgt: also grc f=FCr "Greek ancient"? - Ich bin in solchen Punkten i= mmer=20 f=FCr Standards.=20 =20 2) Was ist mit Worten, deren grammatische Form mehrdeutig ist? Soll dann di= e=20 wahrscheinlichste aus dem Kontext erschlossen werden oder sollen wir in der= =20 Enumerationen solche M=F6glichkeiten gleich ber=FCcksichtigen?=20 =20 3) W=E4re es nicht besser, wenn zb. Pr=E4postionen (pr=E4) und Pr=E4sens (p= r=E4s) lieber=20 ohne deutsche Umlaute geschrieben w=FCrden - dann erleichtern wir es andere= n=20 Nationalit=E4ten an Z-XML mitzuarbeiten. Mein Vorschlag: (pre) bzw. (pres)= =20 Und hier der Code: <xsd:complexType name=3D"T_GRAM" mixed=3D"true"> <xsd:choice minOccurs=3D"0" maxOccurs=3D"unbounded"> <xsd:element name=3D"GRAM" type=3D"T_GRAM" minOccurs=3D"0" maxOccurs=3D"unb= ounded"/> </xsd:choice> <xsd:attribute name=3D"woa" use=3D"required"> <!--Die Wortart--> <xsd:simpleType> <xsd:restriction base=3D"xsd:string"> <xsd:enumeration value=3D"grc-verb"> <!--Verb--> </xsd:enumeration> <xsd:enumeration value=3D"grc-subst"> <!--Substantiv--> </xsd:enumeration> <xsd:enumeration value=3D"grc-adj"> <!--Adjektiv--> </xsd:enumeration> <xsd:enumeration value=3D"grc-art"> <!--Artikel--> </xsd:enumeration> <xsd:enumeration value=3D"grc-pro"> <!--Pronomen--> </xsd:enumeration> <xsd:enumeration value=3D"grc-adv"> <!--Adverb--> </xsd:enumeration> <xsd:enumeration value=3D"grc-pr=E4"> <!--Pr=E4position--> </xsd:enumeration> <xsd:enumeration value=3D"grc-par"> <!--andere Partikel--> </xsd:enumeration> <xsd:enumeration value=3D"grc-konj"> <!--Konjunktion--> </xsd:enumeration> <xsd:enumeration value=3D"grc-subj"> <!--Subjunktionen--> </xsd:enumeration> <xsd:enumeration value=3D"grc-num"/><!--andere Partikel?--> <!--Numerale--> <!-- evtl. andere Partikel extra aufgef=FChrt; z.B.: <xsd:enumeration value=3D"grc-int"> <!--interjektionen </xsd:enumeration> <xsd:enumeration value=3D"grc-neg"> <!--Negationen </xsd:enumeration> =2D-> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name=3D"gen" use=3D"optional"> <!--Geschlecht--> <xsd:simpleType> <xsd:restriction base=3D"xsd:string"> <xsd:enumeration value=3D"grc-mask"/> <!--Maskulinum/M=E4nnlich--> <xsd:enumeration value=3D"grc-fem"/> <!--Femininum/Weiblich--> <xsd:enumeration value=3D"grc-neut"/> <!--Neutrum/S=E4chlich--> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name=3D"num" use=3D"optional"> <!--Numerus--> <xsd:simpleType> <xsd:restriction base=3D"xsd:string"> <xsd:enumeration value=3D"grc-sg"/> <!--Singular/Einzahl--> <xsd:enumeration value=3D"grc-pl"/> <!--Plural--> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name=3D"prs" use=3D"optional"> <!--Person--> <xsd:simpleType> <xsd:restriction base=3D"xsd:string"> <xsd:enumeration value=3D"grc-1"/> <!--1. Person--> <xsd:enumeration value=3D"grc-2"/> <!--2. Person--> <xsd:enumeration value=3D"grc-3"/> <!--3. Person--> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name=3D"diat" use=3D"optional"> <!--Diathese / Genus Verbi--> <xsd:simpleType> <xsd:restriction base=3D"xsd:string"> <xsd:enumeration value=3D"grc-akt"/> <!--Aktiv--> <xsd:enumeration value=3D"grc-med"/> <!--Medium--> <xsd:enumeration value=3D"grc-pass"/> <!--Passiv--> <xsd:enumeration value=3D"grc-mp"/> <!--Mediopassiv--> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name=3D"kas" use=3D"optional"> <!--Der Fall--> <xsd:simpleType> <xsd:restriction base=3D"xsd:string"> <xsd:enumeration value=3D"grc-nom"/> <!--Nominativ--> <xsd:enumeration value=3D"grc-gen"/> <!--Genitiv--> <xsd:enumeration value=3D"grc-dat"/> <!--Dativ--> <xsd:enumeration value=3D"grc-akk"/> <!--Akkusativ--> <xsd:enumeration value=3D"grc-vok"/> <!--Vokativ--> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name=3D"inf" type=3D"xsd:string" use=3D"optional"/> <!--W=F6rterbuchform--> <xsd:attribute name=3D"tmp" use=3D"optional"> <!--Tempus / bzw. Aspekt--> <xsd:simpleType> <xsd:restriction base=3D"xsd:string"> <xsd:enumeration value=3D"grc-pr=E4s"/> <!--Pr=E4sens--> <xsd:enumeration value=3D"grc-aor"/> <!--Aorist--> <xsd:enumeration value=3D"grc-perf"/> <!--Perf--> <xsd:enumeration value=3D"grc-fut"/> <!--Futur--> <xsd:enumeration value=3D"grc-plqp"/> <!--Plusquamperfekt--> <xsd:enumeration value=3D"grc-ipf"/> <!--Imperfekt--> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name=3D"sta" type=3D"xsd:string" use=3D"optional"/> <!--Wortstamm (im grc parallel zu strongs --> <xsd:attribute name=3D"mod" use=3D"optional"> <!--Modus--> <xsd:simpleType> <xsd:restriction base=3D"xsd:string"> <xsd:enumeration value=3D"grc-ind"/> <!--Indikativ--> <xsd:enumeration value=3D"grc-konj"/> <!--Konjunktiv--> <xsd:enumeration value=3D"grc-imp"/> <!--Imperativ--> <xsd:enumeration value=3D"grc-opt"/> <!--Optativ--> <xsd:enumeration value=3D"grc-inf"/> <!--Infinitiv--> <xsd:enumeration value=3D"grc-ptz"/> <!--Partizip--> </xsd:restriction> </xsd:simpleType> </xsd:attribute> <xsd:attribute name=3D"str" type=3D"xsd:string" use=3D"optional"/> </xsd:complexType> =2D-=20 <>< Markus Karzelek=09 developing free bible software join www.anakrino.de ><> |
From: kairos [m. karzelek] <ka...@an...> - 2004-10-11 12:36:50
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ich denke, dass wir mit der Frage nach der Suchf=E4higkeit ein wenig warten sollten (ja, ich wei=DF, f=E4llt mir fr=FCh ein), bis wir endg=FCltig die F= rage der XML gel=F6st haben. Denn z.B: ZefaniaXML benutzt eine andere Auszeichnung f= =FCr die Grammatik als wir es bisher angedacht hatten. Es sei denn, dass es f=FCr dich eh keine Rolle spielt, wie die grammatische Information in der XML letztendlich steht. Dann k=F6nnen wir getrost weiter machen. kairos =DCbrigens: schau dir mal folgendes Bild an, kelko, und dort vor allem die Suchsyntax! http://www.mybible.de/de/screenshots/mybible6.png =2D -- <>< GEGEN Software-Patente: http://petition.eurolinux.org/index.de.html Homepage: http://markus.karzelek.com/ GnuPG-Key: markus.karzelek.com/vorstellung/wie.html ><> =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBan5iYvkFR0eSpKARAgzCAJ9skxIcipRJ5fltTKuTgSsAQCBrxQCgr7Ds uuv23cSwTNb/giCfqV1HGkI=3D =3DqX4u =2D----END PGP SIGNATURE----- |
From: Markus K. <ma...@ka...> - 2004-10-11 12:02:52
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ich denke, dass wir mit der Frage nach der Suchf=E4higkeit ein wenig warten sollten (ja, ich wei=DF, f=E4llt mir fr=FCh ein), bis wir endg=FCltig die F= rage der XML gel=F6st haben. Denn z.B: ZefaniaXML benutzt eine andere Auszeichnung f= =FCr die Grammatik als wir es bisher angedacht hatten. Es sei denn, dass es f=FCr dich eh keine Rolle spielt, wie die grammatische Information in der XML letztendlich steht. Dann k=F6nnen wir getrost weiter machen. kairos =DCbrigens: schau dir mal folgendes Bild an, kelko, und dort vor allem die Suchsyntax! http://www.mybible.de/de/screenshots/mybible6.png =2D -- <>< GEGEN Software-Patente: http://petition.eurolinux.org/index.de.html Homepage: http://markus.karzelek.com/ GnuPG-Key: markus.karzelek.com/vorstellung/wie.html ><> =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBanZBhIRrwW8Jjt0RAgi+AJ9BdM1DhhaHMDaVwMi42CcOTVvflgCg0K0X LogdwH0BERL/HcOHMbrWrEs=3D =3DkkOV =2D----END PGP SIGNATURE----- |
From: kairos [m. karzelek] <ka...@an...> - 2004-10-09 16:10:58
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 9. Oktober 2004 12:42 schrieb Gregor :kelko: Karzelek: > W=FCrde es in euren Augen verst=E4ndlich sein, wenn man f=FCr eine > "und"-Verkn=FCpfung ein '&' nutzen muss? Ist f=FCr mich kein Problem. f=FCr mich stellt sich eher die Frage, ob man etwas anders anstatt "|" nehm= en k=F6nnte - zum beispiel "/"? wenn du es aber schon woanders vorgesehen hast oder ein anderer Grund dagegen spricht , dann nicht. Der Grund meiner =DCberlegung ist, dass das "|" eher unbekannt ist f=FCr die meisten User und das Schr=E4grstrich durchaus die Funktion "oder" im Alltag erf=FCllt. Eine andere Frage: hast du es vorgesehen, eine "nicht (in)" Funktion einzurichten: also z.B. suche alle stellen, in denen dieses Wort ohne jenes Wort vorkommt "find a & b -[oder \] c" oder so in die Richtung? bzw. "search a in elb & schl - [\] lut" oder =E4hnlich. kairos =2D -- <>< kairos / markus karzelek Developing free bibel software join anaKrino :: www.anaKrino.de ><> =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBaA2DYvkFR0eSpKARAt26AJ49atv94v8LwB1JvDeodEjuQcT9TACfakct EVWV+FU1lDyj5g4ah41nrFc=3D =3D8iKp =2D----END PGP SIGNATURE----- |
From: Gregor :k. K. <ke...@an...> - 2004-10-09 10:38:54
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mal ne Frage an die potenziellen Nutzer: > Dabei bedeutet "+" soviel wie "und" > und "|" soviel wie "oder" W=FCrde es in euren Augen verst=E4ndlich sein, wenn man f=FCr eine "und"-Ve= rkn=FCpfung=20 ein '&' nutzen muss? Das Zeichen hei=DFt ja schon "kaufm=E4nnisches und". =46=FCr mich macht es eher Sinn '&' und '|' als Operatoren zu nutzen, da di= ese in=20 der Informatik f=FCr eben "und" und "oder" stehen, '+' benutzt man meist ni= cht=20 f=FCr logische Operationen, und wenn doch, dann als "oder", mit einem=20 "mal-punkt" als "und". Die =C4nderung m=FCsste halt jetzt =FCberlegt werden, da ich grade den =DCb= ersetzer =20 einfache->komplexe Suche schreibe. kelko =2D --=20 anaKrino bible study Gregor :kelko: Karzelek :: ke...@an... Projektmitbegr=FCnder=20 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBZ8CTYvkFR0eSpKARAineAKCciKUmzjuW8s2sL40LEWLu6meLIgCdEzn3 4s6f+PL4f0dvjyxKevjzFnQ=3D =3DfbOs =2D----END PGP SIGNATURE----- |
From: karl k. <ka...@an...> - 2004-10-01 12:52:44
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ich habe mich bezüglich Urheberrechte etwas kundig gemacht und das gefunden: >>UrhG § 70 Wissenschaftliche Ausgaben (1) Ausgaben urheberrechtlich nicht geschützter Werke oder Texte werden in entsprechender Anwendung der Vorschriften des Ersten Teils geschützt, wenn sie das Ergebnis wissenschaftlich sichtender Tätigkeit darstellen und sich wesentlich von den bisher bekannten Ausgaben der Werke oder Texte unterscheiden. (2) Das Recht steht dem Verfasser der Ausgabe zu. (3) Das Recht erlischt fünfundzwanzig Jahre nach dem Erscheinen der Ausgabe, jedoch bereits fünfundzwanzig Jahre nach der Herstellung, wenn die Ausgabe innerhalb dieser Frist nicht erschienen ist. Die Frist ist nach § 69 zu berechnen.<< Ich finde das sieht interessant aus und ich denke mal, der NA fällt unter diesen Paragraphen. Das heißt, dass die allerersten Ausgaben des NA26, der ja 1979 veröffentlicht wurde, so weit ich weiß, und alle davor, dieses oder spätestens nächstes Jahr den Anspruch auf Rechteschutz verlieren. Auf die revidierten späteren Drucke des NA26 kann ich keine Garantie geben. Aber da Veränderungen vorgenommen wurden am Text muss man bei ihnen noch ein bißchen warten. Also, es sieht danach aus, dass wir den Text des NA26 verwenden werden können, ohne Zustimmung der DBG. natürlich wäre es cool, wenn die uns den Text kostenlos zur Verfügung stellen würde. Wenn aber nicht, dann haben wir den NA26, zumindestmal den Text an sich, zur Verfügung, der ja eigentlich textgleich ist mit dem NA27. Wie das mit dem kritischen Apparat aussieht weiß ich noch nicht. Generell kann ich aber nicht sagen, ob sich das alles auch 100% so verhält, wie beschrieben. Da werde ich noch nachbohren müssen. GFS - -- http://karl.karzelek.com || Blog >> http://meinsenf.blogspot.com PGP :: http://karl.karzelek.com/pgp.htm >> think secure! reg. Linux User: #214057 (http://counter.li.org) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBXVSbYvkFR0eSpKARAtPSAJ9Zx8VtN23WafiKSRo08Osv0jMNIACfRvSI x4YcOk1A9YonSWzQIb3tc8g= =86qw -----END PGP SIGNATURE----- |
From: Gregor :k. K. <ke...@an...> - 2004-10-01 12:21:24
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > > Zu dem "Metatext": > > > Die =DCberlegung war folgender Ma=DFen: > > > Eine Art Tabelle > > > <strong> > > > <morph> > > > <vers/> > > > <vers/> > > > <vers/> > > > </morph> > > > <morph> > > > <vers/> > > > <vers/> > > > <vers/> > > > </morph> > > > <strong> > > > ... > > > Und erst wenn man im Suchfeld auf entsprechenden Vers klickt kommt ja > > > der eigentliche Text, und der wird halt gleich in der =DCbersetzung d= er > > > Wahl angezeigt. > > Ja und Nein. > Die Idee mit einer Tabelle finde ich nicht schlecht. Dennoch muss aber der > TAG mit der Strong's Nummer im Bibeltext/Urtext erscheinen. > Wenn ich n=E4mlich per MouseOverOn =FCber ein griechisches oder deutsches= Wort > gehen will, dann sollte im Info-Fenster ja der entsprechende Eintrag > erscheinen (mit Strong's Nummer, Morphologie und =DCbersetzung). > > > Wenn du es jedoch nur in der Tabelle hast, dann geht das nicht, oder? > Oder habe ich dich falsch verstanden? =D6hm, leicht falsch Verstanden. _Nat=FCrlich_ muss im Text zu jedem Wort/Begriff die Strong's eincodiert se= in,=20 damit man im AI-Fenster die Infos dazu sehen kann, diese Tabelle oben, ist= =20 nur und einzig f=FCr die Suche gedacht, damit diese schneller geht. > Au=DFerdem w=E4re es gut, wenn die gefunden Stellen/Worte markiert w=FCrd= en. Klar. kelko =2D --=20 anaKrino bible study Gregor :kelko: Karzelek :: ke...@an... Projektmitbegr=FCnder=20 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBXp29YvkFR0eSpKARAq0GAKC9juq7KZhfvKGnZL9RDyPXSsirtgCgw/u9 Rsph0ToCWlVwyKv3kttL1Kg=3D =3D47Ig =2D----END PGP SIGNATURE----- |
From: Gregor :k. K. <ke...@an...> - 2004-10-01 12:19:22
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So,=20 melde ich mich auch mal wieder zu Wort. > Mein Vorschlag: lass die Anf=FChrungsstriche weg. Stattdessen lieber > festlegen, dass die Stellenangabe ohne Leerzeichen geschrieben werden; z.= B: > 1Mos > 1Mos1 > 1Mos1 - 1Mos5 > 1Mos1,1 - 1Mos1,10 Klar. > Dabei nur einige wichtige definieren. > AT; NT > Th(ora); Pro(pheten), Po(esie); Ge(schichte), bzw: > Th(ora); Pro(pheten)/Ke(tubim), Sch(riften)/Ne(biim) [im Urtext nach > hebr=E4ischer Unterteilung] > Ev(angelien); Sy(noptiker); Br(iefe); evtl: Hi(storisch): Ev + Apg. > Offb. eh einzeln. Da m=FCsst ihr sagen, welche ihr wollt und welchen Bereich die alles=20 einschlie=DFen. > > "Elb" | "Luth" <- Es muss in einem der beiden das gesuchte stehen. > > "Elb" | Luth" + "Schl" <- Das w=FCrde folgend gelesen: > > (( "Elb" | "Luth" ) + "Schl" ) <- Also entweder in Elb oder Luth, und= =20 > > in Schl. > > also von links nach rechts? Genau. > > Nun der eigentliche Grund f=FCr diese Mail: > > Wir wollen noch nach Strong's und Morphologien suchen k=F6nnen. > > Ich denke, dass es eine Unterscheidung geben muss, ob ich nach dem Wort > anakrino suche bzw. nach der 3.Sg. anakrinei oder ob ich nach allen Worten > suche, die als Stammform anakrino haben. > > Wenn ich also einfach eingebe search anakrino, dann sollte er zun=E4chst = nur > die 1.Sg.Pr=E4s. ... finden - mein Vorschlag. > Wenn ich dagegen alle Worte mit Wurzel anakrino suchen m=F6chte, dann m= =FCsste > ich das mit entsprechendem Befehl markieren: (search rt anakrino) [rt f= =FCr > root)]. > > Wenn ich also nach allen Vorkommen von anakrino im Imperativ suche, dann > m=FCsste ich in etwa folgendes eingeben: > (search rt anakrino:*r* ) Ajo, deshalb gibt es doch die unterscheidung zwischen (word XXX) und (gram= =20 XXX) oder wie auch immer das zweite genannt werden soll. Bei (word ) suchst du _genau_ das Wort, in dem Modul, dass angegeben ist (o= der=20 in den default-modulen). Bei der zweiten Suche suchst du nach allen W=F6rtern mit angegebener Grundf= orm,=20 oder nach Grundform + Morphologie (mit Wildcards). Wobei ihr mir da noch n Begriff nennen m=FCsst, wie man zweite Suche benenn= en=20 kann. Erste ist ja eine Wortsuche, deshalb (word ), was ist das zweite? Ich meine, dass es prinzipiell so geht, wie in Ursprungsmail beschrieben, h= abe=20 ich ja jetzt rausgefunden. Die Frage ist: W=E4re das akzeptabel von eurer=20 Seite? Oder gute Argumente dagegen? > Das setzt voraus, dass wir einen festen Code f=FCr Morphologien haben, wo= bei > die Reihenfolge festgelegt ist: z.B.: > v(erb) (impe)r(ativ) p(r=E4sens) a(ktiv) 2(Person) s(ingular) > wenn jeder Buchstabe nur einmal vorkommt, k=F6nnte man auch mit wildcards > suchen (s.o.!) - ansonsten dann halt f=FCr jede Stelle, die egal ist einen > Bindestrich /ein Fragezeichen. (vr----) 1. Ich w=FCrde sagen, jede Stelle muss "ausgef=FCllt" sein, und sei es mit = einem=20 Minus. 2. Ihr m=FCsst mir dann genau sagen, zu was f=FCr Worttypen (Verb, Nomen, .= =2E..)=20 gibt es jeweils wieviele "morphologische Informationen". Muss ich wissen. > Der Doppelpunkt w=FCrde den =DCbergang von der Stammform zu der Morpholog= ie > bedeuten. Das mit der Doppelpunkt-notation w=FCrde ich in der einfachen Form machen, = nicht=20 in der Komplexen. Dass w=FCrde die logische Struktur zerst=F6ren, was die=20 Benutzung nur erschwert. Bei der einfachen Suche kann man es dagegen schon so halten, dass man statt= =20 einem Wort eine Stammform:Morphologie angibt, sofern das Sinn macht. kelko =2D --=20 anaKrino bible study Gregor :kelko: Karzelek :: ke...@an... Projektmitbegr=FCnder=20 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBXp1CYvkFR0eSpKARAronAJ9r+gZChwoJ3bJfM1iQbNI0Q4EcOACfWO3f ZsHKYN/pu16r+kRVwaHX4kg=3D =3DStnQ =2D----END PGP SIGNATURE----- |
From: Carsten Z. <ca...@cm...> - 2004-09-30 14:58:30
|
Am Donnerstag, 30. September 2004 16:57 schrieb karl karzelek: > > "Q" f=FCr die Logienquelle Q nicht vergessen, ganz wichtig f=FCr unser > wissenschaftliches Publikum ;-) > Dann sollten wir auch zwischen Proto- und Deuteropaulinen unterscheiden ;-) =2D-=20 Carsten Ziegert http://www.cmziegert.org |
From: karl k. <ka...@an...> - 2004-09-30 14:51:19
|
Am Donnerstag, 30. September 2004 00:45 schrieb kairos [markus karzelek]: > Dabei nur einige wichtige definieren. > AT; NT > Th(ora); Pro(pheten), Po(esie); Ge(schichte), bzw: > Th(ora); Pro(pheten)/Ke(tubim), Sch(riften)/Ne(biim) [im Urtext nach > hebr=E4ischer Unterteilung] > Ev(angelien); Sy(noptiker); Br(iefe); evtl: Hi(storisch): Ev + Apg. > Offb. eh einzeln. "Q" f=FCr die Logienquelle Q nicht vergessen, ganz wichtig f=FCr unser=20 wissenschaftliches Publikum ;-) > Soweit mein Senf ^^^^^^^ Ich glaub ich muss ein TM drauf anmelden. Heute l=E4sst man sich ja alles=20 registrieren, wieso nicht auch den Namen eines Blogs :gg: GFS P.S.: eine sinnvollere Antwort kommt vielleicht auch noch mal ;-) =2D-=20 http://karl.karzelek.com || Blog >> http://meinsenf.blogspot.com PGP :: http://karl.karzelek.com/pgp.htm >> think secure! reg. Linux User: #214057 (http://counter.li.org) |
From: kairos [m. karzelek] <ka...@an...> - 2004-09-29 22:40:48
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 29. September 2004 20:02 schrieb Carsten Ziegert: > > Desweiteren war es halt meinerseits so gedacht, dass die morph- und > > Strong's-Suche auf dem Grundtext oder einem "Metatext" gesucht wird, > > nicht auf einer =DCbersetzung. W=FCrde halt bedeuten man k=F6nnte nie n= ach > > "Heilig" suchen sondern m=FCsste das griechische Wort dazu kennen. Ich w=FCrde es halt trennen: wenn jemand nach "Heilig" sucht, dann sucht er= nach dem deutschen Wort heilig. Wenn jemand nach dem griechischen Wort f=FCr Heilig suchen will, dann muss = er halt die STrong's Nummer oder das/eines der/ griechischen Worte in der W=F6rterbuch-Form kennen. > Man m=FCsste wahrscheinlich den Text mit Strong-Nummern taggen, sowohl den > Grundtext als auch die =DCbersetzungen. Ich meine, sil.org (Wyclif) hat s= owas > schon gemacht (in XML), da werde ich mal recherchieren. Strong's Nummer w=E4re wohl das einfachste - vor allem, weil es Public Doma= in ist. > Wenn der Benutzer "gut" eingibt, findet man im deutschen getaggten Text > (oder gleich in einer DB) die Strong-Nummern f=FCr agathos und f=FCr kalo= s. > Die findet man dann im griechischen Text und auch im deutschen, unabh= =E4ngig > davon, ob das Wort hier wirklich mit "gut" =FCbersetzt wurde oder mit > "sch=F6n". Das w=E4re meine Idee f=FCr eine Art "Interlinear-Suche". Einerseits finde ich das gut, andererseits denke ich, m=FCssen wir aufpasse= n, dass der Benutzer nicht zu sehr verwirrt wird. Mein Vorschlag: Wenn der Besucher nach "gut" sucht, dann bekommt er das zun=E4chst f=FCr se= ine deutsche =DCbersetzung, die er aktuelle offen hat /bzw. welches er angegeben hat/. In einem extra-Fenster oder so =E4hnlich k=F6nnten dann die entsprechenden Strong's-Nummern erscheinen, die es ihm erm=F6glichen, die Suche entspreche= nd der griechischen Worte weiterzuf=FChren. Bzw. wenn er die Strong's Nummer einschaltet, sodass er sie sehen kann, dann kann er per Doppelklick einfach nach allen Vorkommen in der ganzen Bibel suchen. > > angenommen der User sucht nach "Heilig", dann w=FCrde das Prog halt guc= ken, > > was steht im Text bei Heilig f=FCr n Strong's oder f=FCr ne Grundform, = und > > dann wird auf eben erw=E4hntem Metatext nach allen Vorkommnissen dieser > > Grundform gesucht, dann w=E4re "Heiligen" und "Heiliger" doch auch glei= ch > > dabei, oder hab ich da jetzt was falsch verstanden? > > Das Verb hagiazo w=E4re noch nicht dabei, das hat ne andere Strong-Nummer. > Aber mit der Morphologie-Komponente k=F6nnte man es ableiten. Soweit ich es in Erinnerung habe, steht das immer mit dabei. Beispiel: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D <1253> dia,krisij (diakrisis) Meaning: the act of judgment Origin: from 1252 Usage: discern(1), distinguishing(1), passing judgment(1). Notes: (1) Lit., effects (2) Or, works of power (3) Lit., distinguishings = (a) 1Co 12:28f.; Gal 3:5 (b) 1Co 11:4; 1Co 13:2, 1Co 13:8 (c) 1Co 14:29; 1Jo 4= :1 (d) Mar 16:17; 1Co 12:28, 1Co 12:30; 1Co 13:1; 1Co 14:2ff. (e) 1Co 12:30; 1Co 14:26 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Man m=FCsste dann bei origin entweder einen Link einsetzen oder gleich in d= er Tabelle diese Querweise erg=E4nzen. > > Zu dem "Metatext": > > Die =DCberlegung war folgender Ma=DFen: > > Eine Art Tabelle > > <strong> > > <morph> > > <vers/> > > <vers/> > > <vers/> > > </morph> > > <morph> > > <vers/> > > <vers/> > > <vers/> > > </morph> > > <strong> > > ... > > Und erst wenn man im Suchfeld auf entsprechenden Vers klickt kommt ja d= er > > eigentliche Text, und der wird halt gleich in der =DCbersetzung der Wahl > > angezeigt. Ja und Nein. Die Idee mit einer Tabelle finde ich nicht schlecht. Dennoch muss aber der = TAG mit der Strong's Nummer im Bibeltext/Urtext erscheinen. Wenn ich n=E4mlich per MouseOverOn =FCber ein griechisches oder deutsches W= ort gehen will, dann sollte im Info-Fenster ja der entsprechende Eintrag erscheinen (mit Strong's Nummer, Morphologie und =DCbersetzung). Wenn du es jedoch nur in der Tabelle hast, dann geht das nicht, oder? Oder habe ich dich falsch verstanden? Au=DFerdem w=E4re es gut, wenn die gefunden Stellen/Worte markiert w=FCrden. Soweit mein Senf kairos =2D --=20 <>< kairos / markus karzelek Developing free bibel software join anaKrino :: www.anaKrino.de ><> =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWzs+YvkFR0eSpKARAlqXAKCTWsd7e9cvXmRVJ8yKNJm2MGuFNQCgyGIr LGPPegmJOGO/kGDkUiWgfTU=3D =3DHK5o =2D----END PGP SIGNATURE----- |
From: kairos [m. karzelek] <ka...@an...> - 2004-09-29 22:40:48
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 25. September 2004 11:20 schrieb Carsten Ziegert: > Ich w=FCrde schon bei der Wortsuchen die gesamte Morphologie abdecken, d.= h. > wenn der User "Heilig + Geist" eingibt, dann "Heiligen Geist" genauso > finden wie "(mit) Heiligem Geist". Hm, ich w=FCrde das - wie gerade in der anderen Mail beschrieben - lieber trennen. damit, wenn jemand wirklich nur "Heiliger Geist" haben m=F6chte, a= uch nur "Heiliger Geist" bekommt. Wenn er jedoch nach allen anderen =E4hnlich Formen sucht, dann mit wildcards etc. suchen lassen. oder anders herum: es wird generell nach allen m=F6glichkeiten gesucht - we= nn er aber nur "Heiliger Geist" suchen will, dann mit Anf=FChrungstrichen markier= en. Das setzt aber voraus, dass er ein Auswahlfenster erh=E4lt, in der er die gesuchten und gefundenen M=F6glichkeiten sieht und dort entsprechend die von ihm gewollten anklicken kann. kairos =2D -- <>< kairos / markus karzelek Developing free bibel software join anaKrino :: www.anaKrino.de ><> =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWztXYvkFR0eSpKARAtHlAKC+hnUhaOE21jGmY3Lg35SDkaCH8gCcDypC 2H2bTktPI6rzLlaeufwVebY=3D =3DMyEx =2D----END PGP SIGNATURE----- |
From: kairos [m. karzelek] <ka...@an...> - 2004-09-29 22:40:48
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 25. September 2004 19:29 schrieb Gregor :kelko: Karzelek: > Naja, letztlich sind deshalb zwei verschiedene Formen zum Suchen > entstanden, eine einfache und eine komplexe. wobei ja die einfache nur eine "Maske" f=FCr die schwierige w=E4re, gel? F= =FCr das Backend w=E4re es also egal, nur der Benutzer w=FCrde einen Unterschied mer= ken. Deshalb auch mein Vorschlag es als "find" und "search" zu trennen. > Y steht f=FCr den Bereich in dem man suchen will. > M=F6glich ist eine Angabe in Anf=FChrungszeichen, > eine Bereichsangabe, oder eine Liste von beidem. > M=F6glich w=E4ren: > > "1Mos1" > "1Mos1" - "1Mos5" > "1Mos" > "1Mos" - "Jes" > "1Mos" - "Jes" | "Math" > "1Mos" - "5Mos" | "Math" - "Joh" Mein Vorschlag: lass die Anf=FChrungsstriche weg. Stattdessen lieber festle= gen, dass die Stellenangabe ohne Leerzeichen geschrieben werden; z.B: 1Mos 1Mos1 1Mos1 - 1Mos5 1Mos1,1 - 1Mos1,10 > Und so weiter. > Dabei wird es bestimmte Begriffe wie "AT" oder so geben, die fest > vordefiniert sind und einen bestimmten Bereich meinen. Dabei nur einige wichtige definieren. AT; NT Th(ora); Pro(pheten), Po(esie); Ge(schichte), bzw: Th(ora); Pro(pheten)/Ke(tubim), Sch(riften)/Ne(biim) [im Urtext nach hebr=E4ischer Unterteilung] Ev(angelien); Sy(noptiker); Br(iefe); evtl: Hi(storisch): Ev + Apg. Offb. eh einzeln. > Und "Z" ist die Modulangabe, also die Angabe in welchen Texten gesucht > werden soll. > Dabei kann man die Modulnahmen =E4hnlich wie die Suchw=F6rter verbinden. > M=F6glich w=E4ren: > "Elb" + "Luth" <- Es muss in Elberfelder und Luther im selben Vers das > gesuchte stehen Auch hier w=FCrde ich die Anf=FChrungsstriche weglassen. > "Elb" | "Luth" <- Es muss in einem der beiden das gesuchte stehen. > "Elb" | Luth" + "Schl" <- Das w=FCrde folgend gelesen: > (( "Elb" | "Luth" ) + "Schl" ) <- Also entweder in Elb oder Luth, und in > Schl. also von links nach rechts? > Nun der eigentliche Grund f=FCr diese Mail: > Wir wollen noch nach Strong's und Morphologien suchen k=F6nnen. Ich denke, dass es eine Unterscheidung geben muss, ob ich nach dem Wort anakrino suche bzw. nach der 3.Sg. anakrinei oder ob ich nach allen Worten suche, die als Stammform anakrino haben. Wenn ich also einfach eingebe search anakrino, dann sollte er zun=E4chst nu= r die 1.Sg.Pr=E4s. ... finden - mein Vorschlag. Wenn ich dagegen alle Worte mit Wurzel anakrino suchen m=F6chte, dann m=FCs= ste ich das mit entsprechendem Befehl markieren: (search rt anakrino) [rt f=FCr roo= t)]. Wenn ich also nach allen Vorkommen von anakrino im Imperativ suche, dann m=FCsste ich in etwa folgendes eingeben: (search rt anakrino:*r* ) Das setzt voraus, dass wir einen festen Code f=FCr Morphologien haben, wobe= i die Reihenfolge festgelegt ist: z.B.: v(erb) (impe)r(ativ) p(r=E4sens) a(ktiv) 2(Person) s(ingular) wenn jeder Buchstabe nur einmal vorkommt, k=F6nnte man auch mit wildcards s= uchen (s.o.!) - ansonsten dann halt f=FCr jede Stelle, die egal ist einen Bindestrich /ein Fragezeichen. (vr----) Der Doppelpunkt w=FCrde den =DCbergang von der Stammform zu der Morphologie bedeuten. Wer anstatt der W=F6rterbuch form: 1.Sg .... lieber die Strong's Number tip= pt, darf das auch gerne tun. Soweit mein Senf kairos =2D --=20 <>< kairos / markus karzelek Developing free bibel software join anaKrino :: www.anaKrino.de ><> =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWzsgYvkFR0eSpKARAtvYAJwKPMpPF1I3V4lTN5TL6HDO+NfC9gCfUot3 t8FJCezZBwWJqAof+7TZM50=3D =3D09IV =2D----END PGP SIGNATURE----- |
From: kairos [m. karzelek] <ka...@an...> - 2004-09-29 22:40:48
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Mittwoch, 29. September 2004 20:02 schrieb Carsten Ziegert: > Vielleicht gibt es ein maschinelles Strong-W=F6rterbuch schon lizenzfrei.= WER > MAG MAL RECHERCHIEREN?! Ich versuche mal, mich schlau zu machen kairos =2D --=20 <>< kairos / markus karzelek Developing free bibel software join anaKrino :: www.anaKrino.de ><> =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWztGYvkFR0eSpKARAtHGAJ9wsLkM7G0BvmZFdDr4cnYn7sxllwCaAmAF E8meXSrRiDioBich+v1iY0g=3D =3DA5zC =2D----END PGP SIGNATURE----- |
From: Karl K. <ka...@an...> - 2004-09-29 18:55:24
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Carsten Ziegert schrieb: | |>Zu dem "Metatext": |>Die Überlegung war folgender Maßen: |>Eine Art Tabelle |><strong> |> <morph> |> <vers/> |> <vers/> |> <vers/> |> </morph> |> <morph> |> <vers/> |> <vers/> |> <vers/> |> </morph> |><strong> |> |>Das hätte den Vorteil, man müsste nicht jedes mal ganzen Urtext |>durchsuchen, sondern hätte hier eine Tabelle, die einen schnelleren Zugriff |>erlaubt. Und selbst wenn man nach Morph ohne Grundform sucht ginge das, da |>man einfach in jedem Strong's nach entsprechendem Morph-Tag sucht. |> | | | Gute Idee. Ich habe schon die XML-Datenbank eXist am Laufen und den | Rehkopf-Inhalt (1100 Wörter) drin, die müsste man "nur" um die Strongs | erweitern. Verseingaben kriegt man durch Preprocessing auf dem Grundtext. | | Vielleicht gibt es ein maschinelles Strong-Wörterbuch schon lizenzfrei. WER | MAG MAL RECHERCHIEREN?! Nun, das sword Project hat strongs als Modul. Das ist Public Domain, d.h. Allegemeingut. Die könnte man verwenden. Entweder, wenn wir deren ML nehmen oder in eine andere umformen. Ein Problem dort ist halt, dass griechische Wörter nur in Umschrift erscheinen. Da müsste man halt schauen, wie man das hinkriegt, das die in griechisch angezeigt werden. GFS -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBWwaLYvkFR0eSpKARAqD/AKCA1fk+54eTmWP5tk14LEG0owwTzgCdGHnP cUeN5bFGoJGdWsF9+HCQN+I= =dC52 -----END PGP SIGNATURE----- |
From: Carsten Z. <ca...@cm...> - 2004-09-29 18:02:23
|
Am Dienstag, 28. September 2004 23:23 schrieb Gregor :kelko: Karzelek: > > Ich w=FCrde schon bei der Wortsuchen die gesamte Morphologie abdecken, = d.h. > > wenn der User "Heilig + Geist" eingibt, dann "Heiligen Geist" genauso > > finden wie "(mit) Heiligem Geist". > > Das setzt voraus, dass entweder 1. im Bibeltext jede Wortform an die > > Grundform gekettet ist (was eine schnellere Suche ergeben w=FCrde, aber > > viel Arbeit im Vorfeld bedeutet) oder dass 2. bei der Suche alle > > m=F6glichen Wortformen von der eingegebenen Grundform zun=E4chst abgele= itet > > werden (--> "Morphologie-Generierungs-Komponente"), die dann alle im > > textkorpus gesucht werden. > > Eine dritte Alternative: Man speichert die Grundformen im Text selbst > > (1.), l=E4sst sie aber maschinell generieren (d.h. wie in 2.: > > Morphologie-Generierungs-Komponente mit JEDER Grundform auf den Text > > loslassen und an die gefundenen Wortformen die gesuchte Grundform > > maschinell anketten). > > Hm, die Idee ist keinesfalls schlecht, nur w=E4re zu gucken, wie schwer d= ie > Implementierung w=E4re. ich arbeite dran ... > > Desweiteren war es halt meinerseits so gedacht, dass die morph- und > Strong's-Suche auf dem Grundtext oder einem "Metatext" gesucht wird, nicht > auf einer =DCbersetzung. W=FCrde halt bedeuten man k=F6nnte nie nach "Hei= lig" > suchen sondern m=FCsste das griechische Wort dazu kennen. Man m=FCsste wahrscheinlich den Text mit Strong-Nummern taggen, sowohl den= =20 Grundtext als auch die =DCbersetzungen. Ich meine, sil.org (Wyclif) hat sow= as=20 schon gemacht (in XML), da werde ich mal recherchieren. Wenn der Benutzer "gut" eingibt, findet man im deutschen getaggten Text (od= er=20 gleich in einer DB) die Strong-Nummern f=FCr agathos und f=FCr kalos. Die f= indet=20 man dann im griechischen Text und auch im deutschen, unabh=E4ngig davon, ob= das=20 Wort hier wirklich mit "gut" =FCbersetzt wurde oder mit "sch=F6n". Das w=E4= re meine=20 Idee f=FCr eine Art "Interlinear-Suche". > Hm, moment ... > angenommen der User sucht nach "Heilig", dann w=FCrde das Prog halt gucke= n, > was steht im Text bei Heilig f=FCr n Strong's oder f=FCr ne Grundform, un= d dann > wird auf eben erw=E4hntem Metatext nach allen Vorkommnissen dieser Grundf= orm > gesucht, dann w=E4re "Heiligen" und "Heiliger" doch auch gleich dabei, od= er > hab ich da jetzt was falsch verstanden? Das Verb hagiazo w=E4re noch nicht dabei, das hat ne andere Strong-Nummer. = Aber=20 mit der Morphologie-Komponente k=F6nnte man es ableiten. > > Zu dem "Metatext": > Die =DCberlegung war folgender Ma=DFen: > Eine Art Tabelle > <strong> > <morph> > <vers/> > <vers/> > <vers/> > </morph> > <morph> > <vers/> > <vers/> > <vers/> > </morph> > <strong> > > Das h=E4tte den Vorteil, man m=FCsste nicht jedes mal ganzen Urtext > durchsuchen, sondern h=E4tte hier eine Tabelle, die einen schnelleren Zug= riff > erlaubt. Und selbst wenn man nach Morph ohne Grundform sucht ginge das, da > man einfach in jedem Strong's nach entsprechendem Morph-Tag sucht. > Gute Idee. Ich habe schon die XML-Datenbank eXist am Laufen und den=20 Rehkopf-Inhalt (1100 W=F6rter) drin, die m=FCsste man "nur" um die Strongs= =20 erweitern. Verseingaben kriegt man durch Preprocessing auf dem Grundtext.=20 Vielleicht gibt es ein maschinelles Strong-W=F6rterbuch schon lizenzfrei. W= ER=20 MAG MAL RECHERCHIEREN?! > Und erst wenn man im Suchfeld auf entsprechenden Vers klickt kommt ja der > eigentliche Text, und der wird halt gleich in der =DCbersetzung der Wahl > angezeigt. Genau. Ach ja. Es gibt das Tool Lucene vom Apache-Projekt (Jakarta, also in Java).= =20 Das kann Texte indizieren, dann k=F6nnte man doch mit vorgeneriertem Index = im=20 Grundtext suchen. Das w=E4re evtl. schon ein Teil vom Preprocessing. Ich we= rde=20 mal damit rumspielen. Wenn ich damit was hinkriege, kann ich mir vorstellen, dass es auch f=FCr=20 anaKrino was w=E4re, auch wenn es Java ist (z.B. mit XMLRPC-Schnittstelle).= Man=20 kann dann =FCberlegen, ob man die JVM an die User mit ausliefert oder mit=20 java2c compiliert. Carsten =2D-=20 Carsten Ziegert http://www.cmziegert.org |
From: Gregor :k. K. <ke...@an...> - 2004-09-27 21:21:40
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Ich w=FCrde schon bei der Wortsuchen die gesamte Morphologie abdecken, d.= h. > wenn der User "Heilig + Geist" eingibt, dann "Heiligen Geist" genauso > finden wie "(mit) Heiligem Geist". > Das setzt voraus, dass entweder 1. im Bibeltext jede Wortform an die > Grundform gekettet ist (was eine schnellere Suche ergeben w=FCrde, aber v= iel > Arbeit im Vorfeld bedeutet) oder dass 2. bei der Suche alle m=F6glichen > Wortformen von der eingegebenen Grundform zun=E4chst abgeleitet werden (-= =2D> > "Morphologie-Generierungs-Komponente"), die dann alle im textkorpus gesuc= ht > werden. > Eine dritte Alternative: Man speichert die Grundformen im Text selbst (1.= ), > l=E4sst sie aber maschinell generieren (d.h. wie in 2.: > Morphologie-Generierungs-Komponente mit JEDER Grundform auf den Text > loslassen und an die gefundenen Wortformen die gesuchte Grundform > maschinell anketten). Hm, die Idee ist keinesfalls schlecht, nur w=E4re zu gucken, wie schwer die Implementierung w=E4re. Hm, und da kommen wir, glaub ich, wieder zu einer Frage meinerseits: Kann man f=FCr die morphologische Suche die Grundform einfach an Hand der Strong's speichern, oder muss sowohl als auch im Text gespeichert werden? Desweiteren war es halt meinerseits so gedacht, dass die morph- und Strong's-Suche auf dem Grundtext oder einem "Metatext" gesucht wird, nicht auf einer =DCbersetzung. W=FCrde halt bedeuten man k=F6nnte nie nach "Heili= g" suchen sondern m=FCsste das griechische Wort dazu kennen. Wie gesagt, bisher so gedacht, ob man das nun so beibeh=E4lt ist eine andere =46rage. Hm, moment ... angenommen der User sucht nach "Heilig", dann w=FCrde das Prog halt gucken,= was steht im Text bei Heilig f=FCr n Strong's oder f=FCr ne Grundform, und dann= wird auf eben erw=E4hntem Metatext nach allen Vorkommnissen dieser Grundform gesucht, dann w=E4re "Heiligen" und "Heiliger" doch auch gleich dabei, oder= hab ich da jetzt was falsch verstanden? Zu dem "Metatext": Die =DCberlegung war folgender Ma=DFen: Eine Art Tabelle <strong> <morph> <vers/> <vers/> <vers/> </morph> <morph> <vers/> <vers/> <vers/> </morph> <strong> Das h=E4tte den Vorteil, man m=FCsste nicht jedes mal ganzen Urtext durchsu= chen, sondern h=E4tte hier eine Tabelle, die einen schnelleren Zugriff erlaubt. Und selbst wenn man nach Morph ohne Grundform sucht ginge das, da man einfa= ch in jedem Strong's nach entsprechendem Morph-Tag sucht. Und erst wenn man im Suchfeld auf entsprechenden Vers klickt kommt ja der eigentliche Text, und der wird halt gleich in der =DCbersetzung der Wahl angezeigt. Hm, wie schaut es eigentlich aus mit Screenshots unserer bisherigen Wunsch-GUI? Dann w=FCssten die neuen auch mal, wie das bisher aussehen soll. Wobei ich hier mal wieder Strong's mit Grundform gleichsetze. Aber, wie gesagt, das m=FCsst ihr mir sagen, ob das geht, oder falls nicht, warum? kelko =2D -- anaKrino bible study Gregor :kelko: Karzelek :: ke...@an... Projektmitbegr=FCnder =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWdY2YvkFR0eSpKARAqh4AJ9JDwrNukw6J5Uf8scwqHJXgQYPAACfV511 ED5SgeOoIicgrDsACD4h9VA=3D =3DPTEY =2D----END PGP SIGNATURE----- |
From: Gregor :k. K. <ke...@an...> - 2004-09-27 21:14:50
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > mein erster Gedanke dabei: > Um die beiden Suchanfragen leichter zu trennen, sollte man evtl. "search" > und z.B: "find" benutzen [wenn jemand es =FCber den Prompt macht]. > Sonst werden die Leute vielleicht durcheinander kommen. Jo, gute Idee. =2D -- anaKrino bible study Gregor :kelko: Karzelek :: ke...@an... Projektmitbegr=FCnder =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBWdRuYvkFR0eSpKARAowdAKC1chHuxMSTzzStiPdtKbTFN90ZRwCfT4+x YtcNugI86W/ieGYp2/USkYI=3D =3DyEVm =2D----END PGP SIGNATURE----- |
From: Karl K. <ka...@an...> - 2004-09-27 20:05:48
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Das ist eine TestMail, bitte gleich löschen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFBWHPvYvkFR0eSpKARAtsNAKCempYVqWhXuwgZbkxoXGvLrfkW4QCgjWER k5f0ZeItnJL5gl9v950TGks= =CI+L -----END PGP SIGNATURE----- |
From: Carsten Z. <ca...@cm...> - 2004-09-25 09:12:18
|
Am Samstag, 25. September 2004 19:29 schrieb Gregor :kelko: Karzelek: > Nun der eigentliche Grund f=FCr diese Mail: > Wir wollen noch nach Strong's und Morphologien suchen k=F6nnen. > > Da ich mich in dem Bereich nicht auskenne muss ich halt wissen: > Wonach muss man alles suchen k=F6nnen, in welchen Variationen? > > Meine ersten =DCberlegungen gingen dazu =FCber: > Was kann neben oben genannter Form auch diese haben: > "(XYZ" Wort")" > Wobei XYZ ein Platzhalter f=FCr das eigentliche Keyword ist. Wie genau das > hei=DFen soll m=FCsste dann auch noch gekl=E4rt werden. > > Und Wort ist entweder eine Strong's Number, eine Stammform oder eine suche > nach Morphologien. > "(morph" Strong's/Stammform Morph")" > Strong's/Stammform ist dabei optional, kann also weggelassen werden, wenn > man nach allen Worten mit dieser Morphologie suchen will. > Und Morph ist die Angabe der Morphologie. Wie genau das angegeben wird, i= st > noch unklar. > > Bei der Suche, auch der einfachen, soll man zudem mit "wildcards" arbeiten > k=F6nnen. > > W=FCrde dies alle Suchm=F6glichkeiten entsprechen, wenn es um Suche nach > Strong's und Morphologien geht, oder muss noch eine weitere M=F6glichkeit= der > Suche abgedeckt werden? Ich w=FCrde schon bei der Wortsuchen die gesamte Morphologie abdecken, d.h.= wenn=20 der User "Heilig + Geist" eingibt, dann "Heiligen Geist" genauso finden wie= =20 "(mit) Heiligem Geist". Das setzt voraus, dass entweder 1. im Bibeltext jede Wortform an die Grundf= orm=20 gekettet ist (was eine schnellere Suche ergeben w=FCrde, aber viel Arbeit i= m=20 Vorfeld bedeutet) oder dass 2. bei der Suche alle m=F6glichen Wortformen vo= n=20 der eingegebenen Grundform zun=E4chst abgeleitet werden (-->=20 "Morphologie-Generierungs-Komponente"), die dann alle im textkorpus gesucht= =20 werden. Eine dritte Alternative: Man speichert die Grundformen im Text selbst (1.),= =20 l=E4sst sie aber maschinell generieren (d.h. wie in 2.:=20 Morphologie-Generierungs-Komponente mit JEDER Grundform auf den Text=20 loslassen und an die gefundenen Wortformen die gesuchte Grundform maschinel= l=20 anketten). =46YI: Ich spiele gerade etwas mit Java/Unicode herum und habe *ansatzweise= *=20 auch schon etwas griechische Nominalmorphologie. L=E4sst sich bestimmt in=20 irgendeiner Form f=FCr anaKrino weiterverwenden. Gru=DF Carsten =2D-=20 Carsten Ziegert http://www.cmziegert.org |
From: kairos <ka...@an...> - 2004-09-25 09:00:30
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am Samstag, 25. September 2004 19:29 schrieb Gregor :kelko: Karzelek: > Naja, letztlich sind deshalb zwei verschiedene Formen zum Suchen > entstanden, eine einfache und eine komplexe. > > Die einfache ist gedacht um schnell mal was zu suchen, und sollte fast > schon intuitiv sein. mein erster Gedanke dabei: Um die beiden Suchanfragen leichter zu trennen, sollte man evtl. "search" u= nd z.B: "find" benutzen [wenn jemand es =FCber den Prompt macht]. Sonst werden die Leute vielleicht durcheinander kommen. "find" k=F6nnte dann die leichte "search" die komplexe Suche sein. Bei der graphischen Suche w=E4re das ja eh egal. kairos =2D -- <>< Developing free bibel software join anaKrino :: www.anaKrino.de ><> =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBVTTpYvkFR0eSpKARAi1NAKDG1HiXY0WxtFItrn9BRJC3IRJO7ACgr04Y UuneuPstBgVU9t2yFxfWm94=3D =3DZ1YA =2D----END PGP SIGNATURE----- |
From: Gregor :k. K. <ke...@an...> - 2004-09-24 17:28:34
|
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Die Frage um die es geht ist, wonach soll man wie in anaKrino suchen k=F6nn= en. Die ersten =DCberlegungen gingen dahin, dass wir ne sehr einfache Syntax wo= llen=20 zum formulieren der Suchen, doch so, dass letztlich nach allem und jedem=20 gesucht werden kann. Naja, letztlich sind deshalb zwei verschiedene Formen zum Suchen entstanden= ,=20 eine einfache und eine komplexe. Die einfache ist gedacht um schnell mal was zu suchen, und sollte fast scho= n=20 intuitiv sein. "search" X "in" Y "of" Z [ENTER] Dabei steht X f=FCr ein einzelnes Wort, einen Begriff (in Anf=FChrungszeich= en=20 gesetzt) und einer Liste an W=F6rtern/Begriffen. M=F6glich w=E4ren: Heilig "Heiliger Geist" Heilig + Geist Heilig | Geist Dabei bedeutet "+" soviel wie "und" und "|" soviel wie "oder" Y steht f=FCr den Bereich in dem man suchen will. M=F6glich ist eine Angabe in Anf=FChrungszeichen, eine Bereichsangabe, oder eine Liste von beidem. M=F6glich w=E4ren: "1Mos1" "1Mos1" - "1Mos5" "1Mos" "1Mos" - "Jes" "1Mos" - "Jes" | "Math" "1Mos" - "5Mos" | "Math" - "Joh" Und so weiter. Dabei wird es bestimmte Begriffe wie "AT" oder so geben, die fest vordefini= ert=20 sind und einen bestimmten Bereich meinen. Dabei hat "|" wieder die Bedeutung von "oder". Und "Z" ist die Modulangabe, also die Angabe in welchen Texten gesucht werd= en=20 soll. Dabei kann man die Modulnahmen =E4hnlich wie die Suchw=F6rter verbinden. M=F6glich w=E4ren: "Elb" + "Luth" <- Es muss in Elberfelder und Luther im selben Vers das=20 gesuchte stehen "Elb" | "Luth" <- Es muss in einem der beiden das gesuchte stehen. "Elb" | Luth" + "Schl" <- Das w=FCrde folgend gelesen: (( "Elb" | "Luth" ) + "Schl" ) <- Also entweder in Elb oder Luth, und in= =20 Schl. Man kann auch selber Klammern setzen: "Elb" | ("Luth" + "Schl") Die Syntax der komplexen Suche ist st=E4rker "geklammert", wodurch sich abe= r=20 feiner suchen l=E4sst. Dabei ist die Form an "LISP" angelehnt. Die Syntax i= st=20 nicht die leichteste zum erkl=E4ren. Einfach gesagt: "(search" Wo Was ")" [ENTER] Dabei ist "Wo" entweder eine einfache Bereichsangabe Bsp: "1Mos" Oder eine Von-Bis-Angabe: "(->" Von Bis ")" Wobei Von und Bis wieder einfache Bereichsangaben sind Oder eine Oder-Angabe: "(|" Bereich1 Bereich2 ")" Wobei Bereich1 und Bereich2 entweder eine Von-Bis-Angabe sein k=F6nnen oder= eine=20 einfache Bereichsangabe. wenn man also in einem Bereich oder ein einem anderen sucht w=E4re das: (| (-> "1Mos" "Jes") (-> "Math" "Joh") ) Wenn man nur im 1. Mose sucht w=E4re es einfach: "1Mos" Was ist sowohl die Modul als auch die Wortangabe. Dabei ist Was immer geklammert: "(word" Modul Wort")" Modul wiederrum kann entweder nur eine einfache Modulangabe sein "Elb" Oder eine verkettete Modulangabe mit "und" / "oder" (+ "Elb" "Luth") (| "Elb" "Luth") Dabei k=F6nnen es unendlich viele Modulangaben geben. Dabei kann jede Modulangabe wieder eine verkettete Modulangabe sein: (+ (| "Elb" "Luth") "Schl") (| "Elb" (+ "Luth" "Schl")) Um die oberen Beispiele erneut aufzugreifen. Das Wort ist dann das gesuchte Wort, oder der gesuchte Begriff, oder eine=20 Liste von Worten/Begriffen: Heilig "Heiliger Geist" (+ Heilig Geist) (| Heilig Geist) Dabei kann jede Angabe in einer Liste wieder eine Liste sein. (| (+ Heilig Geist) Unwissenheit (+ Glaube Hoffnung Liebe)) Das ist, was wir uns bisher =FCberlegt hatten, so als Info f=FCr alle. Nun der eigentliche Grund f=FCr diese Mail: Wir wollen noch nach Strong's und Morphologien suchen k=F6nnen. Da ich mich in dem Bereich nicht auskenne muss ich halt wissen: Wonach muss man alles suchen k=F6nnen, in welchen Variationen? Meine ersten =DCberlegungen gingen dazu =FCber: Was kann neben oben genannter Form auch diese haben: "(XYZ" Wort")" Wobei XYZ ein Platzhalter f=FCr das eigentliche Keyword ist. Wie genau das= =20 hei=DFen soll m=FCsste dann auch noch gekl=E4rt werden. Und Wort ist entweder eine Strong's Number, eine Stammform oder eine suche= =20 nach Morphologien. "(morph" Strong's/Stammform Morph")" Strong's/Stammform ist dabei optional, kann also weggelassen werden, wenn m= an=20 nach allen Worten mit dieser Morphologie suchen will. Und Morph ist die Angabe der Morphologie. Wie genau das angegeben wird, ist= =20 noch unklar. Bei der Suche, auch der einfachen, soll man zudem mit "wildcards" arbeiten= =20 k=F6nnen. W=FCrde dies alle Suchm=F6glichkeiten entsprechen, wenn es um Suche nach St= rong's=20 und Morphologien geht, oder muss noch eine weitere M=F6glichkeit der Suche= =20 abgedeckt werden? Achso, keine Angst: Man muss sich die komplexe Suchsyntax nicht unbedingt auswendig lernen, es= =20 soll daf=FCr eine grafische "Suchmodelierung" geben, die dann die eigentlic= he=20 Suchanfrage erstellt. Aber trotzdem muss jetzt gekl=E4rt werden, wonach man= =20 alles in welchen Variationen suchen k=F6nnen muss. kelko =2D --=20 anaKrino bible study Gregor "kelko" Karzelek :: ke...@an... Projektmitbegr=FCnder=20 =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFBVaryYvkFR0eSpKARAj2eAKC1ZXwRKyH+M8E4mVKaa3SaJWyevgCfftkG O5os1wQpTnD7F5Fvw5tOp0Y=3D =3DCIxC =2D----END PGP SIGNATURE----- |