CrossWire Bible Society - User contributions [en]

TEI Dictionaries

2016-02-10T04:08:40Z

Dowens: /* Troubleshooting */

==Introduction==
In SWORD, the "LD" module type is used to contain modules keyed to non-hierarchical keys. Such modules include: dictionaries (indexed by words or numbers), glossaries (simple one-word translation dictionaries), and daily devotionals (indexed by dates).

For lexicons and dictionaries, the use of [http://www.tei-c.org/Guidelines/P5/ Text Encoding Initiative P5] markup is encouraged. TEI P5 is an XML standard, quite similar to OSIS and ThML, intended for encoding all types of electronic documents. Since TEI is modular, it is possible to ignore the majority of its modules and use only a smaller set of tags necessary to our needs.

For the purpose using TEI P5 in SWORD, we have developed a special XML Schema that includes the basic set of P5 modules necessary for dictionaries and adds osisID and osisRef attributes (with their normal OSIS syntax) to many elements. This will permit cross-referencing with OSIS modules and the use of standard Bible references in TEI documents. Our customized TEI schema is available at http://www.crosswire.org/OSIS/teiP5osis.2.5.0.xsd.

==Order==
SWORD uses a strict binary search to find entries and nearest entries in a "LD" module. There are two restrictions that this places upon a TEI dictionary:

1) Keys are unique and cannot be repeated. This poses problems with some dictionaries that have more than 1 entry for a key. These will need to be merged.

2) Entries will be re-ordered (by the importer utility) based upon their UTF-8 code points. Fortunately this turns out to be identical to a simple 8-bit ASCII collation.

Note: Some characters can be composed or decomposed. The tei2mod importer will normalize to NFC using ICU. Any program that does not normalize its search request in exactly the same way cannot be expected to find entries.

==General Structure==

To produce a Lexicon/Dictionary with our customized TEI Schema, you can use this template:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<TEI xmlns="http://www.crosswire.org/2013/TEIOSIS/namespace"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.crosswire.org/2013/TEIOSIS/namespace
http://www.crosswire.org/OSIS/teiP5osis.2.5.0.xsd">
</pre>

===Header===

A header minimally contains information about the title of the electronic text in <titleStmt>, about its publication in <publicationStmt>, and bibliographic information about the source document from which it is derived <sourceDesc>. A minimal TEI header would look as follows:
<pre>
<teiHeader>
<fileDesc>
<titleStmt>
<title>A title statement about the electronic text</title>
</titleStmt>
<publicationStmt>
<p>Information on the publication of the electronic text.</p>
</publicationStmt>
<sourceDesc>
<p>A bibliographic description of the source for the electronic text.</p>
</sourceDesc>
</fileDesc>
</teiHeader>
</pre>

=== Body ===

Here is the general structure of the body content:

<pre>
<text>
<body>
<entryFree sortKey="AARON">
<def>The son of Amram and Jochebed, and the older brother of Moses and Miriam.</def>
</entryFree>
<entryFree sortKey="ABADDON">
<def>Destroyer, the name given to the king of the hosts represented by the locusts.</def>
</entryFree>
....
</body>
</text>
</pre>

1. '''sortKeys are unique and cannot be repeated.'''

2. The container for a dictionary element in TEI is <entry> for structured entries, <entryFree> for any child elements allowed, and <superEntry> to collect entries into a larger one.

* <entry> is strongly structured. It is more like a database row definition. Elements have particular parenting. And whitespace is insignificant. <entry> requires elements to be in a particular order and nested in a particular fashion and may not allow text in places one would want. <entry> seems more appropriate for original works.

* <entryFree> is weakly structured. It is more like a document. The elements can come in any order, nested in any fashion and text can be interspersed as desired. Thus, whitespace is significant. '''For transforming e-texts into TEI, <entryFree> is then highly recommended'''.

* <superEntry> can be used as a collector for several <entry> or <entryFree>. The tei2mod module creator will create an entry for the <superEntry> and one for each <entry> and <entryFree> in it.

3. The engine is designed to support multiple keys in a single dictionary module so something like <entryFree n="ἀγαπάω|agapaō|G25"> would be a feasible entry. A user could look up the same word in different languages modules without having to switch dictionaries.

An example:
<pre>
<entryFree n="H0002|אב">
<title>H2</title>
<orth>אב</orth>
<orth type="trans" rend="bold">'ab</orth>
<pron rend="italic">ab</pron><lb/>
<def>(Chaldee); corresponding to <ref target="Strong:H0001">H1</ref>: - father.</def>
</entryFree>
</pre>

==Markup==

===Linking Entries===
There are three kinds of references in a dictionary:

'''Internal references''' to entries in the same dictionary.
<pre><xr type="see">See: <ref target="self:key">key text</ref></xr></pre>
Note: the key text may be any representation of the key. For example, the key may be G0019a and the key text may be 19a.

'''External references''' to entries in another work.
<pre><xr type="xref"><ref target="work:key">key text</ref></xr></pre>
Note: work is the short module name as found ''between'' square brackets as in [Strong]

'''Biblical references''' to scripture passages. These use osisRef and are discussed below.

====OSIS References====

For the purpose of facilitating the marking of Bible references and linking with OSIS documents, two attributes have been borrowed from OSIS:

osisID exists on virtually all elements and contains osisID(s) (optionally with work IDs). An osisID might be used to link from an OSIS document to your TEI dictionary entry.

osisRef exists on the <tt><ref></tt> element. A biblical reference occurring in an entry might be marked as:
<pre><xr type="Bible"><ref osisRef="KJV:Gen.1.5-Gen.1.8">Genesis 1:5-8</ref></xr></pre>

===Rendering Instructions===

TEI is focused on semantic markup, but supports rendering instructions on most elements via the <tt>rend</tt> attribute. This attribute contains a description (or recommendation) of how the enclosed text should be rendered. In addition, if a segment of text should be marked as primarily significant because of its differentiated rendering, it may be marked by either the <emph> or <hi> elements. <emph> indicates that the text is emphasized, whereas the more general and semantically neutral <hi> element simply acts as a place to hang the rend attribute:
<code>I was <emph rend="italic">extremely</emph> excited by the new TEI filters. Yay.
This text is <hi rend="bold">bold</hi></code>
The <tt>rend</tt> attribute may contain a list of values, but these values are not specified by the TEI P5 specification itself. As such, for the purpose of interoperability and consistency, it is important that values for use in Sword be enumerated. Some of these values come from the set of allowed values on the type attribute of OSIS <hi> elements, which in turn borrows from CSS. Other values will generally borrow from CSS conventions.

CrossWire values for the TEI P5 <tt>rend</tt> attribute:
bold 'from OSIS'
illuminated 'from OSIS; an illuminated letter or drop-cap, rendered very large, preferably across multiple subsequent lines of text'
italic 'from OSIS'
line-through 'from OSIS; used for strike-through text'
normal 'from OSIS; used to switch off special rendering while in the midst of a string of special rendering'
small-caps 'from OSIS'
sub 'from OSIS; subscript text'
super 'from OSIS; superscript text'
underline 'from OSIS'

===Images===

You can easily place images in your TEI file using the <graphic /> element. This element is "milestoned," meaning it isn't a container. The forward slash near the end signals that fact. Use the "url" attribute to define the location of the image relative to the compiled module. In the example below, the image "crosswire.jpg" resides in a folder "images" in the same folder as the compiled module. (SVN version)
<pre>
<graphic url="images/crosswire.jpg" />
</pre>

===Tables===

