Nxaʔamxcín (Moses) Dictionary Blog

Greg pointed out that we are using Ø (Latin Capital Letter O with Stroke, U+00D8) for our zero morpheme marker, rather than ∅ (Empty Set, U+2205). The latter is noted in the Unicode character map as the one used in linguistics to indicate a null morpheme or phonological zero.

We have at least been consistent in our use of the former! We may not have known the Empty Set character existed when we chose the other one in 2010, or it may have been a font-based choice. (I'm using Aboriginal Sans in Oxygen right now, and the Empty Set character doesn't display properly.)

Martin will add this change to his list of global changes to make when improving our current encoding, if we can be assured of fonts that include Empty Set along with all the other special characters we need.

17Aug16: JT has created a new diagnostics page (http://jenkins.hcmc.uvic.ca/job/moses/lastSuccessfulBuild/artifact/trunk/utilities/diagnostics.html) which looks for the following errors in complete, edited, and light-edited files:

-entries with glosses in cits

-entries with no gloss at all (and no name, persName, placeName, orgName or label)

-entries with no def

-entries containing more than one xr (These need to be concatenated into multiple refs within one xr.)

-pron:segs with parentheses in them (These need to be analyzed by a human, and made into either two seg type=n's, or two separate form elements, as necessary.)

-use of n-CTL t-TR Ø-OBJ n-SUBJ or n-CTL t-TR Ø-OBJ s-SUBJ on a word-final -n or -s if preceded by other transitive morphology (n-CTL, t-TR, stu, xit, ɬ-DIR, ɬ-EP,min, nun, tuɬ.)

26Sep16: MDH has added the following additional diagnostics:

-entries with the same string gloss-tagged more than once

-placeName entries that "duplicate" regular entries in <form> (e.g. entry for "deadfall"), so SMK and ECH can review them and make sure they are handled consistently.

-refs in xrs containing non-phonemic characters ... that is, anything BUT these characters

ʔ a á à ạ c ʼ ə h ḥ ʷ i í ì ị k l ḷ ˀ ɬ ƛ m n p q r s ṣ t u ú ù ụ w x y ʕ combining acute accent, combining grave accent, combining dot below, whitespace.

We also need to remember to deal with glosses which end in the English inflections -ing, -ed, -en or -s, as well as ablaut forms like "blow/blew". We can check these with the Find function once all the files are edited, and as we are proofing the print dictionary.

MDH had also asked about diagnostics for what makes an entry "complete", to improve the statistics report. The answer is simply:

-no Not Yet Edited Comment, AND either
-a completed hyph with no m:UNASSIGNED, OR
-a root or stem <fs>

For the time being (26Sep16), MDH has just moved the counts of total entries and entries with no Not Yet Edited Comment into the Statistics section of the new diagnostics page.

If EJD needs to edit the diagnostics further in the future, the file is: trunk/utilities/diagnostics.xsl

Once SMK and EJD have completed a first pass of editing all the files, and resolved all the problems identified by the diagnostics, MDH can make them part of the schematron to make sure we don't introduce new mistakes subsequently.

I have been meaning to mention that we'll also need to orth the contents of <ref>s inside <xr>s.

1) Here is the rule for word-initial i-insertion in orthing:

Where "C" equals any of the following consonants: ʔ c c̣ cʼ h ḥ ḥʷ k kʼ kʷ kʼʷ l ḷ lˀ ḷˀ ɬ ƛʼ m mˀ n nˀ p pʼ q qʼ qʷ qʼʷ r rˀ s ṣ t tʼ w wˀ x xʷ x̣ x̣ʷ y yˀ ʕ ʕˀ ʕʷ ʕˀʷ.

and "V" equals any of the following vowels: á, a, í, i, ú, u, ə́, ə.

and a "word" in a phr is defined as a string preceded by > or whitespace, ignoring any morpheme delimiters,

IF a pron:seg type="p" begins with the string CyV,

OR IF a phr type="p" contains a word which begins with the string CyV,

OR IF a ref begins with the string CyV,

THEN add an i before the y when generating the orth.

I think this is pretty straightforward, although there are then some contexts we'll have to find, check and manually correct: CyV when not word-initial, other Cy and Cw sequences, word-initial šyC sequences, and auto-orthed šiyV sequences.

2) Also, here is the final rule re: removing more stress marks in orths: "If there is only one vowel in a word, remove all stress marks from the word."

Here's my attempt to state it as an algorithm:

Where "V" equals any of the following vowels: á, a, áa, aa, í, i, íi, ii, ú, u, úu, uu, ə́, ə, ə́ə, əə.

IF a pron:seg type="p" contains only one V

OR IF a word (delimited by > and whitespace, or whitespace and <, or whitespace and whitespace, ignoring any morpheme delimiters) within a phr:seg type="p" contains only one V

OR IF a ref contains only one V

THEN replace the following when generating the orth:

á with a
í with i
ú with u
ə́ with ə

Currently, allomorphs are not included in the appendix indexes, and they should be (listed immediately after the first). This will require changes to the outputEntry template. However, in addition, the hcmc:getAffixPrefix(), hcmc:getAffixSuffix() and hcmc:getAffixDelimiter() functions will also need to be updated so that they are not as crude as currently. Right now, they read the first descendant::symbol element, but in fact they'll have to be aware of which allomorph is the subject of the operation, and choose the correct symbol where there is a <vAlt> element.

If there are two instances of the same root's xml:id in a word's hyph, it's because the root morpheme is split up by an infix. These infixes need to be handled as follows:

-- when printing the hyph, replace the following strings:

-ʔ- with <ʔ>
+a+ with <a>
+C₂+ with <C₂>
+CVC+ with <CVC>

-- when generating the translated hyph,

a) Delete the second/rightmost instance of the root after these morphemes: inchoative (xml:id="ʔ"), characteristic (xml:id="CHAR"), out of control (xml:id="OC"):

For example: [[√ʔiɬ<CVC>n-úl • √eat<char>-attrib]]

BUT, if the root has no gloss, DO keep the second part of the root:

For example: [[k-√cúwˀ<CVC>x=ánaʔ • loc-√cúwˀ<char>x=ear]]

b) Delete the first/leftmost instance of the root before the repetitive morpheme (xml:id="REP"), and put the root symbol before the second part of the root.

For example: [[√p<a>tix̣ʷ • <rep>√test]]

Again, if the root has no gloss, keep the first part of the root.

For example: [[√p<a>tix̣ʷ • √p<rep>tix̣ʷ]]

