Nxaʔamxcín (Moses) Dictionary Blog

Following discussions yesterday, I've made a minor change to the retrieval code that runs when you click on "Other entries containing this morpheme" on the website. It now retrieves only entries with the morpheme in their <hyph>, not (as before) anywhere at all.

I've made a similar change to a number of XPaths in the PDF generation code, and a quick check of the resulting PDF shows that it doesn't seem to have had any adverse effects.

That means that if the team wishes to tag <m>s in <cit>/<phr> contexts (e.g. for particles), that can be done without any side-effects on the website or on the PDF generation. I could add a feature to the website which triggers only for entries with this feature:

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

which would "Retrieve all example sentences containing this particle", but I think that should only be done if we're consistently tagging the particles in cits. Of course, if that can be done through search-and-replace (in the cit/phr XPath context) for all particles, then there's no reason not to do it since it won't cost us any time.

SMK has come up with a nice algorithmic approach to identifying reduplicants in hyphs, and converting the contents to CVC-style representations. I've coded up some XSLT to do the first two steps, and we've tested on a couple of files. If no problems emerge, we'll run it on everything. Then there are a series of replacement steps that she's going to do manually, because it's not quite clear whether they can be automated without risk of unexpected side-effects.

Met with ECH and SMK to plan the presentation for January. Also the process generated a new idea: in the print dictionary, the main entry list should be in a separate volume from all the indexes.

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 ə

Now that I have (almost) worked through the affix list and autohyphenated as many affixes as possible, I'm finding that editing the alphabetical files goes significantly more quickly. This is my editing procedure now:

-edit root entry

-autohyphenate all instances of that root in complex words in the file

-first pass: skim through all entries with that root and clean them up as best I can - mainly tagging any remaining morphemes and making sure gloss tags are placed properly in defs

-second pass: check that everything on the Lexware printout is present in the entries, and correct any autohyphing errors.

I could consider NOT even looking at the filecards from here on, to limit my obsessive need to proofread in triplicate. :-)

With SMK, made a range of different fixes to the orthography generation code. What we have now is the same in the fo output code and in the auto_orthography.xsl library; the latter is an identity transform that we plan to use to generate hard-coded orths which can then be manually tweaked. I think we're as close as we can be; what remains is a lot of oddities and special cases.

Suppressed display of labels in lexical affix index; special-cased the OC (out-of-control) morpheme so that it gets a reduplicant delimiter (+) instead of -, owing to its reduplicant nature (not currently reflected completely in its feature structure).

That's the complete set of changes arising out of our meeting on Wednesday.

From discussion yesterday: changed "Meaning unclear" to "Meaning not determined"; suppressed display of labels in web app; checked out some potential issues with display of various note types and resolved to stick with the status quo.

ECH has written most of the front matter, and today we worked on layout, pagination, styles etc. It all looks pretty good now, and is detailed enough to go to the Tribes for feedback.

ECH and I spent some time today looking at the complexities of orthing, with the assistance of the document SMK has been working on. We added a few simple rules to the existing algorithm (removing secondary stresses), and there's one more I can add (removing unstressed schwas at the beginning of the process).

But beyond that, the basic conclusion we came to is this:

Most of the hard decisions for the awkward cases have to be made on the basis of hyph or feature structure information. Right now, I'm not inputting that information into the orthing algorithm; it just operates on a plain phonemic transcription. In the case of <pron> orthing, it would be possible to pass in the relevant hyph and fs data. However, the orthing algorithm also has to be applied to <phr>s in <cit>s, and in that case, there is no hyph or feature structure info; any phr might contain a word from a completely different entry, and we wouldn't have any way of knowing about it.

So we think the best approach is this:

1. We do the best we can to improve the simple algorithm.
2. We run it against the existing files and create hard-coded <orth> elements (or <phr type="orth">) in the actual entry files.
3. We also write code which is designed to detect (but not handle) circumstances under which a manual fix is likely to be required (where, for instance, the sequence əxʷ appears, which might indicate m:mix or m:ulˀəxW). When we detect those cases, we add a comment to the effect that someone needs to fix the results.

Our quick tests suggest that the problem entries are likely to be in the low hundreds rather than the thousands, and a lot of the checking and fixing could be done by a good workstudy student.