Create another detail view (for displaying all related signs)

[ocrasborn]

• All related glosses for a sign should be displayed in a separate list view
• Related glosses come in several types 1) variants: same string in the "Annotation ID Gloss" field, except for the suffix -A / -B / -C etc. 2) all signs linked in the Relations to Other Signs panel 3) all minimal pairs -- to be calculated from the phonology fields. Signs that differ by only one phonological field value are minimal pairs.
• Display similar to the list view, multiple columns: image the two Annotation ID Gloss fields (Dutch & English) translation equivalents/keywords handedness strong hand weak hand **location
• Select this view by clicking a button/tab "Related Signs" at the top, similar to the "Public View" button that's present now at the top of the detail view.
• Display in blocks of variants/related signs with a block header above the column headers (to be repeated for each block?, blocks appearing in this order: Source sign Variants Homonyms Synonyms Antonyms Hyponyms Hypernyms See also ** Minimal pairs
• Blocks should only appear if they contain content

[ocrasborn]

Mockup:

[ocrasborn]

For minimal pairs, visualise somehow what the one field+value is in which the two signs differ.

[vanlummelhuizen]

Note: @susanodd and I decided not to split this issue into subissues so we could have a more delimited view on this issue.

Sub tasks:

1. Create a detail view with just the source sign
2. Add sign relations (homonyms, synonyms etc.). No database changes are needed
3. Add variants.
   1. First find variants dynamically when rendering the page, or better: using an ajax call. This may be a bit slow, but no database changes are needed. The algorithm for finding variants: if a idgloss ends in a dash (-) and one capital, search for glosses that start with the idgloss where the dash and capital are removed (exclude the current gloss of course).
   2. If page generation as describe above is indeed slow, we need precompiled variant relations. My assertions is that variants are grouped by their prefix. So we need something like VariantGroups that are identified by the first part of the variants. This variant group should be referred to by each gloss belonging to that group. Database changes needed! Whether a gloss is in a variant groups should be checked upon gloss creation, idgloss change and gloss deletion.
4. Add minimal pairs.
   1. First find minimal pairs dynamically when rendering the page, or better: using an ajax call. This is probably slow, but no database changes are needed.
   2. If page generation as described above is indeed slow, we need precompiled minimal pairs. My assertion is that it is a many-to-many relation that uses a cross-reference table. The first and second reference are interchangeable, i.e. minimal pair A,B is the same as B,A. So, if both are kept, one of them is redundant. Database changes needed!

Sub tasks 3ii and 4ii could be saved for last.

[susanodd]

Okay, the first two are done. For variants, the model.py file has as relation role choices:['homonym','synonym','variant','antonym','hyponym','hypernym','seealso]. Note the relation "variant" is already (able to be) stored in this way. Although there is only one sign that has this entered (in my off-line version of the database, KOUD-A has variant KOUD-B as a relation to other signs.)

So the question is, this code of the model (for relation choice 'variant'), who put this code there? Was the intention to add variant information to the model in this way, but the data didn't get updated?

[vanlummelhuizen]

So it seems that variants can already be stored in relations. That is nice because it would mean implementing the displaying of variant does not have to be dynamic first.

Since creating relations is now done by hand, there may be few variant relations. We could however automatically create relations using the algorithm described by me earlier. Perhaps this could be a smal side step for you to take now @susanodd

[ocrasborn]

I think the 'variant' was an old relation that we took over from the Auslan source. I'm a bit in doubt as to using it for distinguishing -A/-B/-C etc. from each other. The reason is that we would want to be able to edit the relations manually (promoting variant to the more specific 'synonym', e.g.). If we automatically generate the relations, how can we make sure that the more specific relations are not overridden by or supplemented with a fresh relation 'variant'? We would need to re-generate this regularly (overnight, I suggest), as we constantly add new variants (-C to where before we only had -A and -B, for instance.

[susanodd]

Okay, variants are working now. I have them in the new detail view page for the relations of a sign.

I also made a separate page for listing all variants found in the database [as a preview for storing variant relations in the database when a sign is not already related to a proposed variant via a different relation; we haven't decided what to do with that yet. For my offline version, this is a very long list, since only one sign had variant information stored.]

At the moment, under a gloss detail view, there is the pop-down section for Relations To Other Signs. Should variants show up there? (Dynamically.)

[ocrasborn]

Hi @susanodd, just to check: which type of variants are you talking about now? The -A/-B/-C variants? Or the minimal pairs? I would prefer to hide the A/B/C variants from the relations panel in the detail view, but to show the minimal pairs.

[susanodd]

A, B, C, variants. Okay, I won't put them there.

[susanodd]

Minimal Pairs: should the same number of field + value pairs be defined for those that are minimal pairs? (Or can one gloss have a value for a field while the other gloss has no value for that field? If so, do empty values count as matching/wild cards?)

In other words, can the "minimal pair" be that one gloss has an additional field+value defined? Or should the minimal pairs be the same length.

Or alternatively, I guess you'd end up with one gloss being a sub-gloss in terms of field+value pairs? (Sorry, I can't tell if this question is nonsense. I'm just thinking about querying the database. There are a lot of fields and they are filled in sparsely. It could be that the data hasn't been completely filled in yet.)

[ocrasborn]

No nonsense as far as I can see :-) If I understand the question correctly: yes, empty values also count. Examples: one sign has a value for handshape change, the other does not. One sign has a value for repetition/repeated movement, the other does not. (In the latter case, not having this binary feature is actually value 'no', but I don't know how this is implemented in the database, as a binary field or as absent/yes/no).

[Woseseltops]

Without having read all of the above, I had a discussion with @susanodd about minimal pairs, and below I describe how I thought it should work. Please let us know if this is wrong.

Say glosses have only three fields, and can have letters or nothing as values.

• [a,b,c] and [a,b,d] are minimal pairs (1 field is different)
• [a,b,c] and [a,e,f] are NOT minimal pairs (2 fields are different)
• [a,b,c] and [a,b,] are minimal pairs (1 field is different)
• [a,b,] and [a,,c] are NOT minimal pairs (2 fields are different)

[ocrasborn]

Agree, @Woseseltops

[susanodd]

Here is what it looks like at the moment. At present, for Minimal Pairs, all the fields of the focus gloss are shown first, with the additional fields afterwards. @ocrasborn is this too much information? Which columns should be included/excluded?

[ocrasborn]

Hi @susanodd , yes, this is too much information. Please just take over the presentation type you have now made for the minimal pair panel: gloss -- field that differs -- value that differs (or absence of a value).

[ocrasborn]

@susanodd , separate request: could you include the picture of the sign in the first column, so below the red section headers and before the gloss in the second column? So that the overall view is very similar to what we see in the standard list view for the search results.

[susanodd]

Okay, here's what it looks like now. The gloss GEBOUW-D has images on my local computer, so that's why it's shown. The other example is WOKKEL-B (no images on my computer at the moment). WOKKEL-B has lots of minimal pairs. I made it small to show them all.

[ocrasborn]

Looks great @susanodd !

[susanodd]

[susanodd]

Here is the first step in pre-compiling variants. This is a giant list of all glosses with variant patterned names (generated dynamically), followed by relations to other signs, followed by relations that are variants, followed by candidate variants (those not appearing in the relations), and then buttons to add them (move from candidate column to variant relations column.)

The next step is to automatically press all the buttons and put the candidates in the variant relations column.

(I did it this way first to make sure it's working before doing thousands of updates at once.)

[susanodd]

Okay, I have a "find_and_save_variants" page implemented that can be run to find the variants in the database, and store those that are not yet stored as variant relations. The table headers are shown in the first screen shot, with the "other relations", the (existing) "variant relations (pre)", the "candidates" (to be saved), and the (post update) "variant relations (post)".

In the second screen shot, you can see examples in SusanTest variants where there are other relations, which keep a found variant candidate from being saved.

[susanodd]

Sentence should be: Already existing other relation for a variant patterned gloss, which keeps it (the variant pattern in an other relation) from becoming a candidate variant. (The candidates are the things to be saved.) (The example is Focus Gloss SusanTest-B where SusanTest-C is an antonym, so it doesn't get saved as a variant.)

[susanodd]

After running the find_and_save_variants routine, the variants are stored in the database as relations.

(To do. This code is on a separate branch. This code will need to run periodically to make the views that want to display variants be efficient. The creation of a new gloss could possibly find any variants for the new gloss, as for how not-yet-stored homonyms are shown in the Gloss Detail View, Issue #277.)

[susanodd]

https://signbank.science.ru.nl//dictionary/gloss_relations/1775/

[ocrasborn]

So cool!

[Woseseltops]

Yeah @vanlummelhuizen and me were also quite excited about it

[ocrasborn]

@susanodd , is there a use of find_and_save_variants for the end user, or was it only needed by you in the first generation of relations? The relation as 'variant' between, say, DOG-A and DOG-B are not listed in any of the panels, nor do they need to be.

[susanodd]

The routine find_and_save_variants also exists. That one does update the database, so it's not been advertised.

Variants can be stored in the Relations to Other Signs. (That functionality has always been there, In order to increase efficiency, the Relations View only shows the stored Variant Relations. It was intended that the variants could be done automatically by the system with the find_and_save_variants view.)

The code is on the site, but if you visit the page then it will find and save variants.

I could modify this code so that it merely displays them and not save them, as for Homonyms. Or we can make it inactive by commenting it out of the urls.py file.

I can update the Related Signs page to compute the Variants dynamically. An earlier version found both saved and dynamic.

[ocrasborn]

I've boldly gone where no Onno has gone before, and ran the find_and_save_variants. It's rather useful to also have these in the Relations View, and their presence doesn't really bother us in the Relations to Other Signs panel (although strictly speaking, they are not necessarily semantic 'synonym' relations, the Dutch words for the gloss overlapping can mean either (near)synonymy, or a homonym in Dutch where the sign meanings are really different. Now, it would be good if these variants were kept up to date of course, as we regularly add XX-A and XX-B variants where initially we just had XX. Do you have an idea about how to best take care of that, @susanodd ?

[ocrasborn]

Now that we've put some improvements in separte issues, I'll go and close this @susanodd . Feel free to reopen and comment on aspects that still need polishing.

[Woseseltops]

Working my way through the 'tbc after asl migration' issues. I think the ASL SB has this now, agree this can be closed @ocrasborn ?

[ocrasborn]

yup

[ocrasborn]

oops, sorry, no: the button to go to the Relations View in the Detail View doesn't work yet (KeyError).

[susanodd]

@ocrasborn, can you say which gloss gave this error? If you're looking at a particular gloss, then the Relations View goes to the url with gloss_relations instead of gloss, and the same id number. It should be able to generate this url without an error because you're starting out on the same gloss number. (The gloss already exists because you're looking at it.) So maybe there is something else going on with your particular example.

[ocrasborn]

This is for the ASL SB, @susanodd . See e.g. https://aslsignbank.haskins.yale.edu/dictionary/gloss_relations/2007

[ocrasborn]

@Woseseltops , does this already work for ASL and can we close the issue?

[ocrasborn]

It works, as far as I can see. Can we close this, @Woseseltops ?