MDH: I BELIEVE THIS IS FUNCTIONAL AS OF 2014-03-05.

Here's a further explication of how to generate and format the "translated hyph", as proposed in this blog:

http://hcmc.uvic.ca/blogs/index.php?blog=10&p=11777&more=1&c=1&tb=1&pb=1

-print each component morpheme's <label>, if it has one
-if it has no <label>, print the first <gloss> in the entry

-if the gloss includes more than one word, separate them with periods, as in: √look.for

-if it has no <gloss>, just print the contents of the <m>, with no question mark or special formatting

-separate the hyph and the translated hyph with the bullet character, • U2022, size 8 font

-format the contents of <label>s in small caps. (We will still use full capitals at the beginning of Sbj, Obj, and Poss, because they sometimes occur in combination with other labels – e.g. 1sgSbjTr. We will also use full capitals for Tr and Intr when they occur in combination with other labels.)

-where an <m> corresponds to more than one morpheme, separate the labels with periods, as in:

[[√ƛʼaʔá-n-n • √look.for-ctl-tr.3Obj.1sgSbjTr]]

ECH will go through and check consistency of abbreviations in defs, notes and xrs in all 5 affix files, pron, and particles.

Documenting some more decisions which will affect the final form of the print dictionary.

1) Cits for affixes

For the time being, we are suppressing cits for affixes - that is, cits which have not been autophonemicized. It's on our To Do list to go through and check that all these cits exist elsewhere as full entries. We will decide how or whether to display cits for affixes later. We can harvest examples from entries containing each affix, and either print them as full cits, or print page references to their full entry. If there is not enough space to print all cits for affixes and keep the dictionary under 1000 pages, we could just print a few cits for each affix, or leave them out entirely. To be decided.

2) Names

-placeNames, orgNames, flora, fauna, and StoryPeople are to be included in the main dictionary as regular entries

-personal names are to be excluded from main dictionary and placed in a separate appendix (if we have enough space in the final print version). Include hyph. SMK has emailed EB to confirm these instructions, 4Mar14. Awaiting response.

If we go with the Personal Names appendix, would it be possible to continue to print cross-references to personal names, and add a page number pointer to the appendix?

If not, we should search for all <xr>s which contain a pointer to a persName xml:lang="col", and go through and make sure the refs are in their own separate <xr> tags. There shouldn't be a lot of these.

MDH: I BELIEVE THIS IS FUNCTIONAL AS OF 2014-03-05.

All affix entries should include delimiters adjacent to the orth. Here's how to determine what delimiters to use where:

(Infixes will require some delicate handling, as they are allomorphs of prefixes or suffixes. This is encoded with @n values in the <form> and <symbol> tags.)

- if the affix entry contains <f name="positionType"><symbol value="infix"/></f>, put < before the orth, and > after the orth

-ELSE if the affix entry contains <f name="positionType"><symbol value="suffix"/></f>, put the delimiter before the orth

-ELSE if the affix entry contains <f name="positionType"><symbol value="prefix"/></f>, put the delimiter after the orth

AND THEN

- if the affix entry contains <f name="derivationalType"><symbol value="lexical"/></f>, use =

-ELSE if the affix entry contains <f name="derivationalType"><symbol value="reduplicative"/></f>, use +

-ELSE for any other entry in the five affix files, use -

MDH: I believe this is done as of 2014-03-14.

-grammatical affixes, lexical affixes, clitics, particles, and inferred roots will all appear with full entries in the main alphabetical dictionary

-we will also have four appendices, which will list

-all grammatical affixes (those in the five affix xml files)
-all lexical affixes (from lex-pref.xml and lex-suf.xml)
-all clitics (pron.xml) and particles (particles.xml),
-all roots (but not stems)
(i.e. anything with <f name="baseType"> <symbol value="root"/></f>)

... with brief pointers to their full entries in the main alphabetical dictionary

-place these appendices before the morpheme index.

-the pointers will include orth, pron:seg type="p", def:seg, and page reference, with the same formatting as in the main dictionary entries

This is a lower-priority task to be done after more data is edited.

We are hoping to use superscript numbers to distinguish homophonous roots. This presents some challenges.

One is that in Aboriginal Serif, superscript 1 (U2071) is i. However, U00B9 (185) seems to provide a superscript 1 also.

The other question is HOW to generate these superscript numbers from our data. If we were vigilant about standardly naming the xml:ids of homophonous roots with _#, could you print the number in superscript after the orth of the root in the entry, MDH?

For example, we current have four roots with the phonemic transcription kʼʷəƛʼ. Their xml:ids are

"kʼWəƛʼ"
"kʼWəƛʼ_2"
"kʼWəƛʼ_3"
"kʼWəƛʼ_4"

If we renamed the first one "kʼWəƛʼ_1", could you look for the number in the xml:id and use it to add a superscript number after the orth, and after references to the root in <xr>s?

Note for MDH: The current sort works on orths; to sort collections of numbered entries, the orth passed to the sort function will have to have the appended numeral from the xml:id.

Note to selves: We also need subscript 1 and 2 for reduplicants in hyphs. MDH has asked Chris Harvey to add them to AbSerif. If Chris does not respond, an alternative would be for MDH to use the subscript characters from another serif font.

This is the first of several blog posts re: formatting for the print dictionary. I am posting this information here to help us remember what we decided, and why!

1) Space-saving abbreviations:

--Replace the following content before printing <note>s:

-Suggested form. with «s.f.»

-Meaning unclear. with «no def.»

-any <note> beginning with "Definition inferred" with «def. inf.»

--For entries with name or loanword features - i.e.

<f name="name"><binary value="true"/></f>

and/or

<f name="loanword"><binary value="true"/></f>

print the following abbreviations immediately after the phonemic transcription

«nm.» for names

«lw.» for loanwords

--Inferred root and stem entries include one of the following editorial <note>s:

Root entry added based on attested complex forms.
Stem entry added based on attested complex forms.

-Suppress these notes, and put an asterisk (not bold) after the <orth> when the inferred entries appear in the main dictionary, root appendix, and morpheme index.

2) Orth the content of <ref>s in <xr>s too.

3) More about entries with multiple forms:

The current handling of entries with multiple <form>s looks great. Please add:

-a space between the orth and the page reference in the secondary entry (DONE, MDH 4Mar14)

-if an entry has multiple <form>s with @type="allomorph", separate these allomorphs with a tilde ~ (surrounded by spaces) in the main and secondary entries - e.g.:

