Announcing the Universal Metadata Tool Beta

The extension is now able to add Taxon IDs and Comments as well

1 Like

I am having trouble adding the extension to chrome (Windows). When I am going to Load unpacked, it says:

*The “background.scripts” key cannot be used with manifest_version 3. *
Use the “background.service_worker” key instead.
Could not load manifest.

I am not too sure how to fix this - I tried changing the manifest.json from

},
“background”: {
“service_worker”: “background.js”,
“scripts”: [“background.js”]
},

to

},
“background”: {
“service_worker”: “service_worker.js”,
“scripts”: [“background.js”]
},

but that did not work either. Any thoughts?

Hm it’s interesting that this is actually causing it to fail? In Edge it throws the error but loads anyway. My other tester has been using Chrome and hasn’t had an issue. All you need to do is remove the scripts line though.

To be clear the reason both of these lines are present is because Firefox wants it as a script and Chrome/Edge want it as a service worker. In my testing both browsers throw errors about the one that doesn’t match and then run with the one that does. When I ship the real versions I’ll remove the nonmatching ones but for building it’s easier to keep it all the same.

I got it working - thanks! It’s already a huge help as it makes me actually want to annotate. Have you thought about adding the data-quality tab to it as well? I often want to click that the observation is not IDable any further, but don’t because of the time/labor it takes for each individual observation. Either way, thanks for making this extension!

2 Likes

I was just gonna do another call for additional feature requests; I added everything that was requested so far this week but I knew I was still missing something. I will have the data quality stuff up sometime tomorrow.

2 Likes

Installed and running… phenomenal! Actually makes annotating fun :sweat_smile:. Can-t wait to see how it evolves.

4 Likes

Okay this is implemented now, if you just remove the extension and delete the folder and follow the installation instructions from scratch you’ll have it. Don’t forget to export any configurations you want to keep first though.

3 Likes

Great, thanks!

1 Like

Would it be a bad idea to be able to “mirror” the value of another observation field of the same type? If the person using the extension is adding a “Nectar Plant” obs field to an observation that already has “Plant the organism was found on”, for example. They both have type of “taxon”, so it seems theoretically possible. But maybe a bad idea? And also maybe hard to do?

This is implemented.

Worth noting that the extension just does exactly what you tell it to do, so think carefully about how you implement these actions if you want to do more than one at a time. For instance, there are many fields used to record the host plant of a plant parasite. If you want to take Host, Host plant, Host plant species, Host plant identification, etc, and copy whichever one the user applied into Host Plant ID because that’s the one your data structure uses, you can make an action that checks all of them at once (very convenient!). However, what it is actually doing is just copying each of them in order, and skipping the ones that are blank. In a case where multiple fields are already filled out, it will copy each into Host Plant ID sequentially. If they’re all the same that doesn’t matter; if some of them are different, you’ll only end up copying whichever is the last action in your configuration.

Also note that this of course overwrites any existing value in your target field.

What’s the current official download link, still the one in the OP?

1 Like

That’s awesome!

1 Like

Yes, that link pulls the most recent version from GitHub so it should stay up to date as I continue developing.

1 Like

Great, thanks!

only export configurations that are “enabled”? I may only want to share some of my configurations. scared of editing json!

If the tool allows two redundant observation fields to become 1:1, it might make sense to add functionality to “lock” one of the redundant observation fields so it can’t be added to new observations. Once any projects using the locked field switch over, the locked observation field could be deleted. It seems like sometimes even the “owner” of the obs field might be open to dropping it but can’t control which projects and users have come to rely on it.

it’s difficult to normalize user defined meta data without offending some of the users who defined it. it seems like getting them to 1:1 and then locking one might be reasonable. it would give time for there to be push-back and inquiry while it’s locked.

if the tool is used for large scale setting of observation fields to ultimately clear redundancy, hopefully the “mute” functionality blocks notification of an observation field being added. I think maybe it does.

I sympathize with this impulse but all of that is outside of my control and I would be surprised if the iNat admins went for it

1 Like

It does.

1 Like

Wow! Thanks for all of the time you’ve put into this extension! I’m excited to use it!

Any chance you can make a short video tutorial?

1 Like

When I “Open this link” in the original post in Chrome, I see the following and no apparent download. Do I need to disable anything in my browser?

2 Likes