We discovered we needed the @subtype attribute on <phr>, and it wasn't available, so I went back to the schema. What I have is a manually-modified RNG file; the original was generated from Roma back before P5 was finally released, and I think Roma was broken at one point, hence the manual modification to the RNG (to allow <bibl> in <entry>). I discover now, though, that there were significant changes to the dictionary markup between the generation of my schema and the release of P5. Specifically, dicteg now no longer exists (<cit> and/or <q> and/or <quote> should be used), and it looks as though @subtype is now available on <phr>. However, if I generate a new schema, all the old data will be invalid because of <dicteg>, so as a temporary measure I've made another manual modification to the old schema to allow @subtype on <phr>, and we're sticking with the old schema until I get the chance to generate a new one, figure out the issues, re-process all the old markup, and rewrite the XSLT. Not a huge task, but an annoying and unexpected addition to the workload.
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>
The Adaptive DB code has reached the stage where it can be used for other projects, so we took on BI's database of historical photos. This is what I did today:
- Got the spreadsheet from Stew.
- Turned each of the support tables into a db table in PhpMyAdmin.
- Saved the sheet for that table as a tab-delimited CSV file.
- Used Transformer 3, with a JavaScript transform item, to turn the CSV file into an SQL query to insert all the data.
- Inserted the data in PhpMyAdmin using the output from Transformer.
- Added relevant indexes and foreign keys.
- Created the requisite definitions and settings in the
local_classes.phpfile to generate an editor interface for all these tables. - Worked through the main table, creating a new "documents" table which will hold the core data.
- Hooked up the foreign keys in the documents table.
Meanwhile, Stew is transforming the documents table data (2200+ rows) into insert statements for the new table. There are two one-to-many relationships, chapters and keywords. Initially, the original comma-separated values for these will be inserted into the mySQL table in temporary fields; we will then write PHP to parse the fields and generate the required records in the related tables. Once that's done, we can delete the original string fields.
Finally, I'll have to create a local_classes definition file for the documents table. It probably deserves its own editing page -- the other page is already heavy with data and takes 8 seconds to load.
There are a couple of CANJAS lectures scheduled while I'm gone, and Dr. Iles will be handling the hardware. He asked me to write up a brief outline of what to do:
Placement.
In the boardroom, the optimal location is at the window end of the room; the curtains are not sufficient to stop glare on the screen.
I generally need to get in to the room a bit ahead of schedule to move the table and chairs around to fit the VC equipment in to the space.
Network.
The boardroom is already sorted out, network wise, and should just work. That said, the network port is at the opposite end of the room from the best location for the VC equipment. There is a long network cable for this (the end of which is sticking out of a blue-grommeted hole in the bottom left side of the cart). I run it under the tables to keep it out of the way.
*** Networking note: If another node is dialing (cascade call from UofA or similar) in you'll need to know your IP address beforehand and give it to the dialer. If you dial out (make your own call to another node) your IP doesn't matter.
Audio.
in the boardroom, you should be able to get away with a single microphone, but if you have a full house you might want to use two. I run the cable (sticking out of the same hole as the network cable) down the middle of the table (on the floor, running it up to the mic's location). Remember that the mic displays a green light when broadcasting and a red one when turned off. They can be manually turned on and off with the switch on each mic, or through the remote mute function.
*** Audio note: the mic cables plug in to the mic only one way. It's a bit like an S-Video cable in that it requires a delicate touch to attach. Take a close look at the cable end and the mic before trying to connect them.
Video.
The VC equipment is plugged in to the S-Video plug on the TV (which displays as "AV1" on the TV screen). Use the "Source" button on the TV remote to adjust the input.
The bigger VC box (on the right) has a power (toggle) switch that should already be on. When you plug in the cart and turn on the power on the VC remote (silver one) the camera should turn around a bit and settle in a forward position (away from the TV). If the TV is on the right input you should see a view of the room on the TV screen.
If the blue Sony IPELA screen is displaying on the TV, you'll notice in the lower middle section of the screen some info about the network connection. It should display an IP address here - if it doesn't, you don't have a connection. Fix this first!
To dial in to a node, use the IPELA remote and choose "Phone Book" in the top right of the main screen. When you click it, you get a new screen with about 6 big, cryptically titled, icons (Sony, Clare@UofA etc.). Look at the bottom left of the screen and you'll see the IP address that will get dialed if you choose one of the icons. (***Remember, if UofA is going to do a cascade call (dials you) you need to know your IP address and make sure the outside caller knows what it is.)
If you need a separate monitor for a Powerpoint presentation, you need to make sure that it's working ahead of time. I normally dial up UofA and ask to do a test to make sure everything is functional.
To connect things, put the small LCD monitor where you want it and connect the VGA extension cable to the one already on the monitor. The extension cable is already attached to the SONY box; you'll find the cable inside the cart.
Out for a couple of hours to go to the accountants for HBS eoy.
Having implemented the similarity metric in C++ under QT, I'm now experimenting with the results I get, and comparing them with the results from the same data using my Java implementation. There are some interesting issues:
- I have noticeable different results between the Java (GZip) implementation and the C++ (zLib) version. Differences are of the order of 0.12 in some cases (12% of the range). This is both intriguing and worrying, although it may not be an issue if the only use of the values is for relative comparisons.
- The order in which the strings are dealt with (when concatenated as part of the calculation algorithm) affects the score, on the order of about 0.02 (2% of the range). This is interesting. Right now, my object calculates scores using both sequences, and averages them out, but it may be more "correct" (whatever that means) to take the larger or the smaller of the values in each case. I'll have to do some thinking about this.
Ewa needs to write the discussion / "disclaimer" re: Kinkade's phonemic transcriptions. See for example ṣə̣́nṣə̣nt, 'tame'.
Here's a summary of the rest of the markup decisions we made last week:
-placeName tags can be added to highlight place names within glosses, e.g.
<seg><gloss><placeName>Corkscrew Grade </placeName></gloss>(next canyon from <gloss><placeName>Jackass Canyon</placeName></gloss>)</seg>
-Each <entry> should generally only have one <hyph>. It is not necessary to have a <hyph> for every <form>, unless a variant form contains one or more additional morphemes (e.g. cahcimn, cahcimn-c).
-For words which were transcribed with an initial "(s-)", the prefixed and non-prefixed variants should be marked up as different forms within the same entry. They will have different <hyph>s.
-Words with ə transcribed in parentheses should have separate segs for transcriptions with and without ə - e.g.,
<seg type="narrow">cx̣cx̣ᵊnᵊwˀálənˀ</seg>
<seg type="narrow">cəx̣cəx̣ᵊnᵊwˀálənˀ</seg>
-Yes, morpheme breakdown should be included in <dicteg>s, but only for the form being exemplified.
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.