=úlʼəxʷ /úlˀəxʷ/ ~ =lʼəxʷ /lˀəxʷ/

-DO NOT create secondary entries for allomorphs of affixes - that is, for <form>s with @type="allomorph" within the five affix files, pron.xml, and lex-suf.xml

From SMK:

A couple of weeks ago, we "downgraded" the clitics in the sort by preceding any clitic values with "0000_" when generating the sort key, and then stripping the added bit out again before calculating the indent levels.

I think we need to precede the aspectual affixes with 0000_ ... and then downgrade the clitics further by preceding them with 0000_0000_.

These are the aspectual affixes:

s-IMPF
ʔas
ʔac
sac
kaɬ-PR
kas
mix

And these are the clitics:

kn
kW
kp
kt
lx

Here are some requests for formatting changes to the morpheme index, per yesterday's discussion with ECH.

-if possible, nothing should be indented more than 3 levels.

-make the indents larger, so it's easier to see the different levels

-remove the group headings, and the spaces between groups

-bold the plain root/stem

-include the following on each line:
-Nxa'amxcin word (orth), size 12 font
-first English def (not gloss), size 10 font
-hyph and "translated hyph" in size 8 font
-if possible, page reference to this word's full entry in the main alphabetical dictionary

More to follow re: generating the "translated hyph"!

ECH and SMK noticed a few more issues with rendering of <note>s in the Names dictionaries generated on 2013-10-17. See for examples names_only_with_related_linguist.pdf.

1) For entries with defs including the following,

<def>
<seg>
<note type="editorial">Meaning unclear.</note>
</seg>
</def>

... "Meaning unclear" is showing up twice in the pdf file - apparently once as the contents of the <seg>, and again as the contents of the <note>. It only needs to appear as a <note>.

2) Please indent entry-final notes to parallel the rest of the entry.

3) Please add more space between an entry-final note and the beginning of the next entry. At present, it's not clear in the printout whether an entry-final note belongs with the preceding entry or the following one.

I ran some queries on where we have placed <note> elements thus far, and concluded that they should be rendered as follows in the print dictionary output.

1) Cultural, comparative, and editorial notes should appear in the print dictionary, and on the website. (Internal, referToEwa, and referToElders notes should NOT appear in the print dictionary, nor on the website.)

2) Render these elements immediately followed by all the (immediate child) <note>s they contain:

entry (some editorial notes that begin with a non-English word begin with a small letter)
form (some editorial notes that begin with a non-English word begin with a small letter)
sense
def
def:seg
cit
quote:seg

3) A <note> inside a <pron> should be rendered after its preceding-sibling <seg> and <bibl> pair. If there is no <bibl>, render the note after its preceding-sibling <seg>.

Similarly, a note inside a <quote> should be rendered after its preceding-sibling <seg> and <bibl> pair, or <phr> and <bibl> pair.

4) <note>s should never appear within these elements. (I have added this reminder to the Dictionary Editing Manual.)

div
pron:seg
hyph
xr

5) I also tried to standardize the formatting of <note>s to begin with a capital letter and end with a period. However ...

-Most comparative notes have the form <note type="comparative" resp="psn:MDK">CA. {a Coeur d'Alene word}</note>. They do not currently end with a period. MDH, can you please do this globally if you think it is necessary?

-There are 4036 editorial notes in the database, of which 1688 are "Meaning unclear." and 1560 are "Root entry added based on attested complex forms." MDH, can you help narrow down the finding and fixing of initial capitals and final periods in the other 788 editorial notes??

6) I have not tried to formalize or summarize MDK or EB's language in the cultural notes. I think we should render them in smaller type, and mention in the introduction that these are reproduced exactly as collected / contributed. This is consistent with what other dictionaries have done.

7) Delimit <note>s with « ».

We have identified the following repetitive steps that the editors are doing. We're hoping these steps can be done globally, programmatically. Please make the following global changes in all files with status="unedited", and Sarah and Caitlin's "editing" files, c.xml and x-uvul.xml.

1. DONE, 9Aug13: Comment out hyphs in monomorphemic entries.

2. DONE, 9Aug13. REVISED with bug fixes, 9Sep13:

For inferred root entries, change structures like this:

<entry xml:id="qəm">

<form>
<pron>
<seg type="p">qə́m</seg>
<bibl><!--[No source]--></bibl>
</pron>
<!--Original hyph element before phonemicization:-->
<!--<hyph xmlns="http://www.tei-c.org/ns/1.0">
√<m corresp="m:UNASSIGNED">qəm</m>-</hyph>-->
<!--<hyph>√<m corresp="m:UNASSIGNED">qəm</m>-</hyph>-->
</form>

<sense> </sense>

<!--[Not yet edited.]-->
</entry>

to this:

<entry xml:id="qəm">

<form>
<pron>
<seg type="p" subtype="i">qəm</seg>
<bibl corresp="psn:ECH">ECH</bibl>
</pron>
</form>

<sense>
<def>
<seg><note type="editorial" resp="psn:ECH">Meaning unclear.</note></seg>
<note type="referToElders" resp="psn:SMK">Is qəm a word by itself? If so, what
does it mean? Click 'other entries containing this morpheme' for examples of
words with the root qəm.</note>
</def>
</sense>

<fs>
<f name="baseType">
<symbol value="root"/>
</f>
</fs>

<note type="editorial" resp="psn:ECH">Root entry added based on attested complex forms.</note>

<!-- [Editor: please double check the following and update this entry accordingly: Is this a root or a stem? Update <symbol value=> Was it inferred by ECH or MDK? Update <bibl> Has it been added based on several attested complex forms, or just one? Update <note> above.]-->

<!--[Not yet edited.]-->
</entry>

This involves the following steps:

-remove stress mark from contents of pron:seg

-add subtype="i" within the pron:seg tag

-replace <bibl><!--[No source]--></bibl> with <bibl corresp="psn:ECH">ECH</bibl>

-replace empty <sense> </sense> with the following. Can you embed the contents of the pron:seg into the contents of the <note>??

<sense>
<def>
<seg><note type="editorial" resp="psn:ECH">Meaning unclear.</note></seg>
<note type="referToElders" resp="psn:SMK">Is contents of pron:seg a word by itself? If so, what does it mean? Click 'other entries containing this morpheme' for examples of words with the root contents of pron:seg</note>
</def>
</sense>

<fs>
<f name="baseType">
<symbol value="root"/>
</f>
</fs>

<note type="editorial" resp="psn:ECH">Root entry added based on attested complex forms.</note>

