Skip to content

Check for general parameter overlap during sign comparison #487

@kchall

Description

@kchall

Basic idea:
-within a parameter (at least "movement," "location," "handshape", and "relation"), it's possible that all the aligned modules mismatch each other, but there is still some overlap in the actual phonological structure (e.g. because H1 in sign 1 matches H2 in sign 2, but these two hands weren't aligned with each other)
-so, we'll add a check for general overlap that in such cases will just pop up with a user message along the lines of “Note that there may be some additional overlap in phonological form not captured here. There is XX in Sign 1 that also occurs somewhere in Sign 2. We recommend checking manually.”
-overlap is checked for by pulling out a list of all modules for each sign that have any of the following specific elements

The specific elements to include as the 'sets' for each parameter:

  1. Handshape -- all the 'base' handshapes
  2. Movement -- the specific movements as follows: Straight, Arc, Circle, Zigzag, Loop, Nodding/Un-nodding, Pivoting, Twisting, Fully rotating, Closing, Opening, Pinching/Unpinching, Flattening/Straightening, Hooking/Unhooking, Spreading/Unspreading, Rubbing, Wiggling/Fluttering

(note that for "Closing" and "Opening" I am including the lowest level of the change, whereas for all the others, I am just including the highest level of the movement -- this is intentional)

  1. Location -- the specific locations as follows: Head, Neck, Torso, Arm, Leg and Foot, Whole Hand, Horizontal/Ipsi, Horizontal/Contra, Horizontal/Central, Vertical/High, Vertical/Mid, Vertical/Low, Sagittal/In front, Sagittal/Behind

(note for all the locations, these can be matched even if they have lower specifications that differ, e.g. if Sign 1 has Head / Top of Head and Sign 2 has Head / Face, they both get marked as having a "Head" location and so there is overlap)

  1. Relation -- only the specific selections as follows: Contact; X and Y are crossed; X and Y are linked; Body parts (probably these should be checked at the lowest level of the hierarchy for exact matches, e.g. Finger 1 == Finger 1, etc., with no further check of sub-area or bone/joint)

(this is a really small subset of the possible relations, but I think most other things would come up far too often to be worthwhile -- that is, too many signs "don't have contact" and so we shouldn't mention it every time!)

NB: I also think that the criterion for doing the overlap check might need to be different for relation modules than for other module types. For hand config, movement, and location, the overlap check is done and the message is displayed if, when the full set of specifications in all the aligned pairs of modules of that type has no blues (only reds and yellows). For relation, the overlap check is done and the message is displayed if, when the full set of specifications in all the aligned pairs of modules of that type has either no blues or only blues in the "X" and "Y" specifications. See the example of BEAR and MULTIPLICATION below.

--> I still need to think about non-manuals. I think orientation probably doesn't need this extra level of checking.

So e.g. if we have the following two signs:

Sign 1 [HELICOPTER]
H1 Hand config: 5
H2 Hand config: 1
H1 Location: Whole hand / Fingers and thumb / Fingers / Finger 1
H2 Location: Hor/Central, Ver/Mid, Sag/In front
H1 Movement: Trilled twisting

Sign 2: [APPEAR]
H1 Hand config: 1
H2 Hand config: 5
H1 Location: Whole hand / Fingers and thumb / Between fingers / Between Fingers 2 and 3 / Between Fingers 2 and 3 - contra
H2 Location: Hor/Central, Ver/Mid, Sag/In front
H1 Movement: Straight / Doesn't interact with a subsequent straight movement

Then the set of elements for each sign is:

Handshape:
HELICOPTER: {5, 1}
APPEAR: {1, 5}
--> these overlap but the actual alignment and comparison would lead them to be fully 'mismatching' and so would trigger the message

Location:
HELICOPTER: {Whole hand, Hor/Central, Ver/Mid, Sag/In front}
APPEAR: {Whole hand, Hor/Central, Ver/Mid, Sag/In front}
--> these overlap, and the actual alignment and subsequent comparison would have all the locations aligned and matching at the top level (though not fully matching all the way down), so doesn't need to trigger the message

Movement:
HELICOPTER: {Twisting}
APPEAR: {Straight}
--> these don't overlap, so even though the actual alignment and comparison would also have nothing match, no message is triggered because there really is no overlap


Relation example:

BEAR:

Image

MULTIPLICATION

--> In this example, both signs have 'arm' relations, and then MULTIPLICATION also has a 'hand' relation. The 'arm' relations will align and since both have X = Arm 1 and Y = Arm 2, they will be blue at that level. But nothing else about the arm relation modules is the same across the two signs. So, the overlap check should be done, and should note the following:

Relations for BEAR: {Contact, X&Y are crossed}
Relations for MULTIPLICATION: {Contact, X&Y are crossed}

--> These overlap, but they overlap in modules that weren't aligned with each other, so they wouldn't have been reported under regular sign comparison. The message is triggered in this case.


Movement example:

CANDLE and CANDLE (backwards):

Image

--> in CANDLE, H1 flutters while H2 makes a straight tapping movement (I added the 'tap' to make this example work); in "backwards" CANDLE, H2 flutters while H1 makes the straight movement; the general overlap check should notice that they both involve fluttering and straight movements


Location example:

SICK and SICK (backwards)

Image

--> in SICK, H1 is on the forehead and H2 is on the stomach (torso / abdominal area); in "backwards" SICK, H1 is on the stomach and H2 is on the forehead; the general overlap check should notice that they both involve "Head" and "Torso" locations


Link to sample corpus: https://www.dropbox.com/scl/fi/1f0isomy9g2neytil3z4g/Parameter_overlap_corpus.slpaa?rlkey=dy28c37mj6badpk3l382dsjrr&dl=0

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions