allomorphy vs. variant (minor entry) forms
Lynnika Buter
I have a conceptual question which I'd appreciate feedback on from
anyone who understands Flex's hidden workings better than I do.
In our text data (upwards of 20,000 utterances from several different
archival sources), we have both regular allomorphy and variant forms
(minor entries) of lexical items. We have pretty much figured out how
to handle the allomorphy in Flex, and it's handy that in the
interlinear parse we can specify that a form is an allomorph of a main
entry lexical item. However, with variant forms (forms which our best
evidence indicates are atypical pronunciations, errors by documenters,
etc.), the only way to get the item to parse as the relevant main
entry is to go into 'Edit Morph Breaks' and spell it as the main
form. Here are examples of what I'm talking about:
a) verb mehe 'see': mehe-n=ka 'I saw'; but mehee-pu 'see
oneself' (vowel lengthening in open syllables). For mehee forms, we
can tell the parser mehee is an allomorph of mehe
b) hiruhmin vs. iruhmin 'everyone': the h-initial form is the main
form, but iruhmin occasionally crops up as an atypical form (no
principled allomorphy at work). When we parse this, we can't tell
Flex that iruhmin is a variant (minor entry) in our lexical database,
linked to main form hiruhmin. Instead, we have to open the 'Edit
Morph Breaks' box and type in hiruhmin, essentially tricking the
interlinearizer into finding the right item.
I wonder if anyone else has this type of issue, and if so, how you're
handling it. I'd also like to know if there might be future plans for
incorporating something analogous to the 'Allomorph of...' function
for variant pronunciations--? It seems strange that you can link a
minor entry to a main entry in the lexicon, but not in the texts.
Thanks a bunch,
Lynnika
Allan Johnson
> b) hiruhmin vs. iruhmin 'everyone': the h-initial form is the main
> form, but iruhmin occasionally crops up as an atypical form (no
> principled allomorphy at work). When we parse this, we can't tell
> Flex that iruhmin is a variant (minor entry) in our lexical database,
> linked to main form hiruhmin. Instead, we have to open the 'Edit
> Morph Breaks' box and type in hiruhmin, essentially tricking the
> interlinearizer into finding the right item.
>
> I wonder if anyone else has this type of issue, and if so, how you're
> handling it. I'd also like to know if there might be future plans for
> incorporating something analogous to the 'Allomorph of...' function
> for variant pronunciations--? It seems strange that you can link a
> minor entry to a main entry in the lexicon, but not in the texts.
>
Hi Lynnika, thanks for bringing this up. It does seem like there's a
feature that could be added here to make it work more nicely. When a
variant form shows up in the text, you want it to be recognized and
linked to the main form, right? Trying it on my computer, I find that I
can do one of these two things:
-1-
Word iruhmin (variant form)
Morph iruhmin
Lex Ent hiruhmin (main form)
-2-
Word iruhmin (variant form)
Morph hiruhmin
Lex Ent hiruhmin (main form)
Case one requires me to call the variant form an allomorph, as you
mentioned.
Case two - it seems to me too that this is the better choice, so you can
keep variant forms distinct from allomorphs. Once you've encountered
this once in a text and manually specified the morpheme to link to, the
interlinearizer will automatically offer this same analysis in the
future. But looking at the Analyses view I see that even though this is
a user-approved analysis, the parser isn't able to produce it. Even if
the variant is already linked to the main form in the lexicon. The
parser doesn't seem to have any awareness of variant forms in the
lexicon. Would it be feasible to have the parser read this variant form
information from the lexicon and offer analysis 2 the first time,
without any need for manual tweaking?
Allan J.
Lynnika Buter
Yes, you have grasped exactly the issue. We have chosen to go with
option 2 because there *is* principled allomorphy in Mutsun (as in
probably every language), and we don't want to muddy that up with
random variation. For us, it's less an issue of automatic parsing,
since we're not doing that anyway (we had most of the parsing done
before Flex). It just seems strange that there is a way to link
variant & main forms in one part of the system and not in another;
especially when a mechanism exists in the texts to link allomorphs.
It would also be nice, for learners, to have some consistency in what
the Word, Morph, Lex Entry etc. lines represent: currently, for an
allomorph, the Word and Morph lines reflect the surface pronunciation
while the Lex. Entry is the citation form; where for a variant, only
the Word line is the surface form for that utterance, with both the
Morph and Lex. Entry lines containing the citation/main form. I
suppose if I were being really idealistic, it would be nice to have
variant forms appear in purple or something so it's clear this is how
they were recorded on this occasion in the data, but not how we
suspect they were typically pronounced based on the rest of the data
(did I mention Mutsun hasn't been spoken since 1930?)...anyway, it's a
generally confusing situation, and the questions just arose because I
was delighted with the allomorph linking in a recent Flex upgrade and
wondered why we couldn't do the same with variants. It stayed on my
mind because of the trouble my colleague and I had in making sure we
were both dealing with allomorphs and variants properly, and our
uncertainty as to the options.
Thanks for listening! I'm very interested in others' experiences &
opinions on this.
Lynnika
Ronald Moe
"Yes, you have grasped exactly the issue. We have chosen to go with
option 2 because there *is* principled allomorphy in Mutsun (as in
probably every language), and we don't want to muddy that up with
random variation."
I would agree that FLEx needs to handle variants better. I don't know if it
has been mentioned before on this list, but the FLEx developers have known
for quite some time that the system for handling Entry Types and Morph Types
(including variants) has some problems. We even toyed with the idea of
having a mini-conference to sort out the issues. Lynnika has brought up one
that I hadn't thought of. Just to give you an idea of the sorts of problems
we are aware of...
A variant can be of numerous types and these types can be combined. For
instance 'color' is both a dialect variant and a spelling variant of
'colour', even though the default options in FLEx require you to choose one
or the other. Fortunately FLEx allows you to set up custom variant types. So
you could add 'American spelling variant' (or 'British spelling variant') to
the list.
There are actually three kinds of variants and three other things that are
often thought of as variants:
(1) A morphologically or phonologically conditioned variant of a morpheme is
treated as an "allomorph" (e.g. stop/stopp, sweep/swep, -ed/-t) in the
alternate forms section of the entry. But this is only true of allomorphs
that are spelled differently. Allomorphs that are not spelled differently
(e.g. -s [-s/-z] (and -es [-iz]) 'Pl') are frequently ignored in
dictionaries, but should be handled in the pronunciation section.
(2) A phonological variant, which is spelled the same as the basic variant
(e.g. either [idhr/aydhr]), is handled in the pronunciation section by
adding a second pronunciation.
(3) A variant that is spelled differently (e.g. color/colour) is handled by
creating a separate entry and linking it to the basic form. If the spelling
variant is also pronounced differently, you can record the variant
pronunciation in the pronunciation field in either entry or both
entries(!?).
(4) Inflectional variants (run/ran, bring/brought) and suppletion (go/went)
are also handled by creating a separate entry and are similar to variants in
the way they are treated in published dictionaries, but in fact are not
variants at all. A better term is 'irregularly inflected form'. It would be
nice if the interlinearizer could automatically parse 'went' as 'go-Pst' and
then allow the user to pick the correct sense of 'go'. Irregularly inflected
forms are not variants (of a single form) but are combinations of morphemes.
(5) Contractions (e.g. I'm, I'd've, can't) are handled by creating a
separate entry and linking the two constituents to their basic forms.
Contractions can be handled by treating one member as a clitic and treating
any shortened morpheme as an allomorph. Contractions are not variants (of a
single form) but are combinations of lexemes.
(6) Dialect synonyms (e.g. elevator/lift, hood/bonnet, trunk/boot) are
handled by creating separate entries and linking the appropriate senses. For
instance 'elevator' and 'lift' both have multiple meanings in both British
and American English. Most of the meanings are shared by both dialects. Only
the sense 'a machine used to lift people or freight from one floor of a
building to another' is different between the dialects. So we would have to
list this sense under both entries and link the two senses (but not the
entire entries) using the sense level Lexical Relations field. Dialect
synonyms are not variants (of a single form) but are similar to them.
Some linguists might use the term 'variant' for all six of these. I would
prefer to reserve 'variant' to refer to alternate *forms* of a linguistic
form (morpheme or lexeme). But the issue is complex and I don't want to be
dogmatic on the point. In particular the term 'allomorph' is the standard
term for a spelling or pronunciation variant of a morpheme that is
phonologically or morphologically conditioned. As an example of the
complexity of this area, note that 'cain't' is a dialectal spelling and
pronunciation variant of a contraction.
The real problem that Lynnika has raised is that 'variants' are issues with
linguistic forms and combinations of forms. In each case the form can have
multiple meanings. So we have to have a way to handle the difference between
form and meaning. I don't want to have to set up separate entries for
'color' and 'colour' and list all the meanings twice. So FLEx needs a way to
deal with the difference in form and yet refer to a single list of meanings,
which the user would maintain in a single place, presumably under the basic
form. The parser should be smart enough to link the forms, which are kept in
two different places, and yet look in one place for the meanings.
Ron Moe
Hi Allan,
Lynnika
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1376 - Release Date: 4/13/2008
1:45 PM
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1376 - Release Date: 4/13/2008
1:45 PM
Alexandre Arkhipov
'irregularly inflected forms'. We've got lots of these in our languages, and
it would be nice to be able to have a different gloss (like "go-Pst") but
linked to the same lexical entry.
Alexandre
=============================
...
Beth B
> However, with variant forms (forms which our best
> evidence indicates are atypical pronunciations, errors by documenters,
> etc.), the only way to get the item to parse as the relevant main
> entry is to go into 'Edit Morph Breaks' and spell it as the main
> form.
Lynnika, does it make any difference if your variant form has a sense
or not? I think even an empty sense might make a difference, but I
haven't tested this.
This is an excerpt from an exchange I had with Susanna a while back.
I think she *intended* for variant forms to be linked; it just didn't
get implemented that way.
-Beth
On Feb 8, 2008, at 11:23 AM, Susann...@sil.org wrote:
> I have found recently a problem with the current approach because
> if a user does not have a sense for a variant form, then the
> variant form cannot be referenced in interlinear text.
Ronald Moe
" Lynnika, does it make any difference if your variant form has a sense
or not?"
It bothers me that FLEx creates entries without a sense, especially when the
lack of a sense causes features to malfunction. Today Susanna commented on a
problem when an entry had no Morph Type specified. Again, why does the
program do this when it causes features to malfunction? It seems to me that
each entry should have all basic elements automatically created and all
default values filled in, no matter how the entry was created. (On the other
hand, as soon as the programmers get a feature working right, some
"creative" user does something unusual, like importing a database with no
lexeme forms! --something I've contemplated doing myself.)
Ron Moe
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1377 - Release Date: 4/14/2008
9:26 AM
John_T...@sil.org
> It bothers me that FLEx creates entries without a sense, especially when
the
> lack of a sense causes features to malfunction. Today Susanna commented
on a
> problem when an entry had no Morph Type specified. Again, why does the
> program do this when it causes features to malfunction?
It does it because programmers are human, and hence, not infallible :-)
It's definitely a bug one way or the other...either the program should work
on entries with no senses, or it should always create a sense with an entry
(and never let you delete or move or drag or cut all of them), or it should
automatically create a sense when it is first asked for.
We took the approach of trying to make it impossible to have an entry with
no senses, but importing lexemes without senses was one way to do it that
we didn't think of.
JohnT
Ronald Moe
"It does it because programmers are human, and hence, not infallible :-)"
Nonsense. After observing the superb achievements of the FW programmers, I
am convinced that you are a superior race of beings. It is us users who with
devilish delight wreak havoc upon your well-crafted and finely tuned
program. Can you be expected to predict that some crazy user could conceive
of a dictionary with no senses or one with no lexemes? Unheard of!
Unthinkable!
Kudos to the programmers!
Ron Moe
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On
Behalf Of John_T...@sil.org
Sent: Tuesday, April 15, 2008 2:54 PM
To: flex...@googlegroups.com
Subject: [FLEx] Re: allomorphy vs. variant (minor entry) forms
JohnT
No virus found in this incoming message.
Beth B
> It bothers me that FLEx creates entries without a sense,
Here's more from Susanna's note:
On Feb 8, 2008, at 11:23 AM, Susann...@sil.org wrote:
> Normal entries should have senses, and they are added as you make
> entries in FLEx. You cannot normally delete the only sense in an
> entry. However, variant form entries are allowed to have no sense--
> FLEx allows you to delete the only sense from them. This is because
> often a variant form has exactly the same meaning as the form it
> varies from (e.g. colour and color) or the meaning change is
> adequately captured in the entry type and condition e.g. past tense
> inflectional variant. The summary definition of the linked primary
> entry can be used & displayed used to summarize the meaning.
> If an entry that was a variant form, and had no sense, is changed
> to be a main entry or complex form (in the entry type field) then
> FieldWorks does not add an empty sense automatically. At the
> moment, the user needs to use Insert Sense
That all seems reasonable to me (except the last part sounds like
something that could be changed). To me the bug seems to be that
these variants aren't recognized in the interlinear, even without a
sense, not that they are allowed not to have a sense.
But from the other things Susanna wrote, it's clear that's what she
had *hoped* it would be doing. It's just impossible to think through
all the corner cases. Frankly, the FW team has thought through an
*amazing* number of corner cases. It's amazing to me all the things
that FLEx *does*, and how many fewer things there are in 5.2 where I
find myself saying, "Gee, I wish it would ...." FLEx is shaping up
to be a very nice program.
I still haven't had a chance to actually test whether adding a sense
to a variant entry (that doesn't otherwise need one) actually makes
it available in the interlinear, the same way an allomorph would be.
I guess no one else has either?
-Beth
Allan Johnson
> I still haven't had a chance to actually test whether adding a sense
> to a variant entry (that doesn't otherwise need one) actually makes
> it available in the interlinear, the same way an allomorph would be.
> I guess no one else has either?
>
> -Beth
>
I tried it. I haven't actually encountered any cases of entries without
senses. The variant forms I had created for Lynnika's examples had a
"Sense 1" showing, but just with no content - no gloss, no part of
speech, etc. So I redid the test, adding a gloss and part of speech to
the variant form just to be sure that the sense could be recognized as a
sense. The results were the same both ways - the interlinearizer didn't
seem to be aware of the link from the variant form to its main entry.
A different but related topic - The only way I know to create a variant
form is to insert a new entry, change its Entry Type from "Main Entry"
to whichever kind of variant suits it, then fill in the "Primary Entry
References" field to point back to the original entry that it's a
variant of. This must be why I haven't seen any entries without senses -
because my variants are initially created as Main Entries. But I would
love to have a more straightforward way of inserting variants. What am I
missing? How are you guys doing it? I've clicked and right-clicked
everywhere I can think of around the "Variant Forms" field, and I've
never found any way to add a variant form from there. The way I'm
envisioning that it -could- work is just like the insertion of a synonym
or antonym. Right click on the field, choose what kind of variant you
want, FLEx then takes you through the dialog boxes needed to accomplish
the insertion of a new entry if it doesn't yet exist, and then returns
you to the main entry with the desired variant form inserted and linked.
An analogous process should also be possible for the insertion of
complex forms. For that field too, I haven't found any way to add
content apart from first manually creating a separate entry for the
derivation or other complex form, and then linking back to the original
entry.
Now thinking back to the case that Lynnika brought up - what would FLEx
have to do in order to accomplish what she's asking? In terms of what
has to be done manually to accomplish it - FLEx finds a match in the
lexicon for a wordform in the text, notes that this matching form is
marked as a variant, so it takes the "Primary Entry Reference" field,
using the content of that field to fill in the morpheme line for that
word in the text. It would offer that as one morpheme option anyway.
From there the interlinearization would proceed in the usual way.
I wonder if it might be useful to do a similar thing with complex forms.
FLEx finds a match in the lexicon for a wordform in the text, notes that
the matching form is marked as a complex form, so again it takes the
content of the associated "Primary Entry Reference" field to fill in the
morpheme line for that word in the text. This wouldn't be useful for
every type of complex form. But if the complex form is a derivation for
which the root and affixes have all been specified in the "Primary Entry
Reference" field, then it would be nice to enable the interlinearizer to
read and use this information just as we've proposed for variant forms.
For both complex and variant forms, it would probably be good to provide
some kind of check-box to say "yes, let the parser use this" or "no,
don't let the parser use this"
Allan
Andreas_Joswig
> Can you be expected to predict that some crazy user could conceive
> of a dictionary with no senses or one with no lexemes? Unheard of!
> Unthinkable!
>
Here's my scenario: For a phonology workshop I need a wordlist with tons
of phonetic data. Actually, I need to use Keith Snider's and Jim
Robert's 1700 word list for African purposes. Because I need to work
with that language later on my thought was to use FLEx and make this
data the stock for my dictionary that eventually needs to be built up.
More precisely, I already had started a FLEx database on that language
with a small number of non-phonetic language data, and I wanted to
incorporate the wordlist into that. Of course I did not want to mix up
the phonemic data (which I use for parsing) with the fresh phonetic
data, so I really need to have this in the pronounciation field. When I
imported that wordlist, I quickly noticed that FLEx did not like me to
import a database which does not add anything to the FLEx Lexeme field.
The way FLEx communicated this to me was by displaying lots of
questionmarks in many places, and importing the data into wrong records,
etc. But in fact for this wordlist data I had nothing to fill into the
Lexeme field to begin with. I think many similar scenarios can be
envisioned where a user might want to import some set of data (maybe
even just an empty list containing only references and senses to begin
the collection of structured data). I would like FLEx to be able to
allow me to have the lexeme field empty at least for a short time.
I solved my problem by combining it with another shortcoming of FLEx: It
does not provide a field for a reference for a dictionary entry. I
understand that this is not at all needed when you parse and build up
your regular dictionary. But I wanted to use FLEx for a slightly
different purpose for now, as a database which contains the data for my
phonological analysis (to be used by Phonology Assistant). For this
purpose it is very useful to have a reference, and I would have liked to
use the Snider/Roberts word list number for this. Since FLEx does not
provide such a reference field, I just imported the reference number
into the lexeme field (I bulk-copied this into another custom field
right away). So this simple four-digit number will remain in my lexeme
field until I have more useful information to put there (which depends
on my eventual analysis of the data stored in the pronounciation field).
All in all, the FLEx developers should keep in mind that FLEx is
tremendously useful, even for those purposes for which it is originally
not designed. To accomodate these slightly 'off' uses by 'some crazy
user' like me, a little more flexibility would sometimes be appreciated.
Of course I understand that adding flexibility also adds to the
potential for users to mess up everything, so you will want to balance
this. But it appears that the upcoming version of Phonology Assistant
intends to use FLEx databases in the way I outlined above, and it would
be nice if these two programs would cooperate well.
Another idea along these same lines: I sometimes wonder whether the
pronounciation field should only be provided for the lexicon. For my
current purpose I would have preferred to have imported my wordlist as
words (in phonetic transcription) and attach sound recordings to them,
totally separated from the lexicon. But the current location of
pronounciation information in the lexicon only forces me to put things
there.
Andreas Joswig
Ronald Moe
Is there an easy way to add a sense to each entry that currently does not
have one? Several of us find ourselves in this position. Some of us have a
thousand entries like this and it would take forever to manually add a sense
to each one. Is there an easy fix?
Ron Moe
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On
Behalf Of John_T...@sil.org
Sent: Tuesday, April 15, 2008 2:54 PM
To: flex...@googlegroups.com
Subject: [FLEx] Re: allomorphy vs. variant (minor entry) forms
JohnT
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.22.13/1377 - Release Date: 4/14/2008
9:26 AM
No virus found in this outgoing message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.23.0/1379 - Release Date: 4/15/2008
6:10 PM
jlarmagost
Given the stipulation in your first paragraph I shouldn't be responding, as
I'm pretty much a beginner, but I've been typing Boas' 1894 Chinook Texts
into FLEx and have run into several instances of one of your issues.
For example, what to do with a form that *has* to be tcxa but appears once
each as
txa and toxa? The former is perhaps a speaker's error but more likely a
mis-hearing on Boas' part or a typesetter's error; I'd think toxa has to be
a typesetter's error. In interlinearizing, I correct the deviant baseline
forms in square brackets as
t[c]xa.
I possibly haven't thought this policy through to negative
consequences lurking in the shadows, but for now at least it doesn't bother
me that t[c]xa gets
added as a bogus "allomorph" of tcxa.
Jim
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com]On
Behalf Of Lynnika Buter
Sent: Friday, April 11, 2008 9:22 AM
To: FLEx list
Marlin_...@gial.edu
I want to create a semi-automatic way to assign domains so I can do semantic sorts until the "automatic" way gets implemented. I have been thinking of importing the DDP semantic domain list along with the English examples as a gloss.
But I was wondering how to enter the lexeme? I thought of leaving it blank but that's obviously not the way to go. I could put a dot but then I'd have umpteen hundred homonyms. From looking at your solution I could assign a numerical or semantic label code as the lexeme for each domain-gloss combination. I guess I could make the numeric semantic code as the lexeme, but I was hoping to limit the size of the file. It seems a shame to have the semantic domains there in the categorized entry and not be able to use it to quickly assign them in a bulk edit way to already entered data. The LinguaLinks auto-assign tool was so useful for the Thesaurus and OCM code fields.
Setting this up would allow me to sort on the gloss in Bulk Edit Senses. I would then scan down the glosses for identical or similar ones and tick their boxes to assign the appropriate semantic domain from list choice. As new words are added I could repeat the semi-automatic process.
For semantic study I'd actually like to have the Semantic Domains to be listed in 2 separate columns so I could do a sort on the numeric outline code, or an alphabetic sort on the label (to get an idea of what's in the list. I do this in a Word file now, but I can't link to the FLEx).
Marlin
Ronald Moe
>Ronald Moe wrote:
>> Can you be expected to predict that some crazy user could conceive
>> of a dictionary with no senses or one with no lexemes? Unheard of!
>> Unthinkable!
>>
>Well, I did, or at least I tried to have my dictionary without lexemes.
Andreas,
I hope you know that my original message was intended to be humorous. I
should have put in several smiley faces :) Most of us are "crazy" :) in
that we do unusual things with our dictionaries. Your idea of importing a
wordlist for use in phonological analysis is interesting and raises some
problems. Such a wordlist might include inflected forms that would not be
suitable as lexeme forms or citation forms. The pronunciation field was
intended to indicate the pronunciation of the headword in a published
dictionary, not as a place to store phonetic transcriptions of inflected
forms. If the Phonology Assistant in FieldWorks is going to use the lexicon
as a source of phonetic data, then we need an additional field for phonetic
(and/or phonemic) transcriptions of inflected forms, or we need a separate
database for such things. However I would prefer to keep such data in the
lexicon where we can use the Bulk Edit tools together with the grammatical
information fields to generate forms or look for patterns. It would be
necessary to be able to attach sound files to these paradigm forms.
You also raised another issue that others have brought up. Many of us use
standardized wordlists in our work and it would be nice if there was a place
to record the number and/or reference to the wordlist. This would be
especially important if someone wanted to search many dictionaries for
comparative purposes. I'm not sure how we would standardize such references.
At least you can use a custom field. There is no reason why we can't use
custom fields for "slightly off" purposes. It is only when we want to use
FLEx to maintain our address list (like I do with Toolbox) or some other
very different purpose that we run into problems.
Ron Moe
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On
Andreas Joswig
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.23.0/1379 - Release Date: 4/15/2008
6:10 PM
No virus found in this outgoing message.
Checked by AVG.
Ronald Moe
Marlin Leaders wrote:
“For semantic study I'd actually like to have the Semantic Domains to be listed in 2 separate columns so I could do a sort on the numeric outline code, or an alphabetic sort on the label (to get an idea of what's in the list. I do this in a Word file now, but I can't link to the FLEx).”
I maintain the DDP list of domains in Toolbox. There I set up separate views so that I can sort on the domain number (\is), domain label (\sd), and example words (\ex). Would it be helpful if FLEx offered these views of the list of domains? In the meantime I can only suggest doing what Marlin is doing—maintain these views in another application such as Word or Toolbox.
Mark Penny has also developed a semi-automatic way to assign a semantic domain to a vernacular word on the basis of the gloss. But you have to do this prior to import to FLEx.
Ron Moe
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On Behalf Of Marlin_...@gial.edu
Sent: Wednesday, April 16, 2008
12:59 PM
To: flex...@googlegroups.com
</tt
No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.23.0/1379 - Release Date: 4/15/2008 6:10
PM
Andreas_Joswig
hope that I did not sound offended in my last message.
I agree with your assessment that the lexicon is not the ideal place to
store such a wordlist. That's why I suggested to attach pronounciation
information to wordlist data elsewhere in the program. However, such a
standardized wordlist mostly includes citation forms, so as such the
fall-out is not too serious when I use the lexicon, at least in my case.
It looks like it would be good if the various SIL software efforts let
each other know what they are doing, so that this kind of conceptional
problem can be avoided in the future.
Andreas
Allan Johnson
> If the Phonology Assistant in FieldWorks is going to use the lexicon
> as a source of phonetic data, then we need an additional field for phonetic
> (and/or phonemic) transcriptions of inflected forms, or we need a separate
> database for such things. However I would prefer to keep such data in the
> lexicon where we can use the Bulk Edit tools together with the grammatical
> information fields to generate forms or look for patterns. It would be
> necessary to be able to attach sound files to these paradigm forms.
>
I like the idea of recording the pronunciations of wordforms rather than
just pronunciations of headwords. The wordforms are the raw data that we
actually hear, so getting the pronunciations should be straightforward.
Pronunciation for a lexeme is sometimes a more abstract thing, in those
cases where a lexeme actually doesn't stand on its own without
affixation in natural speech.
If we want to record the pronunciations of wordforms, a natural place
would be in the "Words" area. All wordforms from texts automatically go
into that list, so it's a good place for accumulating raw data that we
may not actually want to print as part of the dictionary in the end.
There are currently only 7 fields available in the Words area, and not
yet any way to create custom fields there. I guess some enhancements I'd
suggest would be -
1) Allow custom fields in the "Words" area
2) Add a pronunciation field in the "Words" area
3) Add the capability of attaching a sound file to a word or
pronunciation in the "Words" area
4) In the Lexicon create a way to view all wordforms and/or
pronunciations that have been linked to that lexeme by analyses of the
wordforms
As I think more about it, it occurs to me that even on the wordforms the
marking of pronunciations can sometimes be artificial. The pronunciation
of a given word can vary depending on its context, so the rawest of the
raw pronunciation data would really be associated with individual words
in a text that has been recorded and transcribed. What I'm thinking now
is probably beyond the scope of anything we can implement soon, but just
to dream a little about the process of collecting pronunciation data:
- Do an audio recording of a text
- Transcribe it into the text area of FLEx
- Listen again to the audio and somehow with a mouse click or something,
associate each written word with the point in the audio where it occurs.
- Go to the list of Wordforms and sort it in a useful way, perhaps by
the number of occurrences.
- Starting with the most frequent word, click a button that allows me to
listen to all of its occurrences one after the other.
- If the pronunciation is consistent, record it in the word
pronunciation field
- Choose one audio recording which represents the pronunciation well,
and select this to be linked to the word pronunciation
- If there are alternate pronunciations, enter each alternative into the
pronunciation field, and choose an audio recording to represent each
variant pronunciation that I've entered. Let the multiple pronunciations
remind me later that I need to return to the texts and study this form,
to figure out what in the context is influencing the pronunciation, and
to decide which pronunciation to view as the most basic.
- When I've recorded pronunciations for all the wordforms, then I'm
ready to look at the lexeme level
- Go to the lexicon and for the first lexeme, view a list of all
wordforms which use that lexeme
- Click a button that allows me to listen to the pronunciation of each
wordform which uses that lexeme
- If possible, determine a basic pronunciation for the lexeme itself,
and enter this into the lexeme pronunciation field
- Choose the audio recording of one wordform which best represents the
pronunciation of the lexeme, and select this to be linked to the lexeme
pronunciation.
Allan
Heidi James Rosendall
> wordlist for use in phonological analysis is interesting and raises some
> problems. Such a wordlist might include inflected forms that would not be
> suitable as lexeme forms or citation forms. The pronunciation field was
> intended to indicate the pronunciation of the headword in a published
> dictionary, not as a place to store phonetic transcriptions of inflected
> forms. If the Phonology Assistant in FieldWorks is going to use the
lexicon
> as a source of phonetic data, then we need an additional field for
phonetic
> (and/or phonemic) transcriptions of inflected forms, or we need a separate
> database for such things
I don't believe we need or want an additional field. That will only add to
the complexity of the process. Of course inflected words should not be in
the lexicon, but they will be at the beginning of the process for even the
most educated team and that should be OK. (There may be another Ken Pike out
there who can discover the complete phonological and grammatical system
monolingually in an hour, but they aren't the ones who most need these
tools.) See the process we use below.
> I agree with your assessment that the lexicon is not the ideal place to
> store such a wordlist.
Yes it is the ideal place for a beginning project. Nowhere else will work
for us.
> That's why I suggested to attach pronunciation information to wordlist
data elsewhere in the program.
That is GREAT - for later on when we cleanup...
In response to the above comments and the request to keep people informed of
what they are doing, this is how we are beginning to do things...
1. Set up THREE writing systems, phonetic, orthographic, and phonemic (this
is advised in the helps by the way)
2. Make the phonetic writing system the default.
3. Collect words phonetically through the categorized entry tool (By the
way, I still want an easier way to give them the Trade Language words in
this tool, plus, if we could put our standardized wordlists in here too, it
would be really great. We love the easy data entry here and everyone has to
collect these words anyway.)
4. Access the words through Phonology Assistant and discover the rules for
writing them phonemically.
5. A step I haven't figured out how to do yet - maybe it is there already
but if it isn't, I want it. Right now this step is still manual and messy.
Use standard phonology rules in the Bulk Edit tool (the natural place for it
would be in the Process tab, I think) to change the words to their phonemic
form and drop them in the lexeme field in the phonemic AND orthographic
writing systems.
6. Change the default writing system to the orthographic and begin
grammatical analysis including interlinearizing if the team is up to it.
7. As the orthography develops, change the lexeme spelling in the
orthographic writing system only.
8. Cleanup when you wish, move the phonetic lexeme forms to the
pronunciation field, removing the completely predictable ones altogether if
wished. When orthography is fully settled, you can also remove the phonemic
lexeme forms, though it would be nice to preserve the data somehow. Your
"the lexicon is not the place to store inflected forms" comment only can be
relevant much farther along in the process when (IF!) they discover which
forms are inflected and which are not. We have a wide range of education in
those doing work here, and many will never move beyond working in a
simplified view of the Lexicon tab. (I wish I could hide the other tabs, is
there a way?) Still, I believe FieldWorks will be much more accessible and
useful to them than Toolbox and LinguaLinks were.
No one has gone through this process from beginning to end. But they are all
in various stages of their program and I drop them into this framework where
they fit. They are coming from ToolBox and FindPhone (YES! FindPhone - a
logical place, by the way for someone to try to import data without a \lx or
a sense) and a Microsoft Word Survey wordlist. I won't be surprised if I am
asked to import from WordSurv. Is it possible?
Anyway, if there is a terribly wrong step here that will cause future
problems, let me know, but the change absolutely has to be simple and easy
to understand, teach and do. I am about to move Fieldworks Language Explorer
out of experimental in our entity and introduce it to all my teams. (I.e.,
instead of offering it only to those I know are up for a challenge, I am
adding it to the curriculum as the only path to follow). I don't add a lot
to these discussions because mostly people are discussing very high level
problems my folks will never deal with. But please don't forget my
translators whose formal education is much lower but whose commitment and
heart for the work is higher than my own. I don't think you will, but now is
the time to tell me.
Heidi Rosendall
Language Applications Software Consultant
Wycliffe Nigeria
Heidi_R...@wycliffe.org
Skype:heidi.james.rosendall
Marlin_...@gial.edu
Ron Moe on flex...@googlegroups.com wrote on 04/16/2008 03:35:32 PM:
> I maintain the DDP list of domains in Toolbox. There I set up
> separate views so that I can sort on the domain number (\is), domain
> label (\sd), and example words (\ex). Would it be helpful if FLEx
> offered these views of the list of domains?
Marlin
Craig Farrow
16/04/2008 12:05 p.m. dï, Allan Johnson pišdimiš:
> A different but related topic - The only way I know to create a variant
> form is to insert a new entry, change its Entry Type from "Main Entry"
> to whichever kind of variant suits it, then fill in the "Primary Entry
> References" field to point back to the original entry that it's a
> variant of. This must be why I haven't seen any entries without senses -
> because my variants are initially created as Main Entries. But I would
> love to have a more straightforward way of inserting variants. What am I
> missing? How are you guys doing it? I've clicked and right-clicked
> everywhere I can think of around the "Variant Forms" field, and I've
> never found any way to add a variant form from there. The way I'm
> envisioning that it -could- work is just like the insertion of a synonym
> or antonym. Right click on the field, choose what kind of variant you
> want, FLEx then takes you through the dialog boxes needed to accomplish
> the insertion of a new entry if it doesn't yet exist, and then returns
> you to the main entry with the desired variant form inserted and linked.
>
I've been puzzling over what to do with variant forms vs allomorphs too
(thanks to those who have helped clarify these in this discussion.) I
just hit another one while interlinearising today and it occurred to me
that the natural way to enter the variant would be to have another entry
in the Lex. Gloss dropdown, namely "Variant of..." to parallel
"Allomorph of...". This would open a dialogue similar to the Create
Allomorph one allowing the user to find the main entry and then it would
create the appropriate new entry and link it as a variant to the Main entry.
Craig.
>
Craig Farrow
17/04/2008 3:41 p.m. dï, Heidi James Rosendall wrote:
>
> 5. A step I haven't figured out how to do yet - maybe it is there already
> but if it isn't, I want it. Right now this step is still manual and messy.
> Use standard phonology rules in the Bulk Edit tool (the natural place for it
> would be in the Process tab, I think) to change the words to their phonemic
> form and drop them in the lexeme field in the phonemic AND orthographic
> writing systems.
>
>
Right, in the Process tab you can choose an SIL Converters transducer to
do your mapping from phonetic to phonemic/orthographic. To set up your
own converter you can write a TECKit map or CC table and install it with
SIL Converters. If that sounds a bit scary for your users then I found a
nice way of making a CC table for simple phonetic -> phonemic mappings,
and that is to use the SIL Converters SpellFixer Word template. There
might be some things that this won't handle, but if the mapping is
straight-forward then it might be more comfortable for some people:
1. Create a Word document with the mappings. Make sure that longer
patterns are entered first e.g.
tʃ ch
ʃ sh
ɣ gh
ʁ gh
χ h
x h
2. In Tools | Templates and Addins turn on SpellFixer.dot
3. One row at a time highlight the text to be changed (the IPA) and
click Add Correction in the SpellFixer toolbar and then type in the
phonemic/orthographic.
I hope that is helpful,
Craig.
Allan Johnson
> In response to the above comments and the request to keep people informed of
> what they are doing, this is how we are beginning to do things...
>
> 1. Set up THREE writing systems, phonetic, orthographic, and phonemic (this
> is advised in the helps by the way)
>
> 2. Make the phonetic writing system the default.
>
Hi Heidi,
This outline looks good to me. It's quite a bit like the plan we've been
following at a training program here. At one point we were pretty
ambitious with the writing systems, even trying to do interlinear texts
with phonetic, phonemic, and orthographic writing systems all in the
same text. That got us into some messes at the time because FLEx wasn't
quite ready for it. But I've heard that FLEx has been fixed up to handle
that better now.
> 3. Collect words phonetically through the categorized entry tool (By the
> way, I still want an easier way to give them the Trade Language words in
> this tool, plus, if we could put our standardized wordlists in here too, it
> would be really great. We love the easy data entry here and everyone has to
> collect these words anyway.)
>
We chose to use the interlinearizer for our initial entry of word lists.
It works nicely even for a numbered word list. If you just put a number
followed by the word on each line, the interlinearizer isn't bothered by
the number. It ignores it just like punctuation. Maybe this would be the
thing to try for your standardized wordlists. If there's more than one
wordlist, each one could be entered as a separate "text", with some sort
of meaningful titles to distinguish them. I guess the trade language
words could be handled as interlinear glosses of the vernacular. I think
you could have both English and the trade language for glosses if you've
set up the projects with both of them as analysis writing systems. And
you can hide any extra interlinear lines that you won't actually be needing.
> 4. Access the words through Phonology Assistant and discover the rules for
> writing them phonemically.
>
> 5. A step I haven't figured out how to do yet - maybe it is there already
> but if it isn't, I want it. Right now this step is still manual and messy.
> Use standard phonology rules in the Bulk Edit tool (the natural place for it
> would be in the Process tab, I think) to change the words to their phonemic
> form and drop them in the lexeme field in the phonemic AND orthographic
> writing systems.
>
Yes, this sounds good. I don't think we have any place in PA or FLEx
where we can get it to use Phonology rules to map phonetic to phonemic.
It should be possible. LinguaLinks had such a capability. But then, with
LinguaLinks the phonology tool was part of the same package. I think
that's what makes the difference. PA reads and analyzes the data but
depends on FLEx to edit it. So you're right. The rules would probably
need to be applied in a bulk edit process.
In our class we did our phonetic to phonemic adjustments by bulk edit -
manually, one change at a time. Probably the same way you're currently
doing it. The students didn't seem to mind too much. Sort of like a
search and replace in Word, which they seemed to be fairly familiar
with. As for the orthographic... Most of the students sort of skipped
that step and opted for a phonemic orthography. Maybe because of the
shortage of time. Also I think because it seemed kind of artificial to
them. They had learned in another class that a proper orthography is
developed through interaction with the community - and they didn't
exactly have a community available for the languages they were working on.
> 6. Change the default writing system to the orthographic and begin
> grammatical analysis including interlinearizing if the team is up to it.
>
> 7. As the orthography develops, change the lexeme spelling in the
> orthographic writing system only.
>
> 8. Cleanup when you wish, move the phonetic lexeme forms to the
> pronunciation field, removing the completely predictable ones altogether if
> wished. When orthography is fully settled, you can also remove the phonemic
> lexeme forms, though it would be nice to preserve the data somehow.
For Phonology Assistant we did the same thing you're doing - keeping the
data first in the Lexeme field and then moving it at a later date to the
Pronunciation field. I guess that has been driven by the design of
Phonology Assistant, since those are the only two places it offers to
look for your FLEx data. Then we were able to set up two separate PA
projects - one to analyze the original phonetic data in the
pronunciation field, and another to analyze the phonemic data in the IPA
Lexeme field. So it was possible to start displaying phoneme charts, and
still have access to the original phone charts for comparison. I think
the original plan for orthography, if the students had followed through
with that stage, was to have that in the regular vernacular writing
system of the Lexeme field. They would still keep the phonemic form in
the IPA writing system of the Lexeme field. And the phonetic in the
(IPA) pronunciation field.
Anyway, this is my bit of input on how people have been using FLEx in
connection with Phonology Assistant.
Allan
Beth B
> Beth B wrote:
>> I still haven't had a chance to actually test whether adding a sense
>> to a variant entry (that doesn't otherwise need one) actually makes
>> it available in the interlinear, the same way an allomorph would be.
>> I guess no one else has either?
>>
>> -Beth
>
> I tried it. I haven't actually encountered any cases of entries
> without
> senses. The variant forms I had created for Lynnika's examples had a
> "Sense 1" showing, but just with no content - no gloss, no part of
> speech, etc. So I redid the test, adding a gloss and part of speech to
> the variant form just to be sure that the sense could be recognized
> as a
> sense. The results were the same both ways - the interlinearizer
> didn't
> seem to be aware of the link from the variant form to its main entry.
Okay, I finally tested this myself--sorry for slowness.
If the variant entry has no sense (as it would if it got imported
that way--in order to get that state for one you created in FLEx, you
have to delete the sense), then in the interlinear it looks like even
the variant entry is not available, except that the pulldown does
allow the extra option "Add new sense". So somehow it's aware that
there *is* an entry for that form, but it doesn't have a sense to
link it to, but it allows you to create that first sense. I guess
that's what Susanna meant by "entries without senses are not
available in Texts".
Then once I added a sense to that entry, now when I try to analyze
that word in the interlinear, the pulldown menu shows me that variant
entry, with the sense that I added.
But in neither case is it actually linking to the main entry, as it
really should be doing, for at least some of the minor entry types.
Sorry for the false hope, and for posting a "hypothetical" message,
without testing it myself first.
On Apr 18, 2008, at 2:16 AM, Craig Farrow wrote:
> it occurred to me
> that the natural way to enter the variant would be to have another
> entry
> in the Lex. Gloss dropdown, namely "Variant of..." to parallel
> "Allomorph of...".
Actually, since the section that includes the allomorph is actually
called "Alternate Forms", not "Allomorphs", then it seemed to me that
one ought to be able to have a variety of kinds of alternate forms
there, including allomorphs, inflectional variants, dialect variants,
etc., with a way to specify which variant was which kind, and also a
place for comments about each variant.
But yes, I agree with Craig, that one ought to be able to create one
of those in the same way you can create an "Allomorph of..." from the
interlinear.
-Beth
Ron Lockwood
What I was envisioning was something that would change the background color of the entry displayed in the Browse view. Having a few different color options would be great. Maybe the highlighting colors available in MS Word would be sufficient.
As far as how to get the highlighting set, I was thinking I would right-click on the row in the browse mode and select a highlighting color.
Does anyone else think this would be a useful feature?
Ron L
Robert Hedinger
Robert
Ronald Moe
instead of having to search for a color. If you could set multiple
bookmarks, you could mark several entries that need work.
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On
Version: 8.0.175 / Virus Database: 270.9.6/1797 - Release Date: 11/18/2008
11:23 AM
Marlin_...@gial.edu
As an interim step, couldn't we set up a custom field called Bookmark, or Color, or Needs Work? That could be filtered or sorted, so we could put some or code clue in there reminding us what needs to be done.
Marlin
Ronald Moe
We already have an entry level note field that I use for this purpose.
Ron
<br
John Roberts
anyone else having the same problem?
John Roberts
Michael Boutin
Michael Boutin
From: "John Roberts" <dr_john...@sil.org>
To: <flex...@googlegroups.com>
Jung-hoon Lee
Jung-hoon Lee
-----Original Message-----
From: flex...@googlegroups.com [mailto:flex...@googlegroups.com] On Behalf Of Michael Boutin
Sent: Tuesday, November 18, 2008 3:24 PM
To: flex...@googlegroups.com
Eric & Susanne Johnson
Jonathan
Craig Farrow
The concept in Thunderbird of Tags with associated colour highlighting
might work quite well. As long as you can search/filter on the Tag.
For more flexibility, and as another way to work with TODO items you
could copy the hyperlink (Edit menu) and paste into a text/Word file
(with extra notes/categorising, etc.). In Word make a Hyperlink
(Ctrl-K), or from Notepad copy and paste the link into the Windows Run
command (shortcut WindowsKey-R) to jump to that entry.
Craig.
David Coward
I have to agree with Marlin here. In Outlook 2007 they provide a “Categories” column which can be marked with colors. They have a nice implementation and billions of dollars to do it with. Using a custom field or even use the Status field, and add new categories to that list (“needs work” “bad definition”, etc.) Show this field in browse view, sort on it, and there are all your “needs work” entries grouped together. Not as pretty (or eye catching when scanning through document view) as the color scheme, but it works, right now.
David
<br
Robert Hedinger
----- Original Message -----
From: "John Roberts" <dr_john...@sil.org>
To: <flex...@googlegroups.com>
Subject: [FLEx] spammed
>
> anyone else having the same problem?
>
> John Roberts
>
>
>
> >
Language_Su...@sil.org
I've passed on the report that Jarmail is labeling as Spam messages from this group.
Another thing that could prevent this from affecting us is if we each add "flex...@googlegroups.com" to our list of trusted senders.
Steve White, International Computer Support - JAARS
Language_Su...@sil.org
704 843-6337, 1-800-215-7813
Skype: JAARS-1, JAARS-2, JAARS-3, JAARS-4 extension 6337
Ron Lockwood
Thanks for all the suggestions on how to make it work now.
For the future, though, I think a background color would really be helpful. It could be as simple as having one highlight color that you turn on or off for a record. It would catch your eye so that you know there’s something up with that record. If you want a more elaborate system of tags for what needs to be changed you could have that in a field.
One problem with having that information in a field, is that I have to remember what the code was and which field it is in. I would like a quick and easy way to mark a record visually.
Ron
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.175 / Virus Database: 270.9.2/1784 - Release Date: 18.11.2008 11:23