Tables require a bit of work to get set up but can be useful for some purposes. The entire table is contained in a element, and each row is then contained in a <row> element. For each column in each row a <cell> element contains the text of that cell. The following table creates column labels in bold type and includes two columns and two rows below the label row. (SVN version)
<pre>
<table>
<row>
<cell><hi type="bold">Column 1 Label</hi></cell>
<cell><hi type="bold">Column 2 Label</hi></cell>
</row>
<row>
<cell>Column 1, Row 1</cell>
<cell>Column 2, Row 1</cell>
</row>
<row>
<cell>Column 1, Row 2</cell>
<cell>Column 2, Row 2</cell>
</row>
</table>
</pre>

==Validation==

Use of the above XML header will assist in automated validation with most XML Schema Validators.

See also the TEI Validator online: http://teibyexample.org/xquery/TBEvalidator.xq

==Importing==
The program tei2mod is used to create a SWORD Lexicon/Dictionary/Daily Devotional/Glossary module from valid TEI.

This is a work in progress, so please report any problems found.

The current usage is:
<pre>
You are running tei2mod:
TEI Lexicon/Dictionary/Daily Devotional/Glossary module creation tool for
The SWORD Project

usage: tei2mod <output/path> <teiDoc> [OPTIONS]
-z use ZIP compression (default no compression)
-Z use LZSS compression (default no compression)
-s <2|4> max text size per entry(default 4):
-c <cipher_key> encipher module using supplied key
(default no enciphering)
-N Do not convert UTF-8 or normalize UTF-8 to NFC
(default is to convert to UTF-8, if needed,
and then normalize to NFC. Note: all UTF-8
texts should be normalized to NFC.)

The options -z, -Z, and -s are mutually exclusive.
</pre>

'''Notes:'''
# At this time, enciphering does not work for tei2mod.
# Currently, all compressed SWORD modules use ZIP compression.
# Having keys in the proper order may noticeably improve import time and may affect the module's lookup performance of "adjacent" entries.

==Troubleshooting==
If a module compiles but causes a front-end to crash:
* Double-check the entry id (@n) to make sure there is a unique id for each entry.
* For modules keyed to Strong's numbers, ensure there is "zero-padding," meaning all Strong's numbers should include four digits plus a zero at the beginning. So "G1" should be "00001". If any numbered id is not five digits, it make cause frontends to crash.
* Remove all <tt><div></tt> elements.

==Other helpful sites==

[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index.html The TEI Guidelines] and in particular, the documentation for [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-entryFree.html <entryFree>], on which most dictionaries should be based.

Tutorial modules accompanied with a dedicated examples section: http://teibyexample.org/TBE.htm

