Open knelson-farmbeltnorth opened 1 year ago
In addition, I'm inclined toward modelling GeoPolitical Context by value rather than by reference to a common list of contexts in the Catalog. These will primarily be used with Context Items where a centralized Catalog will not necessarily exist (in the canonical DTD listing), and the amount contexts will repeat seems insufficient to otherwise abstract into common instances.
@aferreyra what thoughts do you have on the above?
While I like 3166, I think it is insufficient for the resolution we need. GeoPoliticalContexts need to be a controlled vocabulary used by reference. The FAO ontology cross references a number of identifier systems including 3166. I'd suggest we take a subset of the ontology and flatten it into a reference file (then make it available by api). I feel 3166 is insufficient because there are ContextItems that apply only with certain states.
We used 3166 and Geonames in other applications. Geonames has multiple admin levels; 3166 has two, you just need the right part.
Thanks,
Andres
From: Stuart Rhea @.> Sent: Wednesday, April 12, 2023 9:01 AM To: ADAPT/Standard @.> Cc: Ferreyra Andres USRS @.>; Mention @.> Subject: Re: [ADAPT/Standard] Simplifying Geo Political Contexts (Issue #91)
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
While I like 3166, I think it is insufficient for the resolution we need. GeoPoliticalContexts need to be a controlled vocabulary used by reference. The FAO ontology cross references a number of identifier systems including 3166. I'd suggest we take a subset of the ontology and flatten it into a reference file (then make it available by api).
https://en.wikipedia.org/wiki/Geopolitical_ontology#:~:text=The%20FAO%20geopolitical%20ontology%20is%20an%20ontology%20developed,as%20countries%2C%20territories%2C%20regions%20and%20other%20similar%20areashttps://en.wikipedia.org/wiki/Geopolitical_ontology#:~:text=The%20FAO%20geopolitical%20ontology%20is%20an%20ontology%20developed,as%20countries%2C%20territories%2C%20regions%20and%20other%20similar%20areas.
— Reply to this email directly, view it on GitHubhttps://github.com/ADAPT/Standard/issues/91#issuecomment-1505331429, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACGW26HBMYBPHZDHSWPS3RTXA2YRDANCNFSM6AAAAAAVWWCRQ4. You are receiving this because you were mentioned.Message ID: @.**@.>>
Andres
This message may contain confidential information. If you are not the designated recipient, please notify the sender immediately, and delete the original and any copies. Any use of the message by you is prohibited.
Let's please be careful with what we do with ContextItem. That stuff is currently part of ASABE/ANSI US National Standard S632-1. Let's try to not divergen unnecessarily from something that was initially created to support ADAPT. If we DO have to diverge, the time is now, because we have a window of opportunity to get those changes into the ISO CD 7673-1, which is the international version of it.
@strhea @aferreyra We discussed this at length in yesterday's meeting. There was general agreement that my proposal of using 3166 exclusively will not work. After researching this in more detail, I'm inclined to revert more closely to the GPC as currently defined. However, there are a few things that still need discussion.
The FAO ontology as near as I can tell is defunct. I can find no link to it that works, nor any published replacement. I suggest we remove it from the list of acceptable vocabularies.
I'm not sure I understand the value of GPCLevel, and our limitation to 2 levels. While we may see limited likelihood of context specificity for, e.g., a US township, why limit our ability to model it? If we are using a controlled vocabulary, to the extent it is needed we should be able to determine its level from that vocabulary. I'm inclined to remove that level concept.
Lastly, I still believe that adding localized labels for geopolitical entities is extraneous information for ADAPT. These can also be referenced from the published sources.
Regarding alterations to ContextItem, some changes will be unavoidable as we work to harmonize it with the Representation system. Perhaps we need to think of it as a version 2.
@strhea and I had a follow-up meeting on this. We agreed that we should use a single ontology within ADAPT and GeoNames seems to be the most comprehensive option.
Looking at a Geonames entry for, e.g., California (https://sws.geonames.org/5332921), there is a hierarchy of codes that we could separate by a colon ("US:CA") to identify California by code and avoid any further Geo Political Context data in ADAPT.
However, within the Geonames ontology, the URI for California is "https://sws.geonames.org/5332921", and the US & CA codes do not appear in the formal ontology.
As such, my current recommendation would be to have a simple GeoPoltical Context class with 2 members to include both a formal URI for automated queries and a human-readable description. We would include this by value where-ever we wished to reference a GeoPoliticalContext:
"GeoPoliticalContext": { "GeoNamesURI": "https://sws.geonames.org/5332921", "Description": "California" }
I could be convinced to dispense with the description and simply use the URI as a string property as a substitute for the entire object.
@knelson-farmbeltnorth No qualms here, using a single ontology is simple and clean.
Glancing through the documentation and export readme, it appears that the geonameid
is the primary identifier that would be used with the geonames dataset or web service.
I would recommend adding the GeoName
to the GeoPoliticalContext attributes. I think there is still some limited benefit in including the GeoNamesUri
, as it aids discoverability without additional documentation.
"GeoPoliticalContext": {
"GeoNamesURI": "https://sws.geonames.org/5332921",
"GeoNameId": "5332921",
"Description": "California"
}
http://api.geonames.org/hierarchy?geonameId=5332921&username=adapt
We agreed in the 10 May 2023 meeting to format it as follows:
"GeoPoliticalContext": { "ISO3166-2Code": "US-CA", "GeoNamesId": "5332921", "Description": "California" }
ISO 3166-2 Code will be required, and GeoNamesId/Description will be optional in cases where a more granular geography is required than possible with 3166-2.
Child issue of #88 for discussion.
The Geo Political Context object is substantially simplified vs. its current specification/implementation.
I'm requiring an ISO3166-alpha 2 code for the country. This allows not only specification of EU alongside its member countries, but is a standard in wide usage. The FAO system listed as default in the C# code is a dead link.
Level 1 & 2 are free text entry, with optional URLs for context/validation. It is not reasonable to enforce any fixed enumeration on these levels where such may not exist.
I dropped the concepts of descriptions and language labels here. These are redundancies if they represent friendly names for the geopolitical entities. Users should reference from ISO3166 in their chosen language.