<!-- [Editor: please double check the following and update this entry accordingly: Is this a root or a stem? Update <symbol value=> Was it inferred by ECH or MDK? Update <bibl> Has it been added based on several attested complex forms, or just one? Update <note> above.]-->

3. MDH attempted, 13Aug13, but no matching contexts can be found in the data:

Within each <sense>, remove defs which duplicate the <seg> and following <bibl> in a <quote>. (These were mistakenly copied twice in the Lexware to XML conversion.)

For example, change this:

<sense>
<def>
<seg>I <gloss>hear</gloss>d you</seg>
<bibl corresp="psn:W">W8.138</bibl>
</def>
<def>
<seg>I did <gloss>not</gloss> <gloss>hear</gloss> you very well</seg>
<bibl corresp="psn:W">W8.139</bibl>
</def>
<cit>
<quote>
<phr type="p" subtype="i">lút x̣ə́st √cq=ánaʔ-mn-c-n</phr>
<bibl corresp="psn:ECH">ECH</bibl>
<phr type="n">lút x̣ə́st √cq=ánaʔ-mən-č-ən</phr>
<bibl corresp="psn:W">W8.139</bibl>
<seg>I did <gloss>not</gloss> <gloss>hear</gloss> you very well</seg>
<bibl corresp="psn:W">W8.139</bibl>
</quote>
</cit>
</sense>

to this:

<sense>
<def>
<seg>I <gloss>hear</gloss>d you</seg>
<bibl corresp="psn:W">W8.138</bibl>
</def>
<cit>
<quote>
<phr type="p" subtype="i">lút x̣ə́st √cq=ánaʔ-mn-c-n</phr>
<bibl corresp="psn:ECH">ECH</bibl>
<phr type="n">lút x̣ə́st √cq=ánaʔ-mən-č-ən</phr>
<bibl corresp="psn:W">W8.139</bibl>
<seg>I did <gloss>not</gloss> <gloss>hear</gloss> you very well</seg>
<bibl corresp="psn:W">W8.139</bibl>
</quote>
</cit>
</sense>

Searching for duplicates such as this one this could be more difficult in cases where programmatic gloss tagging has been done differently in the defs than in the cits. Duplicate defs to be deleted should contain:

-a seg identical to a quote:seg in a following cit, ignoring <gloss> tags and the *character, and
-a sister bibl completely identical to a quote:bibl in a following cit.

4. DONE, 13Aug13: When two or more defs in the same <sense> are identical, collapse them together, but concatenate their <bibl>s. For example, change this ...

<sense>
<def>
<seg>Nez Perce</seg>
<bibl corresp="psn:EP">EP2.84.8</bibl>
</def>

<def>
<seg>Nez Perce</seg>
<bibl corresp="psn:JM">JM2.141.2</bibl>
</def>
</sense>

to this:

<sense>
<def>
<seg>Nez Perce</seg>
<bibl corresp="psn:EP psn:JM">EP2.84.8; JM2.141.2</bibl>
</def>
</sense>

5. DONE, 7Aug13. Please add <name type="flora"> and <name type="fauna"> to the schema, so they will appear in the dropdown list of values.

Tasks arising out of today's meeting:

• Add MLW to the ODD/schema (personography item).
• Add handling for an <entry> with no <form> element (xml:id="unknown") [SMK adds: we will also want to suppress this "unknown" entry from the print dictionary.]
• Build a PDF dictionary with only the affix files and lex-suf (for reference by team).
• In lex-suf, and any affix files which contain matches for the XPath below, do an identity transform which in this context:

  seg[@subtype='i'][following-sibling::bibl[1][@corresp='psn:MDK']]
  

  removes the @subtype value.
• Remove traffic lights from names page (if straightforward).
• Add light-edited (yellow) and light-proofed (green) to the document status values in ODD and schema, then add traffic-light handling.
• Add all light-edited and better docs to the XInclude file and validate to catch any duplicate ids.

Here are a few requests for the Names page on the website:

DONE -exclude Lexical Suffix entries

DONE -fix the display of sic/corr, so that only “Wenatchi” displays, not “WenatcheeWenatchi” (See for example the entry for “Sam George”.)

DONE -put flora (plants) and fauna (animals) in the link text at the top of the page

DONE -separate out the sorting into Nx-Eng and Eng-Nx pages. Ideally, users should be able to view the complete list, or any of the six lists by name type, sorted either by Nxa'amxcin name or by English name. The present setup with Nx and Eng names mixed together in the Name column is somewhat confusing. Continue to sort the Nx-Eng lists based on name tags in prons. Sort the Eng-Nx lists based on name tags in defs.

-For the present, exclude name tags in orths when generating these lists.

Sarah says:

I think we decided on Monday (talking with Ewa) that you should go ahead and use the full def:segs instead of the glosses in the "get related words" and "other entries containing this morpheme" lists. The glosses are only intended as headwords for the English-Nx word list.

Our example was cìqqnúnn, with the def:seg "I accidentally dug up something". The gloss tags are "dig", "dug", and "accidentally". We want the Nx word to appear (with its def) under all three headwords in the English-Nx word list, but we don't want a learner to look at the "get related words" list and think the word can be used to mean just "accidentally".

DONE, 18Mar13.

I have put a list of feature structure questions for further consideration into the docs folder in the SVN respository. It's called feature_structure_questions_Jan2013.odt.

ECH's paper copy of these questions, with our notes on it, is in the blue folder in the top box of Lexware data!

DONE 2013-02-28.

Our new feature structures for names and loanwords are displaying on the website as NAME: TRUE and LOANWORD:TRUE.

Please hide the :TRUE part of these features from the website display.

Just came across an example where:

<phr type="n">√ƛʼécʼ-p=ap Račəméntən</phr>

got autophonemicized to:

<phr type="p" subtype="i">√ƛʼícʼ-p=ap ʔḥacmíntn</phr>

The capital R was correctly changed to ḥ, but where did the glottal stop come from? Did the "insert glottal stop before a word-initial vowel" rule somehow apply between the removal of the R and the addition of the ḥ?

Hmmm.

There are 15 other instances of word initial ʔḥ generated from R in the data. I can just fix them with find-and-replace, but I'm curious about how they were generated.

DONE 2013-02-28.

Please adjust the display of the contributors' roles. Currently, "Fluent Speaker" and "Elder" appear to have a space after them, so for contributors who are both, we see Fluent Speaker space comma space Elder space.

1) In the email that pops up when EB or SC clicks on an Email link, please add the following fields to the template:

