Record of email trail regarding the association between GeomorphologicUnit and GeologicUnit (called unitDescription)

---

In the INSPIRE Thematic cluster we have received a question about GeoSciML 4.0 as you see in blue color, my reply will be the red part can you confirm me interpretation? Question: Have anyone seen the new GeoSciML schemas version 4? I have one doubt about Geomorphologyscheme...Why the multiplicity of the relation: unitDescription is 0..1? is not valid 0..*? My replay: the Geomorphology Feature has a cardinality 0…1 because is a GeologicUnit container used to associate geologic properties to a landform and all the information relate to GeologicUnit are managed as GeologicFeature part. Otherwise if you use as ControlledConcept vocabulary (through the GeologicUnit.classifier -> ControlledConcept link) just a 1 link at time is feasible to use. I'm waiting your response to post my response as well.

Carlo Cipolloni - 27 Jan 2016

---

I think we may have made a mistake here. Can everyone please read below and let me know if you think we need to make a change to the model.

In v3.2, we used the generic “!GeologicFeature > relatedFeature” association to relate geomorphologic units to geological units. This association was 0..* I have been through the meeting notes for the past 2 years and there is no mention of why we made the new v4 “unitDescription” association only 0..1 .

The reasoning may have been that the “unitDescription” association is designed only to describe the material that comprises the Earth beneath a surface landform (eg, using GeomorphologicUnit > GeologicUnit > CompositionPart (0..*) > RockMaterial). For that purpose, a 0..1 “unitDescription” association is sufficient to describe multiple materials. However, if this is the reasoning, then why would we not have made the link directly from GeomorphologicUnit to CompositionPart?

Now in v4, if a user wants to describe that a landform overlies several lithostratigraphic units, then they have to use the generic “!GeologicFeature > relatedFeature” association. I can see that using different associations for links to geologic units may create confusion among users.

I think there are 3 options to clear up potential confusion:

1. We change the “unitDescription” association to point to “!CompositionPart” (0..*) to make it clear that the association is only for EarthMaterial descriptions, OR
2. We change the “unitDescription” association to 0..* to allow for associations to multiple geologic units, which can each have EarthMaterial descriptions, OR
3. We add a detailed scope note describing why we keep the v4 current model and how to use it for different situations (my personal least favourite).

Comments please?

OllieRaymond - 28 Jan 2016

---

In GeoSciML versions pre v4, EarthMaterial was always associated with some real world feature, such as a GeologicUnit, Borehole, Outcrop etc. If this is the case in v4 then is option 1 doable? Like you I abhor option 3 – it sounds like we made a mistake and are trying to explain it away. I’d suggest option 2.

Bruce Simons - 28 Jan 2016

---

> Now in v4, if a user wants to describe that a landform overlies several lithostratigraphic units, then they have to use the generic “GeologicFeature > relatedFeature” association. I can see that using different associations for links to geologic units may create confusion among users.

Or, it can create a generic GeologicUnit placeholder for the whole geomorphologic form with sub units (hierarchyLink) describing the many geologic units. Actually, see figure 29 in the spec document

relatedFeature is only available in Extension, which is not supported in INSPIRE

But we can still make this minor change if it’s just a cardinality thing.

Eric Boisvert - 28 Jan 2016

---

Eric, re “Or, it can create a generic GeologicUnit placeholder for the whole geomorphologic form with sub units (hierarchyLink) describing the many geologic units. Actually, see figure 29 in the spec document” - that’s an ugly solution if you have to create an artificial parent geologic unit just to enable delivery of multiple related units under a hierarchyLink.

Bruce, re “!EarthMaterial was always associated with some real world feature, such as a GeologicUnit” – option 1 would link GeomorphologicUnit (a real world feature) to CompositionPart > EarthMaterial, same as the pattern for GeologicUnit > CompositionPart > EarthMaterial

I think we can cross off Option 3 for the reasons that Bruce and Eric described.

OllieRaymond - 28 Jan 2016

---

> that’s an ugly solution if you have to create an artificial parent geologic unit just to enable delivery of multiple related units under a hierarchyLink

Well. I think we can consider the whole form as a single GeologicUnit (as a package of rock), so it’s not just an artificial geologic unit.

So – this leaves 1 and 2

2 is also my favorite solution, it a benign change in the model that we could probably do right now without going to the formal change request. (it’s also backward compatible, since 0..1 is a valid 0..*)

Eric Boisvert - 28 Jan 2016

---

Ok so we move to change the schema cardinality from 0..1 to 0..*; if this is the best solution I replay to forum that we fix the lack as soon in the schema online, is fine for you or want we take more time? Personally I'm also not remember why we put 0..1 with UnitDescription.

Carlo Cipolloni - 28 Jan 2016

---

I can do it in a few minutes, as soon as I have the “ok” from the chair

Eric Boisvert - 28 Jan 2016

---

Marcus : I hope there are no gotchas with what we are doing with 1ge services to gsml4 that we are doing right now? please give your opinion to Ollie and I.

Tim Duffy - 28 Jan 2016

---

I can't see any gotchas.

Marcus Sen - 28 Jan 2016

---

Hi GeoSciML SWG,

There have been discussions among some of us over the last day or so to fix a perceived problem in the Geomorphology model. The problem is outlined in the bottom of this email trail. In short, the proposal is to change the cardinality of the “unitDescription” association from 0..1 to 0..* (ie, #2 of the options outlined below) . It is a trivial change and is fully compatible with any existing schemas, services, and instance documents.

I will get Eric to make the change to the schema, uml, and spec document on Monday, assuming that no objections are received.

-- OllieRaymond - 29 Jan 2016