Arctos DB
Crazy ideas about waterbodies #7935
Replies: 9 comments 6 replies
-
|
For clarity: I still don't care what shape this takes, I just don't like arbitrary. "Has a wikipedia page" or "mentioned on some wikipedia list" or such seems usable to me, as long as that does whatever ya'll are trying to do I'm in.
Correct, and FWIW I think individual requests usually finds a way to be worthwhile anyway.
I think search terms adequately covers this, but also extends to eg a waterbody within the waterbody (bay in a lake, maybe) and probably some other stuff. Really deep dives are probably better handled spatially (#5597); trying to stretch this too far doesn't seem likely to work well. |
Beta Was this translation helpful? Give feedback.
-
|
Wondering if we might want to be less specific. There is more than one lake Erie.... https://www.getty.edu/vow/TGNServlet?english=Y&find=Lake+Erie&place=&page=1&nation= BUT this might be clear given the higher geography/coordinates associated with the locality. So perhaps "Lake Erie" should just be defined as a body of water surrounded by land that is called Lake Erie. I guess my point is that we can't have multiple Lake Erie's in the code table, but the term could be used inappropriately with the definition given above. Because we aren't associating these terms with spatial footprints, then we shouldn't provide definitions that would cause this problem. Sure, we can say that the definition tells you which lake Erie and if you have some other Lake Erie you can go fly a kite, but that seems less than ideal as well. Sorry to put this fly in the ointment. |
Beta Was this translation helpful? Give feedback.
-
I'd not like to see this die on the theoretical; I would assume that we could find a reasonable workaround when someone shows up with a compelling use case for a non-unique term. |
Beta Was this translation helpful? Give feedback.
-
It seems to me that the "description" and the "related waterbodies" would be sufficient to distinguish watery homonyms. I fully support this approach and think it would answer a host of questions DMNS and OGL have raised. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think I have a problem with this approach, either. |
Beta Was this translation helpful? Give feedback.
-
|
Excited to talk about this in the meeting on Friday everyone, I think a very simple pick list of waterbodies (with no associated shapes) will accomplish what we want. Geospatial complexity is only muddying what we are trying to accomplish, and those ideas and capabilities can be tackled at a later date (#5597). Here's a whack at a new definition: And table values would be as above:
|
Beta Was this translation helpful? Give feedback.
-
|
We seem to all be in agreement that we have adequate controls but flexibility if needed. Let's roll. |
Beta Was this translation helpful? Give feedback.
-
|
I do not believe that the idea presented above is crazy and I am disappointed that the answer now seems to be to return to our old higher geography code table that mashed up political boundaries and watery boundaries in single terms and makes more work for the Code Table Committee. I can imagine that this will not really solve the original problem - mapping Arctos to Darwin Core waterBody. I have always been bothered by the mashup of things in higher geography and how the community tries to use it in so many varied ways. A really radical solution would allow for recording types of geographic information that are consistent and make sense to both collection managers and potential users. There are more possibilities, but why not have a place for more than one type of geography? human geography (GADM) - useful for determining permit needs and sovereignty and for those interested in a political boundary. Map to DwC higher geography. hydrology - (IHO) - useful for determining whether something happened in or very near a body of water. Map to DwC waterBody. paleogeography– (ICS) – useful to understand biotic communities at earlier points in Earth’s history. Map to appropriate DwC GeologicalContext terms. Currently accomplished with a bunch of locality attributes, but still not appropriately mapped to DwC. None of these are mutually exclusive and any given location may have something entered in all three. We can use polygons and coordinates to provide this information, but that doesn't always reflect reality at the time of an event because the borders of all of these things change over time. Unless we can provide polygons with associated dates, we may be serving up bad information. Also, there are the borderline instances - a coordinate may fall on the land today and in the water tomorrow. Being able to assert that it was in the water at the time of the event seems pretty important. The paleo people have something to use – it might be made better or simpler, but at least they have a thing. Marine collections have nothing. Mashing the hydro geography in with human drawn lines did not allow for publishing DwC waterBody in the past, how it work now? |
Beta Was this translation helpful? Give feedback.
-
This is definitely still in flux. But we're working through things over here: https://docs.google.com/document/d/11H7RHM4vqDhTV3bD-42tnJoKkDhbIoQOfjvYtWdxtgM/edit?tab=t.0#heading=h.whuypydnou99 I think the problem with what is outlined above is that hydrology has higher geography, too. So is it fair that only the terrestrial part gets to be in HG? If I have a sample from out in the Gulf of Mexico, it should get to have Atlantic Ocean in it's HG. Unless we treat waterbody as a watery HG, i.e., Atlantic Ocean, Gulf of Mexico. |
Beta Was this translation helpful? Give feedback.
-
|
But we're having another geography meeting to work on this this month! You should come, @Jegelewicz |
Beta Was this translation helpful? Give feedback.
-
Is exactly what I am suggesting. |
Beta Was this translation helpful? Give feedback.
-
|
But also, why is everyone so hung up on higher geography? So what if there is nothing in higher geography? If you put Pacific Ocean in higher geography, GBIF is gonna ignore it because that isn't in GADM. |
Beta Was this translation helpful? Give feedback.
-
|
@Jegelewicz @DerekSikes We are having another Geography meeting in two weeks, we can discuss this there. Please fill out the scheduling poll: https://www.when2meet.com/?28208960-ZoteP |
Beta Was this translation helpful? Give feedback.
-
|
this sounds good to me! |
Beta Was this translation helpful? Give feedback.
-
|
GBIF discussion - gbif/vocabulary#145 |
Beta Was this translation helpful? Give feedback.
-
Hey folks. Starting this discussion so we can continue talking about waterbody outside of committee meetings without clogging up issues! Please read and comment!
Continuing from Arctos geography committee meeting on July 1st (and a discussion between Phyllis, Teresa, and myself yesterday) https://docs.google.com/document/d/1tVmulmkFzN7P_IliFkeiOvMfKTAB_CCzG55ZxX0NFMI/edit#heading=h.3jdyx487bg21
Inspiration: #7666
Relevant issues: https://github.com/ArctosDB/arctos/issues/7374
The issue of adding waterbody to Arctos has gone forward and the code table has been created. However, we have already reached a disagreement about the definition of the code table, and which terms should be added to the code table.
Per #7906, https://arctos.database.museum/info/ctDocumentation.cfm?table=ctwater_body was created. The original idea was to add terms from Marine Regions (of some specific subcategories of terms) that have shapes (but without actually adding the shapes) so that when someday we are able to add them the shapes to arctos, we can easily transition these locality attribute values to spatial data.
The Darwin core term waterbody does not have a strict definition and promotes the use of outside authorities to create a controlled vocabulary https://dwc.tdwg.org/list/#dwc_waterBody We decided to limit ourselves to IHO world seas (via Marine Regions). However, that placetype term list does not include the Pacific or the Atlantic Ocean. DMNS and OGL requested that we include in the definition room for exceptions to the definition that could be added after committee discussion. However, Dusty dislikes building in room for exceptions and terms that need discussion, understandably (https://github.com/ArctosDB/arctos/issues/7374#issuecomment-2207458370) because leaving room for gray area opens up room for more issues in the future.
However, I think it is possible that we are limiting ourselves too much to begin with. Dusty linked https://en.wikipedia.org/wiki/Lists_of_bodies_of_water, which got me thinking. The true need for waterbody is because DMNS and OGL want a field to textually describe the watery aspect of a record. We liked the idea that this could one day become a spatial component, but maybe this is unnecessary and creating too much confusion and limitations at the outset. In the simplest way, what we want is a field that acts as a system of tags for water bodies that are consistent (and ideally does not include an abundance of synonyms) so that our collections can easily search for and group records/localities by watery data. (field should ideally be controlled terms instead of free text to ideally keep up cleanliness). Thinking of waterbody as a textual description vs a stationary geospatial thing (which waterbodies truly are not) could simplify this issue. This could also help differentiate this field from higher geography if is purely textual from the start.
The idea that we are somehow going to find a resource that will have the waterbodies that everyone needs at any size is unreasonable. Already, we will likely end up requesting to add other placetypes from Marine Regions to the code table because DMNS and OGL have specimens from waterbodies (rivers, bays, lakes) that aren’t in IHO World Seas. Why don’t we choose an authority more like the Getty Thesaurus of Geographic Names., or the Wikipedia waterbody list, that don’t have linked spatial data (that we weren’t actually adding anyway). These include names that of course may be similar to Dusty’s birdbath, but we don’t have to bulk add every term (just the ones that we want right now, which DMNS and OGL can identify). Then users could go to the list and create an issue to request the addition of a term from these lists. If the requested term meets the definition (Which could just be that it must be on one of the lists), then it can get added without discussion.
A metadata term for Synonyms in the code table could help with searchability and indicating which waterbodies are related to each other without having to actually build a complicated hierarchy.
Yes, this is different to what we have been discussing, and may be radical, but I would love to continue discussion on this outside of the monthly meetings. Please please please let me know what you think/rip this apart! @dustymc @mkoo @happiah-madson @falco-rk @Jegelewicz @sharpphyl
Beta Was this translation helpful? Give feedback.
All reactions