Date:
Speaker:
Writer:
Typist:
Comments:

2) Please send the emails from this page to skell@uvic.ca and caitlinb@uvic.ca as well as ECH and MDH.

3) The question in the entry for "Paschal Sherman" is not showing up on the website, although it's there in the xml file. SMK can't figure out why ...

4) ECH needs a way to prioritize the Questions for Elders – e.g., questions on lexical suffixes are low priority.

5) If we start to get a large volume of feedback coming from the community, ECH would like a tool for speeding up entry of responses. Here are some initial ideas ...

-responses to Questions for Elders would appear on a new page on the website, instead of coming as email responses

-for each response, the editor (likely ECH or SMK) could select from options like

-ignore
-defer
-add to existing entry as editorial note
-add to existing entry as new <def>
-add to existing <def> as new <bibl>
-add to existing entry as new pron:seg type=“n”
-add whole new entry in new-data-2013.xml

-Please add a menu button for accessing the Verbs page.

-Please make the page title “Verb list” instead of “Word list”.

-Add an explanatory line below the title: This list includes the verb forms recorded in Dale Kinkade's Nxaʔamxcín materials.

-We don't want to combine the verb list with the Questions for Elders page. But we do need a way to mark which verb forms EB, SC, and PCS have already reviewed. SMK suggests the following:

If an entry contains psn:EB, psn:SC, or psn:PCS (i.e., they have commented on it, and we have recorded their input in the entry), flag it on the verbs page as reviewed – perhaps with an icon (a checkmark?) next to the editing status “traffic light”?

-We will eventually add a separate verb paradigms page.

-We've figured out a better way to identify verbs in the data, based on the transitive object and subject endings. Now we just need to finalize our list of those endings, and figure out how to work around endings like “-n” which could be one of many morphemes.

DONE

1)

Process date tags such as the following to show the @when attribute when the date tag has no text in it.

<bibl corresp="psn:PCS">PCS <date when="2013-02-06"></date></bibl>

2) Roles of contributors:

Please make the full description appear after each person's name on the Contributors page.

EB distinguishes "Elders" who have significant cultural knowledge, and "Fluent Speakers" who have language knowledge. So some of the contributors will be one or the other, and some could be both.

SMK assigned me these tasks:

1) DONE Please sort the names with the following headings, using the tags in the pron:seg type="p"?

Personal Names (persName)

Place Names (placeName)

Tribes (orgName) 

People in Stories (name type="storyPeople")

Animals (name type="fauna")

Plants (name type="flora")

2) Printable PDF view of the names page for MM and SB to work from - Full view, with the entries expanded. MM needs to be able to see:

• phonemic transcription with its bibl
• phonetic transcriptions with their bibls
• hyph
• all defs and their bibls

She will also need a printable view of the Contributors page.

3) Get the orthography working. (Note: MM does not use the community orthography, but rather MDK's! ECH will ask GM what orthography SB uses.)

4) DONE One thing which arises from yesterday's feedback from SC is that we should hide glosses with type="i" from the Moses-English displays.

For example, in the verbs list we currrently see:

ʔacḥámˀsn I stopped him from getting in a fight, forbid, stop

"Forbid" and "stop" are inferred glosses that I added for the purpose of creating the English-Moses word list, but they're not direct translations of ʔacḥámˀsn. So of course SC and PC replied that "forbid" and "stop" should be removed. Can you please hide the inferred glosses from all the Moses-English pages?

The English-Moses word list is working correctly, in that ʔacḥámˀsn appears under the English headwords "forbid" and "stop", as well as the more specific "stopped".

DONE 2013-01-29.

1. Change all name feature structures from

   <f name="category">
   <symbol value="proper-noun"/>
   </f>
   

   to:

   <f name="name">
   <binary value="true"/>
   </f>
   

2. Change all loanword feature structures from

   <f name="baseType">
   <symbol value="loanword"/>
   </f>
   

   to:

   <f name="loanword">
   <binary value="true"/>
   </f>
   

3. Comment out existing compound feature structures:

   <fs>
   <f name="baseType">
   <symbol value="compound"/>
   </f>
   </fs>
   

4. Comment out existing compound lexical suffix feature structures:

   <fs>
   <f name="baseType">
   <symbol value="suffix"/>
   </f>
   <f name="derivational">
   <symbol value="lexical-suffix-compound"/>
   </f>
   </fs>
   

Here's a summary of what MDH needs to do next to improve the Autophonemicizer for <phr>s, and implement an Autophonemicizer for pron:segs:

1) Add new step 5c from Autophonemicizer2.doc to the autophonemicizer for <phr>s.

2) Add new step 7 from Autophonemicizer2.doc, to compare generated <phr type="p" subtype="i">s to attested <phr type="n">s and collapse identical ones. This will be a subsequent step to the whole autophonemicization process.

3) Adapt the autophonemicizer for pron:segs

Note to selves for the future: how will we deal with English homophones for sorting the Eng-Nx word list? If we remember, let's list the ones we come across here. So far we have:

fire - "flames" vs. "dismiss employee"

fast - "quick" vs. "abstain from food"

hide - "skin" vs. "conceal"

cold - adj or noun "coldness" vs. "illness"

saw - "tool" vs. past tense of see (replaced with <gloss subtype="i">see</gloss>, SMK 21May13)

close (near) vs. close (shut)

stern (back of boat)

game (recreation)

watch (observe) vs. watch (wristwatch)

back (body part)

top (toy) vs. top (of something)

fish vs. fish (catch fish)

See autophonemicizer2.doc in moses/trunk/docs. It can be done with XSLT and regular expressions.

I have entered all the lexical suffixes from MDK's cards, but have not entered their dictegs, on the assumption that these words exist elsewhere in the database, organized by their prefix or root.

As I was entering the lexical suffixes, I only checked for their dictegs elsewhere in the data if the dictegs were:
-personal names, or
-examples of lexical suffixes with Meaning Not Determined.

I found that the vast majority of these dictegs do exist elsewhere in the data, BUT:

-sometimes additional info is on the lexical suffix card (e.g., Sam Miller)
-sometimes the word only exists in another dicteg (e.g., shotgun)
-sometimes the morpheme breakdown is different (e.g., Nellie Leo, Canada goose)
-sometimes the entry is not all there due to a bad conversion from Lexware (e.g., Paul Timentwa)

Our approach to this issue will therefore be:

-wait until all the alphabetical files are edited

