SignBank ECV and Dropbox w/ELAN

ELAN
1

Hi, I work regularly with ASL SignBank, one of the SignBanks following the general template, and we use an ECV to connect our SignBank with ELAN so that we can annotate directly from the SignBank list, have pop-up videos of our gloss videos from the SignBank website in-line in ELAN as we work, general lexicon services, etc.

Now, I haven’t experienced this issue myself but I have gotten reports from a few people about an issue that I wasn’t sure the source of but the commonality appears to be use of Dropbox to store/access .eafs as opposed to locally on one’s computer HD. The problem was first observed sometime around late summer/early fall this year, 2018. Before that time, at least 1 person was using Dropbox to store/use ELAN files with no apparent issues.

The issue is in the form of a warning saying that the file doesn’t recognize the ECV used in ELAN, and the ECV doesn’t appear to update as SignBank is updated over time.

Could the location of files being on Dropbox instead of locally be causing some kind of issue with the ECV not having permission to have the external link refreshing with SignBank?
Everyone involved is, to my knowledge, using ELAN 5.2 at the moment. Would you expect a change to 5.3 to make a difference here? Looking at the release notes nothing jumps out at me as relevant.
Let me know if more clarification would be useful, and thank you!

2

I remember a few reports of problems that seemed to have been caused by eaf or media files being in a Dropbox or OneDrive folder. Problems that were solved by moving the file elsewhere. It has never become clear to me what the problem actually was, since some people work with files in a Dropbox folder without a problem.

I assume the ECV is not in a Dropbox folder? Then I wouldn’t be able to explain why it sometimes doesn’t update. That should be unrelated in that case? Any messages in the log that could explain why the ECV isn’t updated correctly?

3

Han, thank you for your reply!
Again, I haven’t experienced the issue myself. I did some troubleshooting (remotely) with one of the affected users last night, during which I found an interesting difference in the code of affected vs non-affected (working fine) files. My understanding is that both of these files are accessed via Dropbox regularly. So perhaps I was hasty in supposing that it might be a Dropbox problem, but I didn’t have this information as of my original post.

The last lines of the .eaf when opened in a text editor read like this for files on my computer that work, and for working files on the remote collaborator’s Dropbox:
<EXTERNAL_REF EXT_REF_ID=“er1” TYPE=“ecv” VALUE=“https://aslsignbank.haskins.yale.edu/static/ecv/asl.ecv”/>

My reading of the above line is that the ecv is linked to ASL SignBank at that proper URL.

Alright, now here is what the last few lines look like for the non-working files (though I did anonymize the file path, leaving the start and end intact). Notice the difference in that there are 3 lines where the other file has just one, and notice that even the ASL SignBank site link is not the same one:
<EXTERNAL_REF EXT_REF_ID=“er2” TYPE=“iso12620” VALUE="-"/>
<EXTERNAL_REF EXT_REF_ID=“er1” TYPE=“resource_url” VALUE=“https://aslsignbank.haskins.yale.edu//dictionary/gloss/”/>
<EXTERNAL_REF EXT_REF_ID=“er3” TYPE=“ecv” VALUE=“file:/Users/labname/Dropbox%20(LABNAME)/REMOVED-FOLDER-PATH/ASL%20Signbank%20CV.ecv”/>

So I went to see what each of the 3 external refs (er) point to.
er1 is only found in one tier’s annotations, like so: do I read this correctly as these annotations are referencing the aslsignbank…/dictionary/gloss URL?
<ALIGNABLE_ANNOTATION ANNOTATION_ID=“a260” CVE_REF=“2156” EXT_REF=“er1” TIME_SLOT_REF1=“ts4” TIME_SLOT_REF2=“ts5”>
<ANNOTATION_VALUE>YYY</ANNOTATION_VALUE>
</ALIGNABLE_ANNOTATION>

