# Review recipe with blocks interface **URL:** \ **Category:** Uncategorized\ **Tags:** enhancement, ner, done, review\ **Created:** [February 4, 2020, 6:21pm UTC](https://support.prodi.gy/t/review-recipe-with-blocks-interface/2501 "2020-02-04T18:21:18Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![oshiro](https://avatars.discourse-cdn.com/v4/letter/o/0ea827/32.png) [@oshiro](https://support.prodi.gy/u/oshiro)\ **Post date:** [February 4, 2020, 6:21pm UTC](https://support.prodi.gy/t/review-recipe-with-blocks-interface/2501/1 "2020-02-04T18:21:18Z")
Hello. I'm having some difficulties with the review recipe. The annotation task is basically a ner\_manual task, but I use the blocks interface to add an html block to give more information regarding the sentence to the annotator. We have 2 annotators using 2 different sessions and now I want to review their annotations. However, when I start the review recipe the web application opens with the message "No blocks available.". Can you help me? The Prodigy version is 1.9.4 and I'm starting the recipe as follows: prodigy review -v ner\_manual final\_dataset task\_dataset-bianca,task\_dataset-julio ---
**Author:** ![ines](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/ines/32/3_2.png) [@ines](https://support.prodi.gy/u/ines)\ **Post date:** [February 5, 2020, 10:32am UTC](https://support.prodi.gy/t/review-recipe-with-blocks-interface/2501/2 "2020-02-05T10:32:40Z")
Thanks for the report! It looks like you hit an interesting edge case here: the `review` recipe will check the tasks for their `"_view_id"` and then use that to decide how to render the examples in the review interface. The `--view-id` is only used as the default and fallback. In your case, the interface is `"_view_id": "blocks"`. So Prodigy will try to render the content with the `blocks` UI, but since the `review` recipe doesn't define any blocks, you see "No blocks available.". The easiest workaround would be to either edit the recipe in `review.py` and add your blocks to the config, or to create a `prodigy.json` in your local working directory that sets `"blocks": [...]`. (A `prodigy.json` in the working directory overrides the global config so you can use it to set project-specific config like blocks, without having to add it to the recipe or global config.) I'll think about how to solve this – the easiest solution would probably be to allow the `--view-id` argument of the `review` to override the `"_view_id"` of the task. Then your command would work and Prodigy would render the content using the `ner_manual` interface. ---
**Author:** ![oshiro](https://avatars.discourse-cdn.com/v4/letter/o/0ea827/32.png) [@oshiro](https://support.prodi.gy/u/oshiro)\ **Post date:** [February 5, 2020, 2:22pm UTC](https://support.prodi.gy/t/review-recipe-with-blocks-interface/2501/3 "2020-02-05T14:22:22Z")
Thanks for the fast reply. Including the `"blocks": [...]` to the config almost worked. It's started to show the annotations and the sessions that agreed to that annotation. However, the sessions that disagreed with some annotation appears as a different sentence. What I mean is that disagreeing annotations appears as different annotations to review and they will be duplicated in the final dataset. A more complicated workaround that worked for me was to export (db-out) the original dataset to jsonl format, replace each occurrence of `"_view_id":"blocks"` to `"_view_id":"ner_manual"` and import (db-in) as a new dataset. Then I started the review recipe in this new dataset. ---
**Author:** ![ines](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/ines/32/3_2.png) [@ines](https://support.prodi.gy/u/ines)\ **Post date:** [February 6, 2020, 1:00pm UTC](https://support.prodi.gy/t/review-recipe-with-blocks-interface/2501/4 "2020-02-06T13:00:33Z")
Glad you got it working! > [@oshiro](#): > > However, the sessions that disagreed with some annotation appears as a different sentence. What I mean is that disagreeing annotations appears as different annotations to review and they will be duplicated in the final dataset. Ahh, I think I know what happened here: the `review` recipe uses a somewhat complex logic to determine whether annotations are answering the same question, and whether they're disagreements, based on the view ID. For instance, if you're using the binary `ner` interface, annotations are the same if they have the same task hash (same text _and_ suggested span) and they disagree if they have different `"answer"` values. For the `ner_manual` interface, annotations are the same if they have the same input hash (same text) and they disagree if they have different task hashes (different selected spans). Since the view ID here is `blocks`, Prodigy can't know that the annotation type is `ner_manual`, so it doesn't resolve the disagreements the same way. The option to override the view ID that I suggested above should also fix this, since it'd let you define how the annotations should be interpreted. I'll adjust this for the next release 🙂 ---
**Author:** ![kinghuang](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/kinghuang/32/1172_2.png) [@kinghuang](https://support.prodi.gy/u/kinghuang)\ **Post date:** [February 11, 2020, 10:21pm UTC](https://support.prodi.gy/t/review-recipe-with-blocks-interface/2501/5 "2020-02-11T22:21:03Z")
I just ran into this exact same situation. My variant of `ner_manual` uses blocks, and the `review` recipe doesn't work as is. Changing `"_view_id": "blocks"` to `"_view_id": "ner_manual"` in the dataset works. I am interested in using blocks in a custom review recipe to show related data. Not sure if that would impact this. ---
**Author:** ![ines](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/ines/32/3_2.png) [@ines](https://support.prodi.gy/u/ines)\ **Post date:** [February 21, 2020, 1:45pm UTC](https://support.prodi.gy/t/review-recipe-with-blocks-interface/2501/6 "2020-02-21T13:45:31Z")
Just released v1.9.7, which should now allow the `--view-id` argument to overwrite the interface used to display the tasks 🙂 ---
**Author:** ![kinghuang](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/kinghuang/32/1172_2.png) [@kinghuang](https://support.prodi.gy/u/kinghuang)\ **Post date:** [February 28, 2020, 6:36pm UTC](https://support.prodi.gy/t/review-recipe-with-blocks-interface/2501/7 "2020-02-28T18:36:08Z")
@ines, we tried to use the new `--view-id` argument, yesterday. But, it seems to show cases where annotators provided different labels for the same text as separate items instead of together with the multiple results below. Doing the rename from `"_view_id": "blocks"` to `"_view_id": "ner_manual"` still works. But, leaving the dataset with `"_view_id": "blocks"` and setting `--view-id ner_manual` doesn't work correctly when there are different labels for the same text. ---
**Author:** ![kinghuang](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/kinghuang/32/1172_2.png) [@kinghuang](https://support.prodi.gy/u/kinghuang)\ **Post date:** [March 11, 2020, 3:16pm UTC](https://support.prodi.gy/t/review-recipe-with-blocks-interface/2501/8 "2020-03-11T15:16:15Z")
@ines, just a friendly ping about this! We're still having to do a search and replace from `"_view_id": "blocks"` to `"_view_id": "ner_manual"` because using the `--view-id` option leads to rows where the annotators don't agree being shown separately instead of together. ---
**Author:** ![ines](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/ines/32/3_2.png) [@ines](https://support.prodi.gy/u/ines)\ **Post date:** [March 14, 2020, 6:56pm UTC](https://support.prodi.gy/t/review-recipe-with-blocks-interface/2501/9 "2020-03-14T18:56:11Z")
Just released v1.9.8, which should now correctly use the custom view ID to determine how to combine examples 🙂 ---
**Author:** ![kinghuang](https://sea2.discourse-cdn.com/flex020/user_avatar/support.prodi.gy/kinghuang/32/1172_2.png) [@kinghuang](https://support.prodi.gy/u/kinghuang)\ **Post date:** [March 14, 2020, 8:17pm UTC](https://support.prodi.gy/t/review-recipe-with-blocks-interface/2501/10 "2020-03-14T20:17:58Z")
Awesome. Thanks, @ines!