-check that all dictegs NOT yet entered from the lexical suffix cards exist as entries elsewhere in the data. Enter any missing information, and address differing morpheme breakdown.

-check lexical suffix dictegs that WERE entered at the Lexware stage:

--check cards against Lexware. Pencil any changes onto the Lexware printout.

--check whether the dictegs exist as entries in other files. Refer to phr_to_seg_matches_2.odt.

---if phr to seg is a perfect match in the list, search on the xml:id to view the entry. Check whether the translation is also a match. If the translation adds any new information that's not in the entry already, copy the new information from the lex-suf file into the alphabetical file, with a Comment about where it came from. Then Comment out the dicteg in the lex-suf file.

---if phr to seg is NOT a perfect match in the list, search more carefully on the phr and/or the translation to try to find the entry, and why it didn't match. Check Lexware printout for discrepancies. Inform Martin of any perfect matches NOT found by the search.

----if the entry can be found, copy any relevant information from the lex-suf file into the alphabetical file, with a Comment about where it came from. Then Comment out the dicteg in the lex-suf file.

----if the entry really cannot be found, copy the whole dicteg into the alphabetical file (near its root), with a Comment about where it came from. Build a well-formed entry, changing the <phr> to pron:seg and the <seg> to def:seg. Then Comment out the dicteg in the lex-suf file, noting that it could not be found elsewhere and has been copied into the appropriate alphabetical file.

Here are some editing tasks that Ewa needs to come back to:

1) Review entries with [No meaning specified.] in the following files, and add inferred definitions or change to [Meaning unclear.]

h-phar-part1.xml (3 entries)

h.xml (4 entries)

phar-w.xml. (1 entry)

SK has now updated the project documentation (DictionaryEditingManual.odt, NotesOnDefinitionsAndGloss-Tagging.odt, and EditorialDecisions.odt) to include the corresp="psn: " attribute, as well as our decisions from last December around <persName>, <placeName>, and <orgName> tags. (The latter are also laid out in DecisionsOnMarkupOfNames.odt in the docs directory.)

Read these over and update the XML Markup Documentation.

Met to plan the next couple of months of work and preparation. Takeaways:

• If both the Connections application and the conference abstract are successful, then we should write a full-length paper on TEI/LMF, and/or on the use of TEI in our project. We should consider approaching LR as a co-author for this.
• We should write an abstract for DH2013 on one of these topics, and in preparation for that, we need to read the papers starting on pp 167, 169, 280, and 286 of the DH2012 abstracts.
• We need to identify a core test set of items which are internally coherent (in other words, some root morphemes, and some complex entries composed only of those morphemes) for input into Lexus.
• I need to review the DEL application when ECH has finished it (deadline v. soon).

ECH will provide relevant background information on the Contributing Speakers to be listed on the website, particularly birth dates, death dates, and how the speakers are related to each other, where available.

EDIT by MDH 2011-12-22: This task has been completed. I did add the list of Editors to the Contributors page because it's simpler than not adding it. We can always remove it if necessary. Task marked Completed.

1) MDH will add the list of speakers from the personography to a new page called Contributing Speakers. (No need to add the list of Editors at this time; they are all acknowledged on the home page.)

2) MDH will move the last three buttons from the side menu (Status, XML Markup, Project Blog) to a new page, to make the first menu shorter. The button linking to the new page will be called "About".

3) MDH, ECH, and SMK need to meet to make sure we're all on the same page re: markup of personal names and place names. Meeting tentatively set for 9:00am Thursday Dec. 15.

When generating the Other Entries line in def, it should look like this:

Other entries containing this morpheme: 0 [not a link]

Other entries containing this morpheme: 3 [link which retrieves them]

The following requests came up in ECH and SMK's discussion of the database display today. None of these requests are urgent, but we hope MDH can accomplish them in this or the next phase of the project.

1) Display of dictegs:

Please display the <phr>'s and <seg> within a dicteg each on a separate line, so that we see

/qʼʷáɬstmsta ʔací ʔin-√qʼʷɬt-á-x̣ƛʼcíntn/ ECH
[qʼʷáɬstəmsta ʔacé ʔen-√qʼʷɬ-tá=x̣ƛʼčéntn̩] Y15.93
pack your pack-horse! Y15.93

instead of the current:

/qʼʷáɬstmsta ʔací ʔin-√qʼʷɬt-á-x̣ƛʼcíntn/ ECH [qʼʷáɬstəmsta
ʔacé ʔen-√qʼʷɬ-tá=x̣ƛʼčéntn̩] Y15.93 pack your pack-horse!
Y15.93

2) The symbol values of atomic entries (e.g. ROOT) should be displayed after the phonemic form of the word, before the sources. Currently the symbol value is displayed after the contents of the pron.

This looks fine in entries like:

/qʼʷácʼ/ ECH (ROOT)

But it gets messy if there is also a narrow transcription of the form ... and if it's long and the line starts to wrap:

/qʼʷaʔák/ A72; Y1.104; JM3.145.1 MG JM4.23.9 [qʼʷaʔaq] G74 (ROOT)

ECH would like it to look like:

/qʼʷaʔák/ (ROOT) A72; Y1.104; JM3.145.1 MG JM4.23.9
[qʼʷaʔaq] G74

3) Would it be possible to show/hide all the source information in the web database display? Could the user click a button to make all the bibl information disappear or reappear?

4) Place Names

-are tagged with <placeName> within def:seg
-entries containing this tag appear as regular entries in the dictionary
-entries containing this tag could ALSO be displayed on a separate Place Names page.

5) Personal Names

-tagged with <persName> within def:seg
-if an entry contains a <persName> tag, the whole entry should be hidden from the main dictionary database display
-entries containing a <persName> tag should be listed on a separate Personal Names page

6) Mapping bibls to elicitation dates

Re: the personography, MDH had asked if MDK's notebooks are dated. The answer is yes, but the dates are only recorded on the notebooks themselves in the U of Washington archives. So the idea of mapping the numbers in the bibls to the dates will have to wait until one of us can go to Seattle and look at the notebooks.

• Make <note> elements display wherever they show up in the structure.
• Make the list of <dicteg>s into an expand/collapse structure if there are more than two of them.

We thought of another request for the database display:

When displaying an atomic entry, MDH will add an option to click and see all the entries which contain that morpheme.

This will be useful in the Refer To Elders list, where we are often asking them to define a root. They may never have encountered the root in isolation, so they will need to see the words it occurs in.

The functionality will also be nice to have in the Finished Entries and All Entries lists, where entries with the same root don't always sort together alphabetically due to prefixes.