er2 is found in exactly one annotation in a similar way, which I can’t explain:
<REF_ANNOTATION ANNOTATION_ID=“a16” ANNOTATION_REF=“a15” EXT_REF=“er2”>
<ANNOTATION_VALUE>Whisper.</ANNOTATION_VALUE>
</REF_ANNOTATION>

er3, the one that goes to an ECV on Dropbox, is found in this line only, describing a CV:
<CONTROLLED_VOCABULARY CV_ID=“ASL Signbank lexicon” EXT_REF=“er3”/>

The above lines are as seen in a non-working file. In a correctly working file, again, there is just 1 external link to SignBank at the URL …/static/ecv/asl.ecv like so:
<CONTROLLED_VOCABULARY CV_ID=“ASL Signbank lexicon” EXT_REF=“er1”/>

Do you have any idea how it might have gotten this way or what we can do to make the non-working files be like the working files? I’m told by the collaborator that they used the same template when setting up all files, but if that’s the case then it seems clear that something has happened to some files since that point.

And to answer your actual question, based on these lines of code, the ECV is in a Dropbox folder. Though ideally I would have thought the ECV link should point to ASL SignBank (some URL), not a local file. Is that right?

I’m flummoxed and any speculation or possibilities that you have would be much appreciated!

4

Thanks, that clarifies at least the difference in behavior: it’s caused by differences inside the eaf files.
Concerning the 3 external references in the not-working file:

  • the one with TYPE=”iso12620″ (”er2″) is a reference from a tier type or annotation to an ISOcat data category. The value should normally be a (specific type of) url. I don’t whether it is possible to get ELAN to write a value of “-”.

  • the one with TYPE=”resource_url” (“er1”) seems to point to an internet directory (not to a file). I wouldn’t know how to create such a reference in ELAN.

  • the one with TYPE=”ecv” (”er3″) points to a file in a Dropbox folder. In principle this is possible and ok; one could even link an ECV from the local hard drive. In a team setting the Dropbox variant might even work if all team members have the exact same folder structure on their computer (starting with “/Users/labname/”).
    But I understand that the intention is that all eaf files involved, sync with ASL Signbank updates. Then it is best to change the url to the “https://aslsignbank.etc” version of the correct files.

Repairing the files can probably best be done in a text- or xml-editor: remove the superfluous <EXTERNAL_REF… /> elements completely together with any “EXT_REF” attributes from annotations pointing to the removed elements.
If you update the TYPE=”ecv” external reference, you might change the ID to “er1” (is not really necessary) but then you’ll have to update the EXT_REF attribute from any controlled vocabulary pointing to that ECV too.

5

Han, thank you! I hope that the issue can be solved by manually replacing/removing the references as you suggest. I’ve had luck with that method in other issues before. I’ll ask the collaborator to try this and get back to me.
I do have one concern - if the aslsignbank URL version of the ecv is slightly different and more updated than the ecv that is currently being used (Dropbox version), then what will happen in regards to the links that tell ELAN which CV entry maps to which thing? This may be a question I should ask the SignBank developers e.g. Onno Crasborn instead, but… do you have any thoughts on this? In the past there have been problems with entries that become un-linked to SignBank if a SignBank gloss is deleted or while the file is not actively connected to SignBank (ie via a ECV pointing to a URL, as opposed to a static local ECV file). Or maybe the answer is that yes, that happens but that there is an easy way to fix it?

6

Yes, there can be some issues with replacing one ECV URL by another.
When a file is opened in ELAN, ELAN checks whether annotation values are still correct based on the CVE_REF of those annotations. The default behavior in case of a mismatch, is to update the annotation value, but there is an option in the CV tab of the Edit Preferences window to maintain the annotation value but update or remove the CVE_REF from the annotation (since ELAN 5.3).

7

Thanks for clarifying that, much appreciated. I’ll make sure that the affected parties are using ELAN 5.3 when they are replacing the references and re-opening the ELAN file. Will update here if there are further issues that I’m alerted too. As ever, thank you very much, Han!