DCS-LCSR / SignStream3

Sign language linguistics annotation software
2 stars 0 forks source link

Problem with inserting data from the Sign Bank #607

Open cneidle opened 1 year ago

cneidle commented 1 year ago

Inserting name signs normally correctly results in the name sign box being checked.

However, when preceded by a handshape prefix, that does not happen.

Not sure whether this is a problem on the SignStream side or on @kwasiopoku Augustine's side (i.e., information provided in the Sign Bank file), but FYI

Screen Shot 2022-12-07 at 9 26 47 AM
cneidle commented 1 year ago

same problem:

Screen Shot 2022-12-07 at 10 33 31 AM Screen Shot 2022-12-07 at 10 33 36 AM
douglas-motto-at-rutgers commented 1 year ago

See #579

douglas-motto-at-rutgers commented 1 year ago

In latest 3.4.1_pre...

"Name sign" is initially checked by default when creating a new gloss with label "ns-XXX" or "(A)ns-XXX" (not inserted from the signbank).

But this checkbox is not enforced by the label name ("Entry"), or other property settings (radial "Sign Type" selection), when editing the gloss. Any "Sign Type" may be changed to have or not have the qualifier "Name sign" checked.

On save, the collection files state all three properties...label...sign type...named...whatever they were set to.

The SignBank only includes two properties...label...sign type. When "Inserting All Data" from the SignBank search, the label does not effect the "Name sign" checkbox or the "Sign Type" radial option selected. The label in the SingBank may be "ns-XXX" or "(A)ns-XXX" or "XXX"...and the checkbox may be checked or not. The SignBank property "sign type" MAY control the "Name sign" checkbox. It's value appears to be one of the follow..."LEXICAL", "LOAN", "NUMBER", or "NAME". If "LEXICAL", "LOAN", or "NUMBER", the radial is changed to that value, BUT the the "Name sign" checkbox is left unchanged. If "NAME" is in the SignBank's value for sign type, the "Name sign" checkbox is checked, BUT the sign type selection radial is left unchanged.

Some possible issues....depending on the desired behavior....

1) The morph-phone selections are not constrained or validated on change.

2.a) The signbank needs to separate out sign type property from a name sign property...making them independent. OR POSSIBLY 2.b) A "NAME" signed value should force the "LEXICAL" sign type. OR POSSIBLY 2.c) In addition to "LEXICAL", "LOAN", and "NUMBER"...there should be "LEXICAL-NAME", "LOAN-NAME", and "NUMBER-NAEM"...to indicate both type and name value combinations.

As for the examples in comments above...in the SignBank it appears that all "ns-XXX" labels are of type "NAME" and all "(Y)ns-XXX" labels are of type "LEXICAL"....which is why the name checkbox is not set on insert from "(Y)ns-XXX".

cneidle commented 1 year ago

It seems to me that there are two things to be addressed:

1) When "insert all data" is used to populate or repopulate the Morph-Phon window from the Sign Bank, the ns checkbox should be unchecked unless the gloss being inserted contains an "ns-" prefix.

2) The determination about whether there is an ns- prefix should allow for something in parentheses before the "ns-", e.g., "(Y)ns-XXX" ought to trigger the ns- checkbox.

I don't understand the comment above. Name signs are NOT radio buttons, because every sign has one of the types associated with the radio buttons. The name sign designation, if it occurs, is in addition to the other sign categorization.

gregorydimitriadis commented 1 year ago

The issue is that with the current sign bank files, the SIGN_TYPE value treats NAME sign as a sign type, not as an additional to the sign categorization. As Doug noted, your example from the original post "(M)ns-MEXICO" is listed as "LEXICAL" in the global sign bank file. Others in the global sign bank file with just "ns-" as the beginning of the label are listed as "SIGN" - this causes the discrepancy.

I see in the code, though, that there is no case to handle when SIGN_TYPE == SIGN, however, so something else must be happening which forces the 'name sign' checkbox to get ticked in this scenario. Would need to look into it further. But the suggestion is valid: about needing either an independent property for 'name sign true/false' in the sign bank file OR a new way to identify signs which are " PLUS "

cneidle commented 1 year ago

Not sure what is going on under the hood, but just FYI, this is what is listed in the online Sign Bank:

Screen Shot 2023-01-29 at 9 47 26 AM

after inserting all data:

Screen Shot 2023-01-29 at 9 49 46 AM

and this is what shows up in the Utterance window:

Screen Shot 2023-01-29 at 9 47 47 AM
cneidle commented 1 year ago

See also SignStream entry #607