When thinking about this question, my mind goes to pedagogy and ways to cue the user into understanding the new data structure (and even data structures in general!)

That is: in addition to asking "how do minimize the amount of stuff people in the field have to think about", an interesting parallel question is "how can we offer (optional?) learning opportunities for people to understand how data works in CoMapeo?"

Part of the reason for suggesting this is that this taxonomy definitely introduces a learning curve! And it may also impact field teams who have to intuit what observations to create in order to set up a good entity causal chain. ("OK, first let me map the creek, so I can then map the contamination in the creek...")

See my comments in What & why and CoMapeo data model for more of me wrestling with instantiating entity types, for reference

Along the lines of my thought experiment in Tagging examples where I consider how a project to track biodiversity sensor deployment might fit in:

I do feel the mental model of the entity types are very bound to mapping degradation and negative impacts. "At this feature, there is an activity ongoing with specific incidents that are having an impact..."

It could be tricky or awkward to parse non-impact-monitoring workflows into that mental model. For example, for a biodiversity project (see my attempt to map to entity types in Tagging examples), you could just omit "impact"... but it does feel like I am forcing the things to be mapped into a schema that was designed for something else.

Also, what is superfluous or extraneous? Of the 50 (I am just making that up) categories, we might really only need 20. So it would be good to eliminate the other 30 that are just wasted space in the UI and introduce a margin of error.

Related to this, and I'm not sure if it's elsewhere in the taxonomy:

Some communities I have supported have found it to be helpful to have a question "Who should have access to this data?" with answers like community_only, public.

Could be good to have something similar in the taxonomy.

Thinking about two users that are using CoMapeo to track camera trap deployment, with "deployment", "replace batteries / SD card", "take camera away" categories.

For this,

• feature = name or description of the site e.g. "Pimba"
• activity = "biodiversity monitoring project in the Pimba locale"
• incident = deployment / maintenance observations, i.e. "I came here to replace the SD Card and batteries" or "Picked up the CT as we are done monitoring"

(Right?)

Could be interesting to add this as an example.

What happens if I make a mistake?

Like, I map something as an "Impact", but later realize it should be an "Activity".

How does that impact (no pun intended) the causal chain and relationships between existing entities, and observations about entities?

Ok, this confirms what I was speculating in "What & why" and "CoMapeo data model". Multiple observations, each associated with a single entity. (Assuming 1:1 relationship between category and observation)

I think that makes sense, but users might not like it, or adhere to that convention in practice. If I were doing field mapping for a whole bunch of places, I might say "eh I don't want to create 4 observations to instantiate the 4 entity types, let me just do one right now and worry about the rest later" (only to forget doing so.)

Here is where ODK Entities can be really good inspo.

There are similar workflows to either create Entities on ODK Central, or via a survey (to then be accessed by other surveys, or the same survey). And a bunch of additional workflows around verification, etc.

HOT's Field Tasking Manager is also very interesting to think about.

This is what I was concerned about in my last comment in "What & why"

If I am mapping a location for the first time and need to register multiple entities e.g.

• feature=creek
• incident=mining
• activity=hydraulic_pumping
• impact=sediment_in_water

Do I create four observations?

Or is marking an entity a select_multiple and there is a UX to annotate each entity, turn-by-turn, for a single observation?

Very persuasive writing in this section!

Really interesting.

I wonder how this could work in practice. Imaginary user story:

I am a monitor, and I have just stumbled across a previously unknown mining site along a creek, in an area that has not been mapped yet.

What do I do first? Create an Observation to instantiate the Feature (creek). Then create an Observation to instantiate the Activity (mining). Then ... (you get my drift)

Or would it be that I create a single Observation, and have the option to instantiate an Entity, Activity, Incident, and Impact (and the links between them) all at once?

A user-friendly GUI to customize the universal taxonomy seems like an important (but possibly complex) tool to build down the road.

Yes. I think this is the single biggest limitation of the CoMapeo data structure in practice, and in my view, the biggest motivation to go into the direction proposed by this document.

Just in the CIPDP territory mapping project, countless hours were spent by the mapping team and Tom to determine: "are these 10 observations about the same thing? Is it fair to combine them? But is that lossy insofar as the 'same thing' was sometimes mapped as a creek, other times as pollution, other times as an animal spotting?"

I'm not convinced. Most projects have high-level categories, and then can ask a follow-up select-one question to drill down into the specifics: "What kind of species is this"?

I know this is where the universal taxonomy is going, too, but just noting that this feels a bit like a false dilemma as the problem is solvable by using Details.

Just chiming in that this is not unique to CoMapeo data. Pretty much all of the other customizable data collections tools (ODK/Kobo, EpiCollect, Survey123) have the same issue.

Consider taking a look at ODK's Entities docs, too. They put a lot of thinking and effort into clarifying what Entities are (for them) as well.

I feel the boundaries between these two entity types are a bit murky, and semantically people might understand different things by them.

Someone might consider a mining operation to be an "Incident" and an "Activity" to be annotating a lesser ... activity taking place within the broader temporal or spatial context of the "Incident", e.g.

Incident: small-scale mining site on the Lawa river Activity: they just started hydraulic pumping on the mining site

Put otherwise, in this semantic model I am describing, an Activity is a child of an Incident.

But the definitions here make me think otherwise.