Sarah wrote:

I have been digging through the file boxes looking at the Particle file, and as far as I can see, most of the Particle file cards have NOT been entered. There is only Lexware printout for the first 3 file cards (plus one sentence off the 4th card), and this corresponds to affix-part.xml.

So we need to enter the rest of the Particle file directly from the cards.

-----------

Ewa wrote:

I have just been looking through the particle file cards, and doing some global searches for examples containing the particles. Based on a random sampling I think it is (almost) safe to say that all the dictegs in the particle file are already input as examples!

--------

We decided to proceed by inputting just the forms and defs for all the particles now - so that they all have entries with xml:ids.

Later, we will figure out some way to connect the particles to their relevant dictegs. It’s easy to find the dictegs by searching through the files all at once. So we will need to get Martin to help us connect the particles and the “found” examples.

I have now created entries for the following lexical suffixes in lex-suf-new.xml, as I could not find them in lex-suf.xml, lex-suf-nom.xml, or affix.xml

úlˀəxʷ (xml:id="ulˀəxW")
xn (xml:id="xn")
qín, qn (xml:id="qin")

ús "eye, face, fire, road" (xml:id="us")

WE NEED TO GO BACK THROUGH THE LEXICAL SUFFIX FILE CARDS, AS IT APPEARS NOT ALL OF THEM HAVE BEEN ENTERED!

None of the example sentences in dictegs in affix.xml have been phonemicized.

When/if Ewa adds these phonemicizations, she will also need to move the <bibls> for the attested examples, so that they refer to the narrow transcription and the gloss, not the whole <quote>.

For example, change this:

<cit>
<quote>
<phr type="narrow">kˀɬ‐√kʷan‐xʷ=cn</phr>
<seg><gloss>I answered him</gloss></seg>
</quote>
<bibl>JM3.57.3</bibl>
</cit>

To this:

<cit>
<quote>
<phr type="phonemic" subtype="unattested">kʼɬ‐√kʷan‐xʷ=cn</phr><bibl>ECH</bibl>
<phr type="narrow">kʼɬ‐√kʷan‐xʷ=cn</phr><bibl>JM3.57.3</bibl>
<seg><gloss>I answered him</gloss></seg><bibl>JM3.57.3</bibl>
</quote>
</cit>

To clarify which phonemic transcriptions in the database were recorded by MDK, and which have been derived by ECH from MDK's narrow transcriptions, we are adding subtype="unattested" to the markup.

A phonemic form transcribed by MDK will still be marked up like:

<pron>
<seg type="phonemic">ṣə̣́nṣə̣nt</seg><bibl>JM3.20.11</bibl>
<seg type="narrow">sə́nsə̀nt</seg><bibl>Y24.40</bibl>
</pron>

