Closed ocrasborn closed 4 years ago
Here's what this looks like. At present, this is generated dynamically and is quite slow. @ocrasborn should this become pre-calculated information in the database?
I revised the code to comply with one undefined field and the rest matching. (The previous version shown above allowed a minimal pair to have an additional field when one of the fields was empty. I removed that. Now the ZWART-A gloss only has two minimal pairs.)
I'm wondering what to do about glosses with identical phonology, if anything. These are not shown in Minimal Pairs, but they are kind of visible in a backwards sort of way. See the example screenshots below of ZWART-A (which has Minimal pairs ALLEEN-A and WOKKEL-B), ALLEEN-A and WOKKEL-B (which are identical), and then see the signs ONWEER and ELEKTRICITEIT-D, which are both identical to ZWART-A, as well as minimal pairs of both ALLEEN-A and WOKKEL-B.)
As a user, this seems kind of weird, since it seems to be hidden. Do we want this kind of information about glosses with identical phonology to be showable?
Hi @susanodd -- Good question! Signs with identical phonology can have three different kinds of status for us:
To help us with this workflow, it would be really useful if these could somehow be displayed in a separate area (w/header in red) at the bottom of the new page: "Identifcal phonology but not marked as homonym".
Oh, that's nice!
Oh, and a response to your first question earlier on: yes, if it's slow, we should harvest these relations overnight rather than generating them dynamically. If we do so, it would be useful to have a manual way to update that part of the database during the day. Reason: if people have done a lot of work e.g. on removing false homonyms, they should have a way to refresh the views.
Okay, i added the "identical phonology" pop-down for when the matching glosses haven't been added as homonyms. Here are screen shots.
The gloss SusanTest-D is the same gloss (homonym to ONWEER) but with the identical phonology as Homonyms instead.
I placed the (optional, red) pop-down underneath the Minimal Pairs pop-down since the data in the model is retrieved in the same method (to avoid additional method invocations). When we pre-compute the data, this can be retrieved more efficiently and placed elsewhere in the gloss detail view.
I think for the final version (when it is pre-computed):
One other thing: for the pre-computation (as for the dynamic one), I think we would like not to generate lists of all signs that do not have any phonology specified yet. Note: it seems that the two binary fields "Repeated movement" and "Alternating movement" always have a value ("No") even when we have done nothing about them.
Repeated movement and Alternating movement have a default of "not checked". So that's true, it's either Yes or No; there is no distinction between "No" and "Not filled in". It would seem the database type needs to be changed to reflect this. Other fields that have not been filled in (might) have either "-" or "-----" or "N/A". At places in the code that test for "empty" values, comparison is also done to '' and ' ' and None. This might have to do with evolution of the database contents.
Okay, the Identical Phonology is now right after phonology, and it's only shown if it's not empty. It's not editable.
I adjusted the gloss_detail view to not show the Repeated movement and Alternating movement when these are False. When you search for a sign, you can choose -------, True, False, or Unknown. But the default value in the database schema is False rather than Unknown. In my offline database, there are no signs with Unknown.
One more request, @susanodd : could you change the panel titel by removing the "ALERT: " and "!"? The red colour by itself is enough of an alert to us that something more needs to be done.
Question: The phonology field "Phonetic Variation", at the moment I am either including or omitting comparison of this field for minimal pairs. (Two versions of the code, seeing how it works.) An example is the glosses ONWEER, KLEUR-A and KLEUR-B. (In my off-line database.) KLEUR-B has this filled in. It's a write-in field. (See the phonology in the screenshots below.) KLEUR-A is a minimal pair of ONWEER on field Strong Hand. The question is: KLEUR-B also differs from ONWEER on field Strong Hand. But it also differs from ONWEER on Phonetic Variation. Should Phonetic Variation be counted among the fields compared for Minimal Pairs?
Ah, good question @susanodd . Please ignore the field Phonetic variation for the minimal pair computation.
So for the above example, KLEUR-B is also a minimal pair of ONWEER on field Strong Hand.
Okay, the MInimal Pairs are implemented now. Dynamically. And it's fast now! There had been a problem with "empty" values using many different encodings. And with glosses that had no phonology at all. That was causing thousands of minimal pairs for each empty gloss. That's fixed now, empty phonologies are ignored. I just need to make a version of gloss_detail that's a slightly different name so it can be uploaded for testing.
The Gloss Detail View with Minimal Pairs and Homonyms has been committed. Now we're just waiting for @Woseseltops . :)
I discussed this with the ASL team; they'll also want this once the ASL SB has been moved to the US.
Working my way through the 'tbc after asl migration' issues. I think the ASL SB has this now, agree this can be closed @ocrasborn ?
I think this needs to be adapted for the ASL phonology fields: as they are largely different from the NGT fields, it now appears that any sign has a zillion minimal pairs. @susanodd , could you take this up?
This issue was introduced some time ago. Since then, a "Minimal pairs list" view has been added under Analysis. The Minimal Pairs computation has also undergone a number of revisions as part of other issues (e.g., display of Boolean fields, removal of hard-coded queries).
@ocrasborn, can you check whether this issue can be closed? There are much fewer minimal pairs than there used to be. Some glosses may have minimal pairs because of sparse phonology. If you look at the Minimal Pairs list of the Analysis menu, you get an overview. It's easier to check for anomalies there. As an example, the Shanghainese sign NEARBY-B has 27 minimal pairs. It has 3 phonology fields defined.
Although created with an eye on linguistic (phonological) analysis, the minimal pair list helps us identify errors in the phonological description, including incomplete (sparse) phonologies. Human signers quickly identify a 'false' minimal pair, and this will prompt them to double-check whether the phonology is OK. As far as I can see, the function works well, so I'll close this.