==Sample TEI P5 documents==
* [http://www.crosswire.org/~chrislit/osis/texts/webster1913.tei.zip Webster's Dictionary (1913)]
* [http://www.crosswire.org/~chrislit/osis/texts/strongs.tei.zip Strong's Dictionary]

[[Category:Guides|TEI Dictionaries]]

TEI Dictionaries

2016-02-10T04:07:05Z

Dowens: /* Troubleshooting */

==Introduction==
In SWORD, the "LD" module type is used to contain modules keyed to non-hierarchical keys. Such modules include: dictionaries (indexed by words or numbers), glossaries (simple one-word translation dictionaries), and daily devotionals (indexed by dates).

For lexicons and dictionaries, the use of [http://www.tei-c.org/Guidelines/P5/ Text Encoding Initiative P5] markup is encouraged. TEI P5 is an XML standard, quite similar to OSIS and ThML, intended for encoding all types of electronic documents. Since TEI is modular, it is possible to ignore the majority of its modules and use only a smaller set of tags necessary to our needs.

For the purpose using TEI P5 in SWORD, we have developed a special XML Schema that includes the basic set of P5 modules necessary for dictionaries and adds osisID and osisRef attributes (with their normal OSIS syntax) to many elements. This will permit cross-referencing with OSIS modules and the use of standard Bible references in TEI documents. Our customized TEI schema is available at http://www.crosswire.org/OSIS/teiP5osis.2.5.0.xsd.

==Order==
SWORD uses a strict binary search to find entries and nearest entries in a "LD" module. There are two restrictions that this places upon a TEI dictionary:

1) Keys are unique and cannot be repeated. This poses problems with some dictionaries that have more than 1 entry for a key. These will need to be merged.

2) Entries will be re-ordered (by the importer utility) based upon their UTF-8 code points. Fortunately this turns out to be identical to a simple 8-bit ASCII collation.

Note: Some characters can be composed or decomposed. The tei2mod importer will normalize to NFC using ICU. Any program that does not normalize its search request in exactly the same way cannot be expected to find entries.

==General Structure==

To produce a Lexicon/Dictionary with our customized TEI Schema, you can use this template:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<TEI xmlns="http://www.crosswire.org/2013/TEIOSIS/namespace"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.crosswire.org/2013/TEIOSIS/namespace
http://www.crosswire.org/OSIS/teiP5osis.2.5.0.xsd">
</pre>

===Header===

A header minimally contains information about the title of the electronic text in <titleStmt>, about its publication in <publicationStmt>, and bibliographic information about the source document from which it is derived <sourceDesc>. A minimal TEI header would look as follows:
<pre>
<teiHeader>
<fileDesc>
<titleStmt>
<title>A title statement about the electronic text</title>
</titleStmt>
<publicationStmt>
<p>Information on the publication of the electronic text.</p>
</publicationStmt>
<sourceDesc>
<p>A bibliographic description of the source for the electronic text.</p>
</sourceDesc>
</fileDesc>
</teiHeader>
</pre>

=== Body ===

Here is the general structure of the body content:

<pre>
<text>
<body>
<entryFree sortKey="AARON">
<def>The son of Amram and Jochebed, and the older brother of Moses and Miriam.</def>
</entryFree>
<entryFree sortKey="ABADDON">
<def>Destroyer, the name given to the king of the hosts represented by the locusts.</def>
</entryFree>
....
</body>
</text>
</pre>

1. '''sortKeys are unique and cannot be repeated.'''

2. The container for a dictionary element in TEI is <entry> for structured entries, <entryFree> for any child elements allowed, and <superEntry> to collect entries into a larger one.

* <entry> is strongly structured. It is more like a database row definition. Elements have particular parenting. And whitespace is insignificant. <entry> requires elements to be in a particular order and nested in a particular fashion and may not allow text in places one would want. <entry> seems more appropriate for original works.

* <entryFree> is weakly structured. It is more like a document. The elements can come in any order, nested in any fashion and text can be interspersed as desired. Thus, whitespace is significant. '''For transforming e-texts into TEI, <entryFree> is then highly recommended'''.

* <superEntry> can be used as a collector for several <entry> or <entryFree>. The tei2mod module creator will create an entry for the <superEntry> and one for each <entry> and <entryFree> in it.

3. The engine is designed to support multiple keys in a single dictionary module so something like <entryFree n="ἀγαπάω|agapaō|G25"> would be a feasible entry. A user could look up the same word in different languages modules without having to switch dictionaries.

An example:
<pre>
<entryFree n="H0002|אב">
<title>H2</title>
<orth>אב</orth>
<orth type="trans" rend="bold">'ab</orth>
<pron rend="italic">ab</pron><lb/>
<def>(Chaldee); corresponding to <ref target="Strong:H0001">H1</ref>: - father.</def>
</entryFree>
</pre>

==Markup==

===Linking Entries===
There are three kinds of references in a dictionary:

'''Internal references''' to entries in the same dictionary.
<pre><xr type="see">See: <ref target="self:key">key text</ref></xr></pre>
Note: the key text may be any representation of the key. For example, the key may be G0019a and the key text may be 19a.

'''External references''' to entries in another work.
<pre><xr type="xref"><ref target="work:key">key text</ref></xr></pre>
Note: work is the short module name as found ''between'' square brackets as in [Strong]

'''Biblical references''' to scripture passages. These use osisRef and are discussed below.

====OSIS References====

For the purpose of facilitating the marking of Bible references and linking with OSIS documents, two attributes have been borrowed from OSIS:

osisID exists on virtually all elements and contains osisID(s) (optionally with work IDs). An osisID might be used to link from an OSIS document to your TEI dictionary entry.

osisRef exists on the <tt><ref></tt> element. A biblical reference occurring in an entry might be marked as:
<pre><xr type="Bible"><ref osisRef="KJV:Gen.1.5-Gen.1.8">Genesis 1:5-8</ref></xr></pre>

===Rendering Instructions===

TEI is focused on semantic markup, but supports rendering instructions on most elements via the <tt>rend</tt> attribute. This attribute contains a description (or recommendation) of how the enclosed text should be rendered. In addition, if a segment of text should be marked as primarily significant because of its differentiated rendering, it may be marked by either the <emph> or <hi> elements. <emph> indicates that the text is emphasized, whereas the more general and semantically neutral <hi> element simply acts as a place to hang the rend attribute:
<code>I was <emph rend="italic">extremely</emph> excited by the new TEI filters. Yay.
This text is <hi rend="bold">bold</hi></code>
The <tt>rend</tt> attribute may contain a list of values, but these values are not specified by the TEI P5 specification itself. As such, for the purpose of interoperability and consistency, it is important that values for use in Sword be enumerated. Some of these values come from the set of allowed values on the type attribute of OSIS <hi> elements, which in turn borrows from CSS. Other values will generally borrow from CSS conventions.

CrossWire values for the TEI P5 <tt>rend</tt> attribute:
bold 'from OSIS'
illuminated 'from OSIS; an illuminated letter or drop-cap, rendered very large, preferably across multiple subsequent lines of text'
italic 'from OSIS'
line-through 'from OSIS; used for strike-through text'
normal 'from OSIS; used to switch off special rendering while in the midst of a string of special rendering'
small-caps 'from OSIS'
sub 'from OSIS; subscript text'
super 'from OSIS; superscript text'
underline 'from OSIS'

===Images===

You can easily place images in your TEI file using the <graphic /> element. This element is "milestoned," meaning it isn't a container. The forward slash near the end signals that fact. Use the "url" attribute to define the location of the image relative to the compiled module. In the example below, the image "crosswire.jpg" resides in a folder "images" in the same folder as the compiled module. (SVN version)
<pre>
<graphic url="images/crosswire.jpg" />
</pre>

===Tables===

Tables require a bit of work to get set up but can be useful for some purposes. The entire table is contained in a element, and each row is then contained in a <row> element. For each column in each row a <cell> element contains the text of that cell. The following table creates column labels in bold type and includes two columns and two rows below the label row. (SVN version)
<pre>
<table>
<row>
<cell><hi type="bold">Column 1 Label</hi></cell>
<cell><hi type="bold">Column 2 Label</hi></cell>
</row>
<row>
<cell>Column 1, Row 1</cell>
<cell>Column 2, Row 1</cell>
</row>
<row>
<cell>Column 1, Row 2</cell>
<cell>Column 2, Row 2</cell>
</row>
</table>
</pre>

==Validation==

Use of the above XML header will assist in automated validation with most XML Schema Validators.

See also the TEI Validator online: http://teibyexample.org/xquery/TBEvalidator.xq

==Importing==
The program tei2mod is used to create a SWORD Lexicon/Dictionary/Daily Devotional/Glossary module from valid TEI.

This is a work in progress, so please report any problems found.

The current usage is:
<pre>
You are running tei2mod:
TEI Lexicon/Dictionary/Daily Devotional/Glossary module creation tool for
The SWORD Project

usage: tei2mod <output/path> <teiDoc> [OPTIONS]
-z use ZIP compression (default no compression)
-Z use LZSS compression (default no compression)
-s <2|4> max text size per entry(default 4):
-c <cipher_key> encipher module using supplied key
(default no enciphering)
-N Do not convert UTF-8 or normalize UTF-8 to NFC
(default is to convert to UTF-8, if needed,
and then normalize to NFC. Note: all UTF-8
texts should be normalized to NFC.)

The options -z, -Z, and -s are mutually exclusive.
</pre>

'''Notes:'''
# At this time, enciphering does not work for tei2mod.
# Currently, all compressed SWORD modules use ZIP compression.
# Having keys in the proper order may noticeably improve import time and may affect the module's lookup performance of "adjacent" entries.

==Troubleshooting==
* If a module compiles but causes a front-end to crash, double-check the entry id (@n) to make sure there is a unique id for each entry.
* For modules keyed to Strong's numbers, ensure there is "zero-padding," meaning all Strong's numbers should include four digits plus a zero at the beginning. So "G1" should be "00001".
* Remove all <tt><div></tt> elements.

==Other helpful sites==

[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index.html The TEI Guidelines] and in particular, the documentation for [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-entryFree.html <entryFree>], on which most dictionaries should be based.

Tutorial modules accompanied with a dedicated examples section: http://teibyexample.org/TBE.htm

==Sample TEI P5 documents==
* [http://www.crosswire.org/~chrislit/osis/texts/webster1913.tei.zip Webster's Dictionary (1913)]
* [http://www.crosswire.org/~chrislit/osis/texts/strongs.tei.zip Strong's Dictionary]

[[Category:Guides|TEI Dictionaries]]

TEI Dictionaries

2016-02-10T02:51:19Z

Dowens: Added a troubleshooting section for module creation based on current experience.

==Introduction==
In SWORD, the "LD" module type is used to contain modules keyed to non-hierarchical keys. Such modules include: dictionaries (indexed by words or numbers), glossaries (simple one-word translation dictionaries), and daily devotionals (indexed by dates).

For lexicons and dictionaries, the use of [http://www.tei-c.org/Guidelines/P5/ Text Encoding Initiative P5] markup is encouraged. TEI P5 is an XML standard, quite similar to OSIS and ThML, intended for encoding all types of electronic documents. Since TEI is modular, it is possible to ignore the majority of its modules and use only a smaller set of tags necessary to our needs.

For the purpose using TEI P5 in SWORD, we have developed a special XML Schema that includes the basic set of P5 modules necessary for dictionaries and adds osisID and osisRef attributes (with their normal OSIS syntax) to many elements. This will permit cross-referencing with OSIS modules and the use of standard Bible references in TEI documents. Our customized TEI schema is available at http://www.crosswire.org/OSIS/teiP5osis.2.5.0.xsd.

==Order==
SWORD uses a strict binary search to find entries and nearest entries in a "LD" module. There are two restrictions that this places upon a TEI dictionary:

1) Keys are unique and cannot be repeated. This poses problems with some dictionaries that have more than 1 entry for a key. These will need to be merged.

2) Entries will be re-ordered (by the importer utility) based upon their UTF-8 code points. Fortunately this turns out to be identical to a simple 8-bit ASCII collation.

Note: Some characters can be composed or decomposed. The tei2mod importer will normalize to NFC using ICU. Any program that does not normalize its search request in exactly the same way cannot be expected to find entries.

==General Structure==

To produce a Lexicon/Dictionary with our customized TEI Schema, you can use this template:
<pre>
<?xml version="1.0" encoding="utf-8"?>
<TEI xmlns="http://www.crosswire.org/2013/TEIOSIS/namespace"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.crosswire.org/2013/TEIOSIS/namespace
http://www.crosswire.org/OSIS/teiP5osis.2.5.0.xsd">
</pre>

===Header===

A header minimally contains information about the title of the electronic text in <titleStmt>, about its publication in <publicationStmt>, and bibliographic information about the source document from which it is derived <sourceDesc>. A minimal TEI header would look as follows:
<pre>
<teiHeader>
<fileDesc>
<titleStmt>
<title>A title statement about the electronic text</title>
</titleStmt>
<publicationStmt>
<p>Information on the publication of the electronic text.</p>
</publicationStmt>
<sourceDesc>
<p>A bibliographic description of the source for the electronic text.</p>
</sourceDesc>
</fileDesc>
</teiHeader>
</pre>

=== Body ===

Here is the general structure of the body content:

<pre>
<text>
<body>
<entryFree sortKey="AARON">
<def>The son of Amram and Jochebed, and the older brother of Moses and Miriam.</def>
</entryFree>
<entryFree sortKey="ABADDON">
<def>Destroyer, the name given to the king of the hosts represented by the locusts.</def>
</entryFree>
....
</body>
</text>
</pre>

1. '''sortKeys are unique and cannot be repeated.'''

2. The container for a dictionary element in TEI is <entry> for structured entries, <entryFree> for any child elements allowed, and <superEntry> to collect entries into a larger one.

* <entry> is strongly structured. It is more like a database row definition. Elements have particular parenting. And whitespace is insignificant. <entry> requires elements to be in a particular order and nested in a particular fashion and may not allow text in places one would want. <entry> seems more appropriate for original works.

* <entryFree> is weakly structured. It is more like a document. The elements can come in any order, nested in any fashion and text can be interspersed as desired. Thus, whitespace is significant. '''For transforming e-texts into TEI, <entryFree> is then highly recommended'''.

* <superEntry> can be used as a collector for several <entry> or <entryFree>. The tei2mod module creator will create an entry for the <superEntry> and one for each <entry> and <entryFree> in it.

3. The engine is designed to support multiple keys in a single dictionary module so something like <entryFree n="ἀγαπάω|agapaō|G25"> would be a feasible entry. A user could look up the same word in different languages modules without having to switch dictionaries.

An example:
<pre>
<entryFree n="H0002|אב">
<title>H2</title>
<orth>אב</orth>
<orth type="trans" rend="bold">'ab</orth>
<pron rend="italic">ab</pron><lb/>
<def>(Chaldee); corresponding to <ref target="Strong:H0001">H1</ref>: - father.</def>
</entryFree>
</pre>

==Markup==

===Linking Entries===
There are three kinds of references in a dictionary:

'''Internal references''' to entries in the same dictionary.
<pre><xr type="see">See: <ref target="self:key">key text</ref></xr></pre>
Note: the key text may be any representation of the key. For example, the key may be G0019a and the key text may be 19a.

'''External references''' to entries in another work.
<pre><xr type="xref"><ref target="work:key">key text</ref></xr></pre>
Note: work is the short module name as found ''between'' square brackets as in [Strong]

'''Biblical references''' to scripture passages. These use osisRef and are discussed below.

====OSIS References====

For the purpose of facilitating the marking of Bible references and linking with OSIS documents, two attributes have been borrowed from OSIS:

osisID exists on virtually all elements and contains osisID(s) (optionally with work IDs). An osisID might be used to link from an OSIS document to your TEI dictionary entry.

osisRef exists on the <tt><ref></tt> element. A biblical reference occurring in an entry might be marked as:
<pre><xr type="Bible"><ref osisRef="KJV:Gen.1.5-Gen.1.8">Genesis 1:5-8</ref></xr></pre>

===Rendering Instructions===

TEI is focused on semantic markup, but supports rendering instructions on most elements via the <tt>rend</tt> attribute. This attribute contains a description (or recommendation) of how the enclosed text should be rendered. In addition, if a segment of text should be marked as primarily significant because of its differentiated rendering, it may be marked by either the <emph> or <hi> elements. <emph> indicates that the text is emphasized, whereas the more general and semantically neutral <hi> element simply acts as a place to hang the rend attribute:
<code>I was <emph rend="italic">extremely</emph> excited by the new TEI filters. Yay.
This text is <hi rend="bold">bold</hi></code>
The <tt>rend</tt> attribute may contain a list of values, but these values are not specified by the TEI P5 specification itself. As such, for the purpose of interoperability and consistency, it is important that values for use in Sword be enumerated. Some of these values come from the set of allowed values on the type attribute of OSIS <hi> elements, which in turn borrows from CSS. Other values will generally borrow from CSS conventions.

CrossWire values for the TEI P5 <tt>rend</tt> attribute:
bold 'from OSIS'
illuminated 'from OSIS; an illuminated letter or drop-cap, rendered very large, preferably across multiple subsequent lines of text'
italic 'from OSIS'
line-through 'from OSIS; used for strike-through text'
normal 'from OSIS; used to switch off special rendering while in the midst of a string of special rendering'
small-caps 'from OSIS'
sub 'from OSIS; subscript text'
super 'from OSIS; superscript text'
underline 'from OSIS'

===Images===

You can easily place images in your TEI file using the <graphic /> element. This element is "milestoned," meaning it isn't a container. The forward slash near the end signals that fact. Use the "url" attribute to define the location of the image relative to the compiled module. In the example below, the image "crosswire.jpg" resides in a folder "images" in the same folder as the compiled module. (SVN version)
<pre>
<graphic url="images/crosswire.jpg" />
</pre>

===Tables===

Tables require a bit of work to get set up but can be useful for some purposes. The entire table is contained in a element, and each row is then contained in a <row> element. For each column in each row a <cell> element contains the text of that cell. The following table creates column labels in bold type and includes two columns and two rows below the label row. (SVN version)
<pre>
<table>
<row>
<cell><hi type="bold">Column 1 Label</hi></cell>
<cell><hi type="bold">Column 2 Label</hi></cell>
</row>
<row>
<cell>Column 1, Row 1</cell>
<cell>Column 2, Row 1</cell>
</row>
<row>
<cell>Column 1, Row 2</cell>
<cell>Column 2, Row 2</cell>
</row>
</table>
</pre>

==Validation==

Use of the above XML header will assist in automated validation with most XML Schema Validators.

See also the TEI Validator online: http://teibyexample.org/xquery/TBEvalidator.xq

==Importing==
The program tei2mod is used to create a SWORD Lexicon/Dictionary/Daily Devotional/Glossary module from valid TEI.

This is a work in progress, so please report any problems found.

The current usage is:
<pre>
You are running tei2mod:
TEI Lexicon/Dictionary/Daily Devotional/Glossary module creation tool for
The SWORD Project

usage: tei2mod <output/path> <teiDoc> [OPTIONS]
-z use ZIP compression (default no compression)
-Z use LZSS compression (default no compression)
-s <2|4> max text size per entry(default 4):
-c <cipher_key> encipher module using supplied key
(default no enciphering)
-N Do not convert UTF-8 or normalize UTF-8 to NFC
(default is to convert to UTF-8, if needed,
and then normalize to NFC. Note: all UTF-8
texts should be normalized to NFC.)

The options -z, -Z, and -s are mutually exclusive.
</pre>

'''Notes:'''
# At this time, enciphering does not work for tei2mod.
# Currently, all compressed SWORD modules use ZIP compression.
# Having keys in the proper order may noticeably improve import time and may affect the module's lookup performance of "adjacent" entries.

==Troubleshooting==
* If a module compiles but causes a front-end to crash, double-check the entry id (@n) to make sure there is a unique id for each entry.
* For modules keyed to Strong's numbers, ensure there is "zero-padding," meaning all Strong's numbers should include four digits plus a zero at the beginning. So "G1" should be "00001".
* Remove all <div> elements.

==Other helpful sites==

[http://www.tei-c.org/release/doc/tei-p5-doc/en/html/index.html The TEI Guidelines] and in particular, the documentation for [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-entryFree.html <entryFree>], on which most dictionaries should be based.

Tutorial modules accompanied with a dedicated examples section: http://teibyexample.org/TBE.htm

==Sample TEI P5 documents==
* [http://www.crosswire.org/~chrislit/osis/texts/webster1913.tei.zip Webster's Dictionary (1913)]
* [http://www.crosswire.org/~chrislit/osis/texts/strongs.tei.zip Strong's Dictionary]

[[Category:Guides|TEI Dictionaries]]

Whiteboard/TEI Dictionary Proposal

2012-04-23T12:41:26Z

Dowens: /* Proposed Features of a New Model */

=Summary=

The current SWORD lexicon model allows for only flat dictionaries, which is ideally suited to Strongs but not to more recent lexica. A new model needs to take into account page numbers, non-alphabetic sorting, and hierarchical entries. Ideally it would also allow for browsing a dictionary more like a book.

=Problems with the Current Model=

*Dictionaries are flat. Dictionaries that are hierarchical must be flattened, but BDB (forthcoming) is hierarchical. Roots form super-entries, and the lexicon as a whole is not strictly alphabetical. See the example document below, which is abstracted from BDB.
*Entries are sorted according to unicode code points. This leads to a number of problems.
**In many languages and scripts (including some Latin scripts), sorting by unicode code points does not preserve the proper alphabetic order.
**If BDB were sorted in this way, it would nullify the information about the connections between words based on the roots.
*There is no way to identify page numbers found in print editions of a given module. This information is particularly important for those doing academic work.
*In practice, front-ends usually display lexicon entries as isolated containers. This model works well for Strongs because Strongs-tagged texts take you directly to the correct entry. This does not work for all dictionaries, though. When looking up a word, you might want to scan up and down the "page" to find the entry you are looking for. This is especially important if natural language keys are used so that the text might get you to roughly the right place in the dictionary but not necessarily the exact entry you need. Dictionaries need to allow for fuzzy lookup.

=Proposed Features of a New Model=
*The order of the lexicon should be the same order as the XML file used to compile the module.
*Perhaps an arbitrary (numeric?) key for entries could be created that would be hidden from the user to make life easier for developers, but topic maps could connect corresponding entries in numbered dictionaries (Strongs) and dictionaries keyed to natural language (BDB, etc.). This could be extensible over the long-term.
*Continuous scrolling would facilitate displaying page numbers and browsing entries.
*Markup should look similar to a Genbook, with the option of navigating using a tree structure, as in the Hesychius module. It may be that the easiest solution is to markup hierarchical dictionaries as Genbooks and add the functionality to the engine that allows lemma lookup in genbooks as well as "proper" dictionary modules.

=Example TEI File=

Note the following features in this snippet of the first few entries in BDB (without entry text):
*Page breaks <pb>
*Alphabetical Headings <div1>
*Some entries are super-entries <superEntry> and others are not <entry>. I realize <entry> has to be structured, but for some reason the specification does not allow for using <entryFree> with <superEntry>, so I settled for markup that would illustrate the features of BDB.
*The first word in Strong's is אב, but here in BDB the entry points forward to the full אב entry under the root אבה.
*Of those entries that are here, one (אביב) is out of alphabetical sequence. The sequence of Strong's numbers is H3, H24, H6, etc.

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.crosswire.org/2008/TEIOSIS/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crosswire.org/2008/TEIOSIS/namespace http://www.crosswire.org/OSIS/teiP5osis.1.4.xsd">
<text>
<body>
<pb n="1"/>
<div1><head>א</head>
<superEntry id="א" trans="a" />
<entry id="אב" trans="ab">v. <ref target="BDB:"II_אבה">II אבה</ref></entry>
<superEntry id="אבב" trans="abb">
<entry id="אב" trans="ab" strong="H3"/>
<entry id="אביב" trans="abib" strong="H24"/>
</superEntry>
<superEntry id="אבד" trans="abd" strong="H6">
<pb n="2"/>
<entry id="אבד" trans="abd" strong="H8"/>
<entry id="אבדה" trans="abdh" strong="H9"/>
<entry id="אבדון" trans="abdwn" strong="H10"/>
</superEntry>
</div1>
</body>
</text>
</TEI>
</pre>

Whiteboard/TEI Dictionary Proposal

2012-04-23T12:38:51Z

Dowens: /* Example TEI File */

=Summary=

The current SWORD lexicon model allows for only flat dictionaries, which is ideally suited to Strongs but not to more recent lexica. A new model needs to take into account page numbers, non-alphabetic sorting, and hierarchical entries. Ideally it would also allow for browsing a dictionary more like a book.

=Problems with the Current Model=

*Dictionaries are flat. Dictionaries that are hierarchical must be flattened, but BDB (forthcoming) is hierarchical. Roots form super-entries, and the lexicon as a whole is not strictly alphabetical. See the example document below, which is abstracted from BDB.
*Entries are sorted according to unicode code points. This leads to a number of problems.
**In many languages and scripts (including some Latin scripts), sorting by unicode code points does not preserve the proper alphabetic order.
**If BDB were sorted in this way, it would nullify the information about the connections between words based on the roots.
*There is no way to identify page numbers found in print editions of a given module. This information is particularly important for those doing academic work.
*In practice, front-ends usually display lexicon entries as isolated containers. This model works well for Strongs because Strongs-tagged texts take you directly to the correct entry. This does not work for all dictionaries, though. When looking up a word, you might want to scan up and down the "page" to find the entry you are looking for. This is especially important if natural language keys are used so that the text might get you to roughly the right place in the dictionary but not necessarily the exact entry you need. Dictionaries need to allow for fuzzy lookup.

=Proposed Features of a New Model=
*The order of the lexicon should be the same order as the XML file used to compile the module.
*Perhaps an arbitrary (numeric?) key for entries could be created that would be hidden from the user to make life easier for developers, but topic maps could connect corresponding entries in numbered dictionaries (Strongs) and dictionaries keyed to natural language (BDB, etc.). This could be extensible over the long-term.
*Continuous scrolling would facilitate displaying page numbers and browsing entries.
*Markup should look similar to a Genbook, with the option of navigating using a tree structure, as in the Hesychius module.

=Example TEI File=

Note the following features in this snippet of the first few entries in BDB (without entry text):
*Page breaks <pb>
*Alphabetical Headings <div1>
*Some entries are super-entries <superEntry> and others are not <entry>. I realize <entry> has to be structured, but for some reason the specification does not allow for using <entryFree> with <superEntry>, so I settled for markup that would illustrate the features of BDB.
*The first word in Strong's is אב, but here in BDB the entry points forward to the full אב entry under the root אבה.
*Of those entries that are here, one (אביב) is out of alphabetical sequence. The sequence of Strong's numbers is H3, H24, H6, etc.

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.crosswire.org/2008/TEIOSIS/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crosswire.org/2008/TEIOSIS/namespace http://www.crosswire.org/OSIS/teiP5osis.1.4.xsd">
<text>
<body>
<pb n="1"/>
<div1><head>א</head>
<superEntry id="א" trans="a" />
<entry id="אב" trans="ab">v. <ref target="BDB:"II_אבה">II אבה</ref></entry>
<superEntry id="אבב" trans="abb">
<entry id="אב" trans="ab" strong="H3"/>
<entry id="אביב" trans="abib" strong="H24"/>
</superEntry>
<superEntry id="אבד" trans="abd" strong="H6">
<pb n="2"/>
<entry id="אבד" trans="abd" strong="H8"/>
<entry id="אבדה" trans="abdh" strong="H9"/>
<entry id="אבדון" trans="abdwn" strong="H10"/>
</superEntry>
</div1>
</body>
</text>
</TEI>
</pre>

Whiteboard/TEI Dictionary Proposal

2012-04-23T12:38:01Z

Dowens: /* Example TEI File */

=Summary=

The current SWORD lexicon model allows for only flat dictionaries, which is ideally suited to Strongs but not to more recent lexica. A new model needs to take into account page numbers, non-alphabetic sorting, and hierarchical entries. Ideally it would also allow for browsing a dictionary more like a book.

=Problems with the Current Model=

*Dictionaries are flat. Dictionaries that are hierarchical must be flattened, but BDB (forthcoming) is hierarchical. Roots form super-entries, and the lexicon as a whole is not strictly alphabetical. See the example document below, which is abstracted from BDB.
*Entries are sorted according to unicode code points. This leads to a number of problems.
**In many languages and scripts (including some Latin scripts), sorting by unicode code points does not preserve the proper alphabetic order.
**If BDB were sorted in this way, it would nullify the information about the connections between words based on the roots.
*There is no way to identify page numbers found in print editions of a given module. This information is particularly important for those doing academic work.
*In practice, front-ends usually display lexicon entries as isolated containers. This model works well for Strongs because Strongs-tagged texts take you directly to the correct entry. This does not work for all dictionaries, though. When looking up a word, you might want to scan up and down the "page" to find the entry you are looking for. This is especially important if natural language keys are used so that the text might get you to roughly the right place in the dictionary but not necessarily the exact entry you need. Dictionaries need to allow for fuzzy lookup.

=Proposed Features of a New Model=
*The order of the lexicon should be the same order as the XML file used to compile the module.
*Perhaps an arbitrary (numeric?) key for entries could be created that would be hidden from the user to make life easier for developers, but topic maps could connect corresponding entries in numbered dictionaries (Strongs) and dictionaries keyed to natural language (BDB, etc.). This could be extensible over the long-term.
*Continuous scrolling would facilitate displaying page numbers and browsing entries.
*Markup should look similar to a Genbook, with the option of navigating using a tree structure, as in the Hesychius module.

=Example TEI File=

Note the following features in this snippet of the first few entries in BDB (without entry text):
*Page breaks <pb>
*Alphabetical Headings <div1>
*Some entries are super-entries <superEntry> and others are not <entry>. I realize <entry> has to be structured, but for some reason the specification does not allow for using <entryFree> with <superEntry>, so I settled for markup that would illustrate the features of BDB.
*The first word in Strong's is אב, which in BDB is included under the root אבה. Here in BDB the entry points forward to the full אב entry later in the lexicon under the root אבה.
*Of those entries that are here, one (אביב) is out of alphabetical sequence. The sequence of Strong's numbers is H3, H24, H6, etc.

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.crosswire.org/2008/TEIOSIS/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crosswire.org/2008/TEIOSIS/namespace http://www.crosswire.org/OSIS/teiP5osis.1.4.xsd">
<text>
<body>
<pb n="1"/>
<div1><head>א</head>
<superEntry id="א" trans="a" />
<entry id="אב" trans="ab">v. <ref target="BDB:"II_אבה">II אבה</ref></entry>
<superEntry id="אבב" trans="abb">
<entry id="אב" trans="ab" strong="H3"/>
<entry id="אביב" trans="abib" strong="H24"/>
</superEntry>
<superEntry id="אבד" trans="abd" strong="H6">
<pb n="2"/>
<entry id="אבד" trans="abd" strong="H8"/>
<entry id="אבדה" trans="abdh" strong="H9"/>
<entry id="אבדון" trans="abdwn" strong="H10"/>
</superEntry>
</div1>
</body>
</text>
</TEI>
</pre>

Whiteboard/TEI Dictionary Proposal

2012-04-23T12:36:02Z

Dowens: /* Example TEI File */

=Summary=

The current SWORD lexicon model allows for only flat dictionaries, which is ideally suited to Strongs but not to more recent lexica. A new model needs to take into account page numbers, non-alphabetic sorting, and hierarchical entries. Ideally it would also allow for browsing a dictionary more like a book.

=Problems with the Current Model=

*Dictionaries are flat. Dictionaries that are hierarchical must be flattened, but BDB (forthcoming) is hierarchical. Roots form super-entries, and the lexicon as a whole is not strictly alphabetical. See the example document below, which is abstracted from BDB.
*Entries are sorted according to unicode code points. This leads to a number of problems.
**In many languages and scripts (including some Latin scripts), sorting by unicode code points does not preserve the proper alphabetic order.
**If BDB were sorted in this way, it would nullify the information about the connections between words based on the roots.
*There is no way to identify page numbers found in print editions of a given module. This information is particularly important for those doing academic work.
*In practice, front-ends usually display lexicon entries as isolated containers. This model works well for Strongs because Strongs-tagged texts take you directly to the correct entry. This does not work for all dictionaries, though. When looking up a word, you might want to scan up and down the "page" to find the entry you are looking for. This is especially important if natural language keys are used so that the text might get you to roughly the right place in the dictionary but not necessarily the exact entry you need. Dictionaries need to allow for fuzzy lookup.

=Proposed Features of a New Model=
*The order of the lexicon should be the same order as the XML file used to compile the module.
*Perhaps an arbitrary (numeric?) key for entries could be created that would be hidden from the user to make life easier for developers, but topic maps could connect corresponding entries in numbered dictionaries (Strongs) and dictionaries keyed to natural language (BDB, etc.). This could be extensible over the long-term.
*Continuous scrolling would facilitate displaying page numbers and browsing entries.
*Markup should look similar to a Genbook, with the option of navigating using a tree structure, as in the Hesychius module.

=Example TEI File=

Note the following features in this snippet of the first few entries in BDB (without entry text):
*Page breaks <pb>
*Alphabetical Headings <div1>
*Some entries are super-entries <superEntry> and others are not <entry>. This may not be the best use of <entry>, but it illustrates what needs to be done.
*The first word in Strong's is אב, which in BDB is included under the root אבה. Here in BDB the entry points forward to the full אב entry later in the lexicon under the root אבה.
*Of those entries that are here, one (אביב) is out of alphabetical sequence. The sequence of Strong's numbers is H3, H24, H6, etc.

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.crosswire.org/2008/TEIOSIS/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crosswire.org/2008/TEIOSIS/namespace http://www.crosswire.org/OSIS/teiP5osis.1.4.xsd">
<text>
<body>
<pb n="1"/>
<div1><head>א</head>
<superEntry id="א" trans="a" />
<entry id="אב" trans="ab">v. <ref target="BDB:"II_אבה">II אבה</ref></entry>
<superEntry id="אבב" trans="abb">
<entry id="אב" trans="ab" strong="H3"/>
<entry id="אביב" trans="abib" strong="H24"/>
</superEntry>
<superEntry id="אבד" trans="abd" strong="H6">
<pb n="2"/>
<entry id="אבד" trans="abd" strong="H8"/>
<entry id="אבדה" trans="abdh" strong="H9"/>
<entry id="אבדון" trans="abdwn" strong="H10"/>
</superEntry>
</div1>
</body>
</text>
</TEI>
</pre>

Whiteboard/TEI Dictionary Proposal

2012-04-23T12:19:09Z

Dowens: /* Proposed Features of a New Model */

=Summary=

The current SWORD lexicon model allows for only flat dictionaries, which is ideally suited to Strongs but not to more recent lexica. A new model needs to take into account page numbers, non-alphabetic sorting, and hierarchical entries. Ideally it would also allow for browsing a dictionary more like a book.

=Problems with the Current Model=

*Dictionaries are flat. Dictionaries that are hierarchical must be flattened, but BDB (forthcoming) is hierarchical. Roots form super-entries, and the lexicon as a whole is not strictly alphabetical. See the example document below, which is abstracted from BDB.
*Entries are sorted according to unicode code points. This leads to a number of problems.
**In many languages and scripts (including some Latin scripts), sorting by unicode code points does not preserve the proper alphabetic order.
**If BDB were sorted in this way, it would nullify the information about the connections between words based on the roots.
*There is no way to identify page numbers found in print editions of a given module. This information is particularly important for those doing academic work.
*In practice, front-ends usually display lexicon entries as isolated containers. This model works well for Strongs because Strongs-tagged texts take you directly to the correct entry. This does not work for all dictionaries, though. When looking up a word, you might want to scan up and down the "page" to find the entry you are looking for. This is especially important if natural language keys are used so that the text might get you to roughly the right place in the dictionary but not necessarily the exact entry you need. Dictionaries need to allow for fuzzy lookup.

=Proposed Features of a New Model=
*The order of the lexicon should be the same order as the XML file used to compile the module.
*Perhaps an arbitrary (numeric?) key for entries could be created that would be hidden from the user to make life easier for developers, but topic maps could connect corresponding entries in numbered dictionaries (Strongs) and dictionaries keyed to natural language (BDB, etc.). This could be extensible over the long-term.
*Continuous scrolling would facilitate displaying page numbers and browsing entries.
*Markup should look similar to a Genbook, with the option of navigating using a tree structure, as in the Hesychius module.

=Example TEI File=

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.crosswire.org/2008/TEIOSIS/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crosswire.org/2008/TEIOSIS/namespace http://www.crosswire.org/OSIS/teiP5osis.1.4.xsd">
<text>
<body>
<pb n="1"/>
<div1><head>א</head>
<superEntry id="אבב" trans="abb">Entry text
<entry id="אב" trans="ab" strong="H3">Entry text</entry>
<entry id="אביב" trans="abib" strong="H24">Entry text</entry>
</superEntry>
<superEntry id="אבד" trans="abd" strong="H6">
<pb n="2"/>
<entry id="אבד" trans="abd" strong="H8">Entry text</entry>
<entry id="אבדה" trans="abdh" strong="H9">Entry text</entry>
<entry id="אבדון" trans="abdwn" strong="H10">Entry text</entry>
</superEntry>
</div1>
</body>
</text>
</TEI>
</pre>

Whiteboard/TEI Dictionary Proposal

2012-04-23T12:08:14Z

Dowens: /* Proposed Features of a New Model */

=Summary=

The current SWORD lexicon model allows for only flat dictionaries, which is ideally suited to Strongs but not to more recent lexica. A new model needs to take into account page numbers, non-alphabetic sorting, and hierarchical entries. Ideally it would also allow for browsing a dictionary more like a book.

=Problems with the Current Model=

*Dictionaries are flat. Dictionaries that are hierarchical must be flattened, but BDB (forthcoming) is hierarchical. Roots form super-entries, and the lexicon as a whole is not strictly alphabetical. See the example document below, which is abstracted from BDB.
*Entries are sorted according to unicode code points. This leads to a number of problems.
**In many languages and scripts (including some Latin scripts), sorting by unicode code points does not preserve the proper alphabetic order.
**If BDB were sorted in this way, it would nullify the information about the connections between words based on the roots.
*There is no way to identify page numbers found in print editions of a given module. This information is particularly important for those doing academic work.
*In practice, front-ends usually display lexicon entries as isolated containers. This model works well for Strongs because Strongs-tagged texts take you directly to the correct entry. This does not work for all dictionaries, though. When looking up a word, you might want to scan up and down the "page" to find the entry you are looking for. This is especially important if natural language keys are used so that the text might get you to roughly the right place in the dictionary but not necessarily the exact entry you need. Dictionaries need to allow for fuzzy lookup.

=Proposed Features of a New Model=
*The order of the lexicon should be the same order as the XML file used to compile the module.
*Perhaps an arbitrary (numeric?) key for entries could be created that would be hidden from the user to make life easier for developers, but topic maps could connect corresponding entries in numbered dictionaries (Strongs) and dictionaries keyed to natural language (BDB, etc.). This could be extensible over the long-term.
*Continuous scrolling would facilitate displaying page numbers and browsing entries.
*Markup should look similar to a Genbook, with the option of navigating using a tree structure.

=Example TEI File=

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.crosswire.org/2008/TEIOSIS/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crosswire.org/2008/TEIOSIS/namespace http://www.crosswire.org/OSIS/teiP5osis.1.4.xsd">
<text>
<body>
<pb n="1"/>
<div1><head>א</head>
<superEntry id="אבב" trans="abb">Entry text
<entry id="אב" trans="ab" strong="H3">Entry text</entry>
<entry id="אביב" trans="abib" strong="H24">Entry text</entry>
</superEntry>
<superEntry id="אבד" trans="abd" strong="H6">
<pb n="2"/>
<entry id="אבד" trans="abd" strong="H8">Entry text</entry>
<entry id="אבדה" trans="abdh" strong="H9">Entry text</entry>
<entry id="אבדון" trans="abdwn" strong="H10">Entry text</entry>
</superEntry>
</div1>
</body>
</text>
</TEI>
</pre>

Whiteboard/TEI Dictionary Proposal

2012-04-23T02:25:47Z

Dowens: /* Proposed Features of a New Model */

=Summary=

The current SWORD lexicon model allows for only flat dictionaries, which is ideally suited to Strongs but not to more recent lexica. A new model needs to take into account page numbers, non-alphabetic sorting, and hierarchical entries. Ideally it would also allow for browsing a dictionary more like a book.

=Problems with the Current Model=

*Dictionaries are flat. Dictionaries that are hierarchical must be flattened, but BDB (forthcoming) is hierarchical. Roots form super-entries, and the lexicon as a whole is not strictly alphabetical. See the example document below, which is abstracted from BDB.
*Entries are sorted according to unicode code points. This leads to a number of problems.
**In many languages and scripts (including some Latin scripts), sorting by unicode code points does not preserve the proper alphabetic order.
**If BDB were sorted in this way, it would nullify the information about the connections between words based on the roots.
*There is no way to identify page numbers found in print editions of a given module. This information is particularly important for those doing academic work.
*In practice, front-ends usually display lexicon entries as isolated containers. This model works well for Strongs because Strongs-tagged texts take you directly to the correct entry. This does not work for all dictionaries, though. When looking up a word, you might want to scan up and down the "page" to find the entry you are looking for. This is especially important if natural language keys are used so that the text might get you to roughly the right place in the dictionary but not necessarily the exact entry you need. Dictionaries need to allow for fuzzy lookup.
*Lexicon modules in effect have a single key. That means the Bible module, for example, must be marked up in exactly the same way as the lexicon module for the two to work well. Even with Strongs this creates problems. G0001 and 00001 should lead to the same place, but they do not. Strong's texts are marked up as 00001, but the Strong's TEI file is G0001.

=Proposed Features of a New Model=
*The order of the lexicon should be the same order as the XML file used to compile the module.
*Perhaps an arbitrary (numeric?) key for entries could be created that would be hidden from the user to make life easier for developers, but topic maps could connect corresponding entries in numbered dictionaries (Strongs) and dictionaries keyed to natural language (BDB, etc.). This could be extensible over the long-term.
*Continuous scrolling would facilitate displaying page numbers and browsing entries.

=Example TEI File=

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.crosswire.org/2008/TEIOSIS/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crosswire.org/2008/TEIOSIS/namespace http://www.crosswire.org/OSIS/teiP5osis.1.4.xsd">
<text>
<body>
<pb n="1"/>
<div1><head>א</head>
<superEntry id="אבב" trans="abb">Entry text
<entry id="אב" trans="ab" strong="H3">Entry text</entry>
<entry id="אביב" trans="abib" strong="H24">Entry text</entry>
</superEntry>
<superEntry id="אבד" trans="abd" strong="H6">
<pb n="2"/>
<entry id="אבד" trans="abd" strong="H8">Entry text</entry>
<entry id="אבדה" trans="abdh" strong="H9">Entry text</entry>
<entry id="אבדון" trans="abdwn" strong="H10">Entry text</entry>
</superEntry>
</div1>
</body>
</text>
</TEI>
</pre>

Whiteboard/TEI Dictionary Proposal

2012-04-23T02:10:25Z

Dowens: /* Problems with the Current Model */

=Summary=

The current SWORD lexicon model allows for only flat dictionaries, which is ideally suited to Strongs but not to more recent lexica. A new model needs to take into account page numbers, non-alphabetic sorting, and hierarchical entries. Ideally it would also allow for browsing a dictionary more like a book.

=Problems with the Current Model=

*Dictionaries are flat. Dictionaries that are hierarchical must be flattened, but BDB (forthcoming) is hierarchical. Roots form super-entries, and the lexicon as a whole is not strictly alphabetical. See the example document below, which is abstracted from BDB.
*Entries are sorted according to unicode code points. This leads to a number of problems.
**In many languages and scripts (including some Latin scripts), sorting by unicode code points does not preserve the proper alphabetic order.
**If BDB were sorted in this way, it would nullify the information about the connections between words based on the roots.
*There is no way to identify page numbers found in print editions of a given module. This information is particularly important for those doing academic work.
*In practice, front-ends usually display lexicon entries as isolated containers. This model works well for Strongs because Strongs-tagged texts take you directly to the correct entry. This does not work for all dictionaries, though. When looking up a word, you might want to scan up and down the "page" to find the entry you are looking for. This is especially important if natural language keys are used so that the text might get you to roughly the right place in the dictionary but not necessarily the exact entry you need. Dictionaries need to allow for fuzzy lookup.
*Lexicon modules in effect have a single key. That means the Bible module, for example, must be marked up in exactly the same way as the lexicon module for the two to work well. Even with Strongs this creates problems. G0001 and 00001 should lead to the same place, but they do not. Strong's texts are marked up as 00001, but the Strong's TEI file is G0001.

=Proposed Features of a New Model=

=Example TEI File=

<pre>
<?xml version="1.0" encoding="UTF-8"?>
<TEI xmlns="http://www.crosswire.org/2008/TEIOSIS/namespace" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.crosswire.org/2008/TEIOSIS/namespace http://www.crosswire.org/OSIS/teiP5osis.1.4.xsd">
<text>
<body>
<pb n="1"/>
<div1><head>א</head>
<superEntry id="אבב" trans="abb">Entry text
<entry id="אב" trans="ab" strong="H3">Entry text</entry>
<entry id="אביב" trans="abib" strong="H24">Entry text</entry>
</superEntry>
<superEntry id="אבד" trans="abd" strong="H6">
<pb n="2"/>
<entry id="אבד" trans="abd" strong="H8">Entry text</entry>
<entry id="אבדה" trans="abdh" strong="H9">Entry text</entry>
<entry id="אבדון" trans="abdwn" strong="H10">Entry text</entry>
</superEntry>
</div1>
</body>
</text>
</TEI>
</pre>

Whiteboard/TEI Dictionary Proposal

2012-04-23T02:07:00Z

Dowens: /* Problems with the Current Model */

Whiteboard/TEI Dictionary Proposal

2012-04-23T02:06:44Z

Dowens: /* Problems with the Current Model */

Whiteboard/TEI Dictionary Proposal

2012-04-23T02:03:46Z

Dowens: /* Summary */

Whiteboard/TEI Dictionary Proposal

2012-04-22T22:47:29Z

Dowens: /* Features of the Current Model */

2012-03-01T20:49:28Z

Dowens:

This page will contain an example OSIS document that is structured by Book-Chapter-Verse.

<nowiki><?xml version="1.0" encoding="UTF-8" ?>
<osis
xmlns="http://www.bibletechnologies.net/2003/OSIS/namespace"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.bibletechnologies.net/2003/OSIS/namespace http://www.bibletechnologies.net/osisCore.2.1.1.xsd">
<osisText osisIDWork="KJV" osisRefWork="defaultReferenceScheme" xml:lang="en">
<header>
<work osisWork="KJV">
<title>King James Version (1769) with Strongs Numbers and Morphology</title>
<identifier type="OSIS">Bible.KJV</identifier>
<scope>Gen-Rev</scope>
<refSystem>Bible.KJV</refSystem>
</work>
<work osisWork="defaultReferenceScheme">
<refSystem>Bible.KJV</refSystem>
</work>
<work osisWork="strong">
<refSystem>Dict.Strongs</refSystem>
</work>
<work osisWork="robinson">
<refSystem>Dict.Robinsons</refSystem>
</work>
<work osisWork="strongMorph">
<refSystem>Dict.strongMorph</refSystem>
</work>
</header>
<div type="book" osisID="Gen" canonical="true">
<title type="main">THE FIRST BOOK OF MOSES CALLED GENESIS</title>
<chapter osisID="Gen.1" chapterTitle="CHAPTER 1.">
<title type="chapter">CHAPTER 1.</title>
<verse osisID="Gen.1.1"><w lemma="strong:H07225">In the beginning</w> <w lemma="strong:H0430">God</w> <w morph="strongMorph:TH8804" lemma="strong:H0853 strong:H01254">created</w> <w lemma="strong:H08064">the heaven</w> <w lemma="strong:H0853">and</w> <w lemma="strong:H0776">the earth</w>.</verse>
<verse osisID="Gen.1.2"><w lemma="strong:H0776">And the earth</w> <w morph="strongMorph:TH8804" lemma="strong:H01961">was</w> <w lemma="strong:H08414">without form</w>, <w lemma="strong:H0922">and void</w>; <w lemma="strong:H02822">and darkness</w> <transChange type="added">was</transChange> <w lemma="strong:H06440">upon the face</w> <w lemma="strong:H08415">of the deep</w>. <w lemma="strong:H07307">And the Spirit</w> <w lemma="strong:H0430">of God</w> <w morph="strongMorph:TH8764" lemma="strong:H07363">moved</w> <w lemma="strong:H05921">upon</w> <w lemma="strong:H06440">the face</w> <w lemma="strong:H04325">of the waters</w>.</verse>
<verse osisID="Gen.1.3"><milestone type="x-extra-p"/><w lemma="strong:H0430">And God</w> <w morph="strongMorph:TH8799" lemma="strong:H0559">said</w>, <w morph="strongMorph:TH8799" lemma="strong:H01961">Let there be</w> <w lemma="strong:H0216">light</w>: <w lemma="strong:H0216">and there was light</w>.</verse>
<verse osisID="Gen.1.4"><w lemma="strong:H0430">And God</w> <w morph="strongMorph:TH8799" lemma="strong:H0853 strong:H07200">saw</w> <w lemma="strong:H0216">the light</w>, <w lemma="strong:H03588">that</w> <transChange type="added">it was</transChange> <w lemma="strong:H02896">good</w>: <w lemma="strong:H0430">and God</w> <w morph="strongMorph:TH8686" lemma="strong:H0996 strong:H0914">divided</w> <w lemma="strong:H0216">the light</w> <w lemma="strong:H0996">from</w> <w lemma="strong:H02822">the darkness</w>.<note type="study">the light from…: Heb. between the light and between the darkness</note></verse></nowiki>

OSIS Bibles/BSPExample

2012-03-01T20:47:30Z

Dowens: Created page with "This page will contain an example OSIS document that is structured by Book-Chapter-Verse."

This page will contain an example OSIS document that is structured by Book-Chapter-Verse.