(An appropriate disclaimer can be programmatically added to all of MDK's phonemic forms in the final output.)

A phonemic form derived by ECH will be marked up like:

<pron>
<seg type="phonemic" subtype="unattested">ṣə̣́nṣə̣nt lx</seg><bibl>ECH</bibl>
<seg type="narrow">ṣə̣́nṣə̣nt ləx</seg><bibl>JM3.21.1</bibl>
</pron>

A phonemic form derived by MDK (one with no source noted in the file cards or lexware database) will be marked up like:

<pron>
<seg type="phonemic" subtype="unattested">ṣə̣́nṣə̣nt lx</seg><bibl>MDK</bibl>
<seg type="narrow">ṣə̣́nṣə̣nt ləx</seg><bibl>JM3.21.1</bibl>
</pron>

This applies to <phr>s as well as <seg>s. Martin has rewritten the schema to allow for subtypes of <phr>s.

Every <seg> and <phr> should now have a sister <bibl> showing its source.

I have carried these changes through the s-rtr, c-rtr, and phar-w files, and will implement them in the affix file next.

It is also possible to put <bibl> tags higher up the tree; e.g., if everything in an entry came from the same source, only one <bibl> tag would be needed, a sister to the whole <entry>

Ewa needs to write the discussion / "disclaimer" re: Kinkade's phonemic transcriptions. See for example ṣə̣́nṣə̣nt, 'tame'.

I have just changed the following xml:ids in all the active files (including the affix file):

n --> n-CTL
nt --> n-CTL + t-TR
s2 --> s-SUBJ
kaL-pr --> kaɬ-PR
kɬ-der --> kɬ-DER
kˀɬ-der --> kʼɬ-DER

Ewa will need to ADD the following morphemes to the affix file:

=mix-LS (this is =amx, mix, ExW 'people')
(DONE, SMK 10OCt12. This entry already existed under =amx, but I have changed the xml:id to mix-LS.)

-aɬ- compound linking morpheme. Check fs for morpheme designation

n-LOC (locative prefix)

n-unknown (see sḥaƛʼƛʼnus)

k-LOC (locative prefix)

t-LOC (locative prefix)

kɬ-LOC (locative prefix)

kat-LOC (locative prefix)

niʔ (locative prefix)

t-TR (transitive suffix)

CHAR (characteristic reduplication)

OC (out-of-control reduplication, +C2)

n-SUBJ (1st person singular subject)

xW-SUBJ (2nd person singular subject)

t-SUBJ (1st person plural subject)

Ø-OBJ (3rd person singular object)

m-OBJ (1st/2nd person singular object after -stu-)

m-SUBJ (1pl subject occurring with 3 object in causative paradigm)

al (1st person plural object)

ɬ-DIR (directive)

sa (Note: one cross-reference to a morpheme "sa" already appears in the affix file.)

si

RED (total reduplication - e.g. hames+hames) [n.b.: there is already a morpheme with xml:id RED in the affix file. It's CVʔ reduplication. This needs sorting out, as total reduplication has already been marked up with RED in the h.xml file.]

m-MID (middle)
(Are other "m" morphemes missing too?)

sac (stative)

ʔin- (1st/2nd person singular possessive)

s-POSS (3rd person possessive)

ayˀ-PAST (not to be confused with the entry "ayˀ" in the lexical suffix file!)

s-SUBJ also needs its definition added.

I took a look at the file and it looks fine. I've uploaded it into the DB, and the list of words is a bit longer:

There are a couple of things I noticed. There's one asterisk still in there:

Also, there's one instance of a space at the beginning of a gloss element:

which could be eliminated -- it'll save on processing time if we don't have to strip leading and trailing spaces from gloss tags when we process them.

There's one <m> element with no sameAs reference:

which I presume is because you don't yet know what that reference would be, not having done all the affixes yet. This is a good reason for doing the affixes next, so that we can go back and fill any missing ones in before there are too many of them.

Finally, there are some things about the display of the entries which, now I look at them, I don't understand. The primary form (the headword on the web page) seems to be the <seg type="narrow"> form, rather than the phonemic form, while I suspect the sorting is being done based on the phonemic form. In addition, for an entry like "sweater" where the morpheme element can only point back to its own entry, the morpheme should not be a link; however, it is a link, and even worse, it doesn't point back to its own entry, it points to nothing.

So I'm adding this as a task for me to fix the sorting, headword display, and handling of morphemes which shouldn't link because they'd link only to themselves.

Ewa is working on the s-rtr.xml file, and has noticed this:

"in a number of entries (e.g., saplil 'flour') there are several form elements, either because there is more than one phonetic transcription attested for the entry, or there is more than one source for the entry, or there is more than one gloss for the entry. The first form element in an entry like this will have a seg type="phonemic" and, if it is attested, a seg type="narrow". But should the remaining form elements have both seg types, when this means repeating the exact same seg type="phonemic" over and over again?"

I can certainly write the code so that in the absence of a phonemic element in a particular form element, it will look at preceding-sibling form elements until it finds one, and use that instead. If that's always going to be the right thing to do, it shouldn't be too hard to implement. Adding this as a task for April: check whether there is already any handling for this, and if not, implement it.

Completed Feb 1: This task is essentially the same as the one described for the Mariage project here.

• Phase one: Rescuing the old data (basically complete)

  The initial task was to retrieve the original data from its DOS/WordPerfect/Lexware form. The bulk of this work was done by Greg, with the assistance of a piece of software (Transformer) written by me to make certain complicated search-and-replace operations easier.

  • Convert the binary files to text (a process of converting escape characters and WordPerfect codes to predictable, readable text-strings).
  • Identify each of the escape sequences used to represent non-ascii characters and character/diacritic combinations, and select an appropriate Unicode representation for it.
  • Implement search-and-replace operations in sequence to convert the data to Unicode.
  • Use the Lexware Band2XML converter (http://www.ling.unt.edu/~montler/Convert/Band2xml.htm) to turn the original data into rudimentary XML markup.

• Phase 2: XML Encoding
  (ongoing: this ball is currently in Ewa's court)

  • Decide on a suitable XML format for the data. The requirements were:
    
    • portability (format must be easily parsed and transformed)
    • efficiency (data should not have to be duplicated -- for example, the same information about the same item should not have to be encoded in two places, as an independent entry, and as a nested component of another entry).
    • standards-compliance (format must be based on an existing, well-accepted and documented standard; we don't want to have to rescue it again in future).

    We chose TEI P5 (http://www.tei-c.org/P5/), and we decided to avoid all nesting and do all linking through xml:id attributes. We also decided that each entry would be marked up in such a way as to break it down into individual morphemes, each of which would be linked through xml:id to the entry for that morpheme. In this way, most feature information for most entries need not be encoded at all, because it can be retrieved from the entries of the morphemes that constitute it. This makes the encoding simpler and cleaner, offloading much of the work onto the XML database that will store and handle the data.

  • Devise a method for migrating the rudimentary Band2XML data to the new format. This was achieved using a two-stage XSLT transformation:
    
    • Un-nesting all the entries. Nested entries were extracted and made into siblings, and derivations encoded as part of main entries were also split off into separate entries. After this stage, all entries are siblings at the same level.
    • Elaboration. The rudimentary entry information from the Lexware bands was expanded to produce a more elaborate and explicit TEI P5 structure; xml:ids, transcriptions and morphological breakdowns were created by the XSLT based on the original data, and where appropriate, linguistic descriptors were added using the TEI feature structure system (http://www.tei-c.org/release/doc/tei-p5-doc/html/FS.html).
      
  • Check and correct the results, based on the original printed/handwritten data (this is the real work!).

• Phase 3: Storage and Presentation

  • The data will be stored in an XML database, from which all presentation forms will be created algorithmically. The database system we're using is eXist (http://www.exist-db.org/), and open-source native XML database system which we have used for some years. This project will eventually use the next-generation version of eXist (1.1 or 1.2) which is currently in development, but pilot work is being done with the 1.0 beta version.
  • The interface to the data will be built in Cocoon, an open-source servlet container which provides a good basis for browser-based interaction with the eXist XML database.
  • The first output format we aim at will be a browser-based system which works like this:
    
    • A list of headwords is retrieved through a search.
    • Clicking on a headword retrieves the full entry for that item, which is inserted into the page. This is done on-the-fly using AJAX/XMLHttpRequest, which sends a query to the XML database; the database response with a block of XML, which Cocoon converts to XHTML through an XSLT transformation before sending it back to the page; the page then inserts the data into the appropriate place.
    • Each morpheme in an entry is itself a link, and clicking on it retrieves the data for that morpheme's entry, which is then inserted into the page. Thus a kind of expanding tree is generated, and an entry can be expanded until it contains all the information on all its constituent morphemes.
    • Each morpheme entry includes a "see also" link which would call back through AJAX to get a link to all other items in the database which include that morpheme. Clicking on one of these would retrieve its entry and insert it.

  • The search functionality basically works like this:

    • There is a drop-down list of "what fields to search": Orthography, Transcription or English.
    • If you choose one of the first two, you get a button bar to enter special characters.
    • The choice also determines which fields will be searched.
    • A checkbox also allows fuzzy searching. This involves translating IPA to plain latin, and searching agains plain latin conversions of the fields searched. This will probably require the construction (through XSLT, on the fly) of parallel indexes of plain latin fields, so it can be relatively fast.
    • Searches will pull back results which can be added selectively to your "notebook"; you can then take your notebook to the "print shop" where you can configure a page (accessible through URL) or a PDF printable output to create a vocab sheet or mini-dictionary.
  • Other projected output formats include:
    
    
    • Print dictionary (PDFs generated through XSLT -> XSL:FO and converted to PDF using the RenderX XEP engine). We envisage linguistic dictionaries as well as dictionaries aimed at language-learners.
    • Printable wordlists (Nxa'amxcin to English and English to Nxa'amxcin).

    • Graphical navigation devices for browsing the data such as the KirrKirr Java model used by Christopher Manning (http://www-nlp.stanford.edu/kirrkirr/doc/ach-allc2000-ver5-single.pdf).

• Phase 4: Media

  We plan to integrate audio and visual media into the database in the future.