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)
Fruitful discussion on how we might auto-generate orthographic representations, and check these against community-generated versions, based on morphological information, phonemic context, and phonetic context/realization rules.
I have replaced
U207B superscript minus, and
U2010 hyphen
with
U002D hyphen-minus
The latter is what occurred the most in the data, and is what you get if you type either hyphen or minus on the keyboard.
I've implemented the schema constraints described in the previous post, making @type required on <note>, and providing the documentation to ease usage in Oxygen. This will render many files invalid, since there are a lot of note elements currently lacking @type.
This took longer than it should have because the TEI Debian Roma package appears to be broken at the moment. Reported my symptoms to SR.
We have decided on the following note type values. These will allow us to organize the different kinds of notes, and later to decide which ones to suppress from the print dictionary and/or the online interface.
<note resp="psn:MDK" type="cultural"> cultural notes, from Kinkade's cards
<note resp="psn:MDK" type="comparative"> comparisons to other Interior Salish languages (Coeur D'Alene, Okanagan-Colville), from Kinkade's cards
<note type="editorial"> - should be used:
1.When a root or stem is inferred from a complex word or dicteg. In other words, when we infer an <entry>.
<note type="editorial" resp="psn:ECH">[Root entry added based on attested complex forms.]</note>
<note type="editorial" resp="psn:ECH">[Root entry added based on attested examples.]</note>
2. When the definition of a word or phrase is inferred – e.g.,
<note type="editorial" resp="psn:ECH">[Definition inferred based on complex forms containing this root.]</note>
<note type="editorial" resp="psn:ECH">[Definition inferred based on phrase containing this stem.]</note>
3. Etymological notes – e.g., “from Chinook”, “onomatopoeic”
4. Genealogical notes – e.g. ,“uncle of Jerome Miller's father”, “Henry Miller's childhood name”
5. Details on morphology – e.g.,
<def>
<seg>diminutive</seg>
<note type="editorial">[The reduplication is usually accompanied by glottalization of resonants in the word.]</note>
</def>
<def>
<seg>relational</seg>
<note type="editorial">[Attaches to motion verbs, psychological event verbs, speech act verbs, and transfer source verbs; cooccurs with transitive, causative, applicative and external possession markers.]</note>
</def>
6. Contextual notes – e.g., “said if the rabbit belongs to the person addressed”
7. Elaborations on definitions – e.g., “mainly for dried salmon that has gotten old.
<note type="internal"> - should be used for any kind of comments about the database structure, possible analyses, or for comments about notes that MDK made on his filecards, including forms MDK noted as ungrammatical. Some of MDK's notes have consequences for how we structure the entries; some of his notes are simply points that we want to keep track of, but that do not need to be shown to non-editors. So internal notes are essentially keeping track of editors' decisions and unresolved questions, and MDK's comments.
<note type="referToElders"> - questions for the Elders.
Editorial cases 1 and 2 above could also be referred to Elders for confirmation or additional discussion, with a separate <note type="refertoElders">.
It turns out that matching against only <seg type="n"> misses most of the matches, because entries that haven't yet been processed don't have type attributes. Thus take 2, which finds 670 matches:
declare default element namespace "http://www.tei-c.org/ns/1.0";
import module namespace util="http://exist-db.org/xquery/util";
for $p in collection('/db/moses/')//TEI[@xml:id='lex-suff']//phr[@type='n'][parent::quote]
let $target := normalize-space(translate($p/text()[1], '+-=√‐', '')),
$matches := collection('/db/moses/')//pron/seg[text() = $target]
return
if (count($matches) gt 0) then
concat('*** ', $p/ancestor::entry/@xml:id, ' (', $target, ') [', $p/text(), '] matches ', collection('/db/moses/')//pron/seg[text() = $target][1]/ancestor::entry/@xml:id)
else
concat(' ', $p/ancestor::entry/@xml:id, ' (', $target, ') [', $p/text(), '] has no matches. ')
This was the code for detecting dupes where dictegs exist in lex-suff which match full entries elsewhere:
declare default element namespace "http://www.tei-c.org/ns/1.0";
import module namespace util="http://exist-db.org/xquery/util";
for $p in collection('/db/moses/')//TEI[@xml:id='lex-suff']//phr[@type='n'][parent::quote]
let $target := translate($p, '+-=√‐', ''),
$matches := collection('/db/moses/')//seg[@type='n'][text() = $target]
return
if (count($matches) gt 0) then
concat('*** ', $p/ancestor::entry/@xml:id, ' (', $target, ') [', $p/text(), '] matches ', collection('/db/moses/')//seg[@type='n'][text() = $target][1]/ancestor::entry/@xml:id)
else
concat(' ', $p/ancestor::entry/@xml:id, ' (', $target, ') [', $p/text(), '] has no matches. ')
From today's meeting:
Some dictegs inside the lex-suff.xml file are basically duplicates of entries in the main entries files, and should therefore be commented out; and conversely, some are not reproduced in the entries files, and should be copied over to full entry status before being commented out. In order to detect this situation, I need to:
This should help us keep track of what's happened if we get an SVN conflict.
I've begun the process of mapping our feature structures onto the GOLD ontology, using the @dcr:datcat and @dcr:valueDatcat attributes in TEI, based on unique identifiers from the ISOCat.org version of GOLD 2010. Here I'll gather together a list of concepts which are difficult to map or for which no obvious terms appear in GOLD; based on this, we'll contact the GOLD maintainers for advice.