Done
https://edgeryders.eu/en/openethnographer-codes-conversion-table
There is also a filter that can act as a search. But maybe Ctrl-F is faster.
Looks good
Thank you!
1 Like
How to merge tags
When I attempt to rename a tag to an already existing tag (in order to merge the two) I get this message:
How do I merge them into the same thing?
For example, in this instance I attempted to merge “triage” with “resource allocation” by renaming the “triage” tag “resource allocation”
Not merging
That’s not true merging, because the two tags keep having separate IDs even if they have the same name.
I am not sure there is support for tag merging in OpenEthnographer (@danohu ? @Matthias ?). There are three ways that I can think it can be done:
- Low-level, batch: run a SQL query on the database that will assign the "triage" tag the same name and ID as "resource allocation". This cannot be done from the Drupal admin interface, it requires Matt to write the query and launch it from the server.
- Low-level, slow: go through the annotations tagged "triage" (I switched back to the old name for clarity) and change them manually to "resource allocations". This is not so bad, because there are only four annotations tagged "triage", and they are numbers 1755, 1815, 1817 (these last two are on the same comment, number 4225), and 1822. This would be my recommended method.
- Workaround: create a new tag called "resource allocation". Assign it as a parent tag to both the old "resource allocation" and "triage". This does not really solve the problem, but it does associate "triage" and "resource allocation".
For comprehensive tag management, however, this is not going to fly. We will need to implement a better way to do it. Let’s put this on the agenda of the upcoming consortium meeting.
1 Like
Should be possible with Drupal’s term_merge module
Renaming is indeed not proper renaming (even though the exports in RQDA format might have tags with the same names exported to the same tag, that is, properly merged – I just don’t properly remember).
The simplest way for proper merging will be to install Drupal’s term_merge module. It should work (since OE uses the normal Drupal taxonomy feature), but since we do a bit of special stuff in Open Ethnographer I want to test that before putting it live. I’ll take time out for that tomorrow.
(The special stuff is that OpenEthnographer data is stored with an own entity type “annotation”, having its completely own table and not integrating with Drupal’s field system. So I don’t know yet if term_merge will properly update references to a term made in annotations. We’ll see. If not, Alberto’s first alternative would work too, I could provide a few “drush sql-query” commands that Alberto can customize and run on demand on the server.)
Ready!
I stand ready to customize and run. All of this GUI stuff is overrated anyway 
Can we make this a priority?
It’s very important to be able to quickly and easily merge tags in order to have effective management of the data. It is not feasible for most of the annotations to go back through and retag them (and, more importantly, it isn’t a sustainable practice).
In the meantime I will focus on the hierarchies and continuing to code more posts.
1 Like
Oh sorry
@Alberto I missed your initial reply from above. Will make you the required drush commands after sleep.
Thanks, and
Drupal module is a superior solution to Drush command, because with the former Amelia can be independent from me. So I’d take that, if possible. If not, Drush.
Ping?
@Matthias – this seems to have slipped under the radar. We will do more hacking around this Monday – it would be great to have the module up and running by then. Feasible?
1 Like
Couldn’t keep up … will try again
@Alberto It is on my list but I did not get to it so far. Just can’t keep up with what I have on my list currently 
Ok, finally tried this task today, failed for now (quite early … SSH login issuem grr). Will work on this tomorrow from on a train. That is my last chance for getting this done until Monday, but it should do the job.
(One caveat: except if there’s some programming to do. Which could be possible, since the term_merge module might not find the taxonomy references stored by he annotation module (it uses its own data base table / Drupal entity type for storage). I’ll know more tomorrow. Unfortunately I don’t have a quick fix if that happens.)
Thanks and plan B
Thanks @Matthias , you rock.
If not: plan B. You write me a SQL query, I SSH into the server, sit with @Amelia and run it with the names of the tags to merge and the other parameters as needed. We can do this Sunday from the hotel.
1 Like
Merging seems to work
Ok, term_merge complains a bit (“missing field handler”) but does its job. I just merged two terms into one in my comment above this, and it is successfully reflected in the annotations. Quite astonishing, I expected problems …
The interface to merge terms is here, and I enabled it for ethnographers and ethnographer admins (and site admins of course).
Edit: Note that you can select multiple terms to merge into a target term, and one target term. Use Ctrl+Click to select multiple terms to merge into one other term.
Great!
Can’t wait to try it out. I’ll be working later today --willsee how it goes then.
1 Like
New comments in Opencare Explorer working well
@Alberto Just wanted to say that the new comments function in Opencare explorer is working great---- it’s allowing me to make sure that posts that have already been coded stay complete. I think (as we discussed briefly) it is better to expand in that way with fully coded posts as opposed to many partially coded. Do you agree?
1 Like
Fully agree
On top of the advantages for the coding itself, it gives us a way to quantify the work done vs. the work to do. Just count the threads with at least one annotation (and their comments) vs. those with no annotations (and their comments). We’ll write a script to do that in Milano.
Makes sense
keep in mind that I am starting with posts that have the most comments and working my way down-- is there a way to reflect that when calculating work done vs work left? It will get exponentially faster as we go.
Sure
Count all posts => AP
Count posts with at least one annotation in the thread => CP
## The above is tricky because we have to go through the relationship between entities, but can be done.
Count all comments => AC
Count comments to posts in CP => CC
Share of work done for posts: CP/AP
Share of work done for comments: CC/AC