"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"


GeoSciML v3 Design Proposals

Also see



1. Rock vs UnconsolidatedMaterial

The following is a summary of a series of email discussions held during December 2007 by BruceSimons, SimonCox, EricBoisvert, OliverRaymond, BruceJohnson, JohnLaxton, SteveRichard and BoyanBrodaric.

Definitions:

Rock - A consolidated aggregate of one or more EarthMaterials, or a body of undifferentiated mineral matter, or of solid organic material [adapted from Jackson, 1997]. Includes polymineralic mineral aggregates such as granite, shale, schist, and monomineralic aggregates such as calcite limestone or marble. Excludes unconsolidated materials. Materials not classified as Rocks in this model include volcanic glass (inorganic fluid, non-crystalline) and coal (organic material).

UnconsolidatedMaterial - A CompoundMaterial that consists of particles that are not bound together to form a solid material. May occur either at the surface or at depth. May include sediment, mud, sand, soil, volcanic detritus etc. Cohesion of these materials forms a continuum with weakly consolidated rocks, and as such some UnconsolidatedMaterials may have a minor degree of cohesion (eg, a clay soil).

consolidationDegree - A property that specifies the degree to which an aggregation of EarthMaterial particles is a distinct solid material. Consolidation and induration are related concepts specified by this property. They define a continuum from poorly-cemented collections of particles to very hard rock. Induration is the degree to which a consolidated material is made hard, operationally determined by how difficult it is to break a piece of the material. Consolidated materials may have varying degrees of induration

The Issue:

When the EarthMaterial portion of the model was created, there was only one type of CompoundMaterial, Rock. Then, some bright soul realized that sediments (and other miscellaneous loose stuff) were also CompoundMaterials, but were certainly not rocks. Thus, UnconsolidatedMaterial was added. The model distinction was that UnconsolidatedMaterials had an additional attribute, consolidationDegree. At this point, life was good; the Geologists understood the difference between rocks and unconsolidated materials and the data modelers were happy that the two classes had different attributes.

Then, another bright soul said, "Wait a minute. What if I want to include information on the degree of consolidation of a rock? Shouldn't it also have a consolidationDegree attribute?" The geologists were still happy, 'cause they're used to dealing with uncertainty and incomplete data. But, the data modelers cry, "Foul. Can't have two classes w/ the exact same attributes because that causes ambiguity and kills interoperability." That's where we are today.

In GeoSciML 2.0 both "Rock" and "UnconsolidatedMaterial" have the same content model, including the property "ConsolidationDegree"

It is therefore possible to describe a "Rock" with a "consolidationDegree" of "Unconsolidated" and an "UnconsolidatedMaterial" with a consolidationDegree of "Consolidated". To avoid this problem during Testbed 3, scope notes were added to the consolidationDegree attributes to recommend ensuring appropriate consolidation vocabularies were used for each of the subclasses: (Scope notes: "For the 'Rock' class the consolidationDegree should be 'consolidated' or one of its sub categories. For the 'UnconsolidatedMaterial' class the consolidationDegree should be 'unconsolidated' or one of its sub categories.")

Considerations:

1.1 They are overlapping classes.

UnconsolidatedMaterial was created at the Concept Model (NADM-C1) level to handle typical pleistocene/recent/glacial units. Geologists working with these deposits and those working in older (consolidated) material form distinct groups. However, there are grey areas - some lower Pleistocene deposits are laterally extensive and form part of sequences extending down into the Tertiary and get treated as 'bedrock'. Most 'superficial' deposits will be unconsolidated, but by no means all as there are some highly consolidated Pleistocene tills and regolith duricrusts. Conversely there are many 'bedrock' deposits in the Tertiary (and older) which are poorly consolidated. Consolidation is therefore not a good basis for distinguishing superficial (surficial, regolith) deposits from bedrock. Although unconsolidated materials are often young, the difference between rocks and unconsolidated materials has nothing to do with geologic age or mechanism of formation. The difference is whether one samples the material with a rock hammer or with a shovel.

If we have a class called "Rock" and one called “UnconsolidatedMaterial” we have to have a way to ensure that these do not overlap in an way that is guaranteed to be inconsistent between data providers.

1.2 Providing more than one way to encode the information is not interoperable.

Since
  1. both classes have the same properties, one of which is “consolidationDegree”
b. there are no constraints on the value of the “consolidationDegree” property for each class, to ensure that the classes do not overlap

there is the potential for misclassification, which would mean that queries would fail when they shouldn”t.

That is, does the service use the “Rock” class for both consolidated and unconsolidated materials, use the “UnconsolidatedMaterial” class or use both? A surficial geologist will consider an indurated till as an UnconsolidatedMaterial that has a consolidatedDegree = “indurated” just because Till are normally considered as unconsolidated. Probably the same reasoning for a 'bedrock' geologist mapping a loose carboniferous sandstone will call it a “Rock” with consolidationDegree = “unconsolidated”.

1.3 Can the “Rock” and “UnconsolidatedMaterial” classes be combined into one class?

In the model at present they both have the same content model, so it is really questionable, from an analysis and design point of view, why they should be separate classes.

Maybe they do need to be merged but with a name that embraces both. Are geologists who are working with the regolith or surficial materials comfortable calling the unconsolidated material a rock? We have attempted many times to come up with a more inclusive word that would represent both classes, so far without success. Should it be CompoundMaterial? This will require determining how to deal with the “Fossil” CompoundMaterial subclass. Is not having a “Rock” class in the model acceptable?

1.4 Don't include classes in the release that might be removed later.

It is definitely a bad thing to include classes now with the possibility that they might be removed later. Deprecation is really hard - the versions of GML have demonstrated that. It's much easier to add than take away.

1.5 Will “geologists” be reading the XML document?

Geologists will not be editing XML documents. Software will. You can put whatever you want in the human interface, but the transfer encoding should be unambiguous.

What we call things in the model does matter in terms of getting acceptance and understanding (we've spent an awful lot of time along the way discussing just these sort of issues for this reason) but if the separation of rock and unconsolidated material is unhelpful maybe this should be an exception.

1.6 The information distinguishing these classes is usually stored as part of the lithology classification.

As the consolidation information is traditionally contained in the lithology classification system the current model takes information from one place and delivers it to three places. Given “lithology” is a ControlledConcept, isn't it redundant to specify a lithology, which can only be applied to an unconsolidated or consolidated material, not both, along with a class that makes the same distinction?

1.7 Move the consolidation degree to GeologicUnit.

It could be argued that consolidation degree is a property of a unit, pretty much like metamorphism and weathering (consolidation of the unit can change du to weathering). -- EricBoisvert - 2009-09-08

Solutions:

  1. Delete the consolidationDegree attribute from the Rock class.
  2. Define different values for the consolidationDegree attribute for each class.
  3. Delete both the “Rock” and “UnconsolidatedMaterial” classes and use CompoundMaterial.
  4. Combine the “Rock” and “UnconsolidatedMaterial” classes into a new class
  5. Move consolidationDegree to GeologicUnit

Issue Status

This issue was debated at the Uppsala meeting (see https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/Uppsala2008F2FMeetingNotes).

Changes tested in Testbed 3.1 and incorporated into GSML v2.0 were:

  1. UnconsolidatedMaterial and Rock merged into one class called RockMaterial. (Scope notes: "A specialized CompoundMaterial that includes consolidated and unconsolidated materials as well as mixtures of consolidated and unconsolidated materials.").
  2. CompoundMaterial class retained as per GeoSciML v2.0 release candidate 2.
Subsequent email discussion (12-14 August 2008) suggested that there may be CompoundMaterials that do not have consolidationDegree or lithology properties. For example, it may useful to model Groundwater as a CompoundMaterial, rather than an InorganicFluid? Although not totally convincing, the opportunity to specify CompoundMaterials that are not Rocks or UnconsolidatedMaterial in the conceptual model is probably worth retaining in v3. (-- BruceSimons - 14 Aug 2008 )

-- OliverRaymond - 12 Nov 2008

2. PhysicalProperty

The cardinality of the PhysicalDescription attributes ( density, magneticSusceptibility, permeability, porosity) to encode numeric values is (0..1). With the current model a user needs to choose whether to deliver the range values or the median values if they have both. Allowing multiple values (cardinality 0..*) would allow serving up both.

  1. Do we want to serve up multiple values for the PhysicalDescription attributes (density, magneticSusceptibility, permeability, porosity)?
  2. If so, is it required as part of GeoSciML 2?
In order to handle any possible data structure we're sacrificing interoperability - which is the point of it all! The alternative is to agree specific data structures for every type of PhysicalProperty - but there are potentially a huge number of different types of PhysicalProperty. The PhysicalProperty was seen as an imperfect and partial solution. The extent to which particular properties can be applied to GeologicUnits, as opposed to being the result of observations of GeologicUnits is something that needs to be considered in this context. -- OliverRaymond - 12 Nov 2008

Another issue arising from Australian use case to deliver rock properties WFS involves the delivery of physical properties that not just a simple number value. eg; magnetisation (or magnetic remanence) is a vector property defined by a magnitude and two angles (declination and inclination) or by 3 magnitudes (corresponding to components in 3 principal axis directions). In both instances, the coordinate reference frame would need to be defined.

To accomodate this and the huge array of potential physical rock properties, should we move to a more soft-typed solution for delivering PhysicalProperty? -- OliverRaymond - 2009-09-15

Issue Status

ISSUE PARTLY RESOLVED - Multiple cardinality of PhysicalDescription attributes tested by instance document in Testbed3.1 and incorporated into GeoSciML v2.0. However, there still remains the issue as to whether having CGI_Numeric (for a mean value) and CGI_NumericRange (for maximum and minimum values) is interoperable. See other issues with CGI_Value that need to be addressed in GeoSciML v3. -- OliverRaymond - 12 Nov 2008

3. Specifying Proportions in Component Relationships

The Issue

One of the Vocabulary Task Group submitted vocabularies included concepts for 'subequal' and 'equal proportions'. These are required to be able to specify logic such as:

"part of the definition of concept x is that it contains components y and z in roughly equal proportions"

In GeoSciML 2.1 CompositionPart, GeologicUnitPart and ConstituentPart all allow for specifying the proportion of the part with respect to the whole, but not with respect to other parts. GeologicRelation would allow creating a relationship between the parts, but does not allow specifying a proportion.

Solutions:

  1. Adding a 'proportion' attribute to GeologicRelation or to a specialized ComponentRelation. Possibly too clumsy to work.
  2. Adding an aggregation to each of the 'Part' classes. For the above example 'y' and 'z' would be ComponentParts of 'yz', each with proportion 'approximately 50%'. The ComponentPart 'yz' construction is probably not workable.
  3. Other ...
-- BruceSimons - 10 Jan 2008

Issue Status

Decision at Uppsala to defer discussion to GeoSciML v3 -- OliverRaymond - 12 Nov 2008

4. Material Relation and Earth Material vocabularies

The issue

The problem concerns compound Earth Material descriptions such as 'Metalimestone with bands of calcsilicate rock' - both in the way these are described and in the use of the resulting descriptions as part of an Earth Material vocabulary.

There are two ways of describing CompoundMaterials depending on whether you want to describe the relation between the two ConstituentParts or between the ConstituentPart and the CompoundMaterial. Both require creating a CompoundMaterial "Metalimestone with bands of calcsilicate rock" and two ConstituentParts "Metalimestone" and "calcsilicate".

  1. The MaterialRelation is between the two ConstituentParts. (ie Metalimestone provides the "framework" MaterialRelation::role and calcsilicate the "bands" MaterialRelation::role).
  2. The ConstituentPart::role for the Metalimestone is "framework (?)" and the ConstituentPart::role for the calcsilicate is "bands".
In the case of 'Metalimestone with bands of calcsilicate rock' we need to describe the relation between the ConstituentParts (option 1 above) but there is a problem when you want to add the resulting definitions to a vocabulary. We can describe a CompoundMaterial with two ConstituentParts and separately define a MaterialRelation between the two ConstituentParts. However when we come to add the definitions to the GeologicVocabulary we find that the GeologicEntity defining the ControlledConcept prototype must be either a featureEntity or a materialEntity. A CompoundMaterial is a materialEntity but a MaterialRelation is neither so can't be used to define a ControlledConcept and therefore can't be added to the GeologicVocabulary.

One option would be to extend the GeologicEntity union to include GeologicRelation, so that both the CompoundMaterial and MaterialRelation parts of the description could be distinct ControlledConcepts and added to an EarthMaterial vocabulary. However 'Metalimestone with bands of calcsilicate rock' is a single concept - it is not two separate concepts, one of a CompoundMaterial with two constituents and then another of the relation between the constituents.

A better solution to the problem would be to have an association from CompoundMaterial to MaterialRelation allowing MaterialRelation to become part of the CompoundMaterial description. This would enable an EarthMaterial such as 'Metalimestone with bands of calcsilicate rock' to be fully described as a CompoundMaterial and be a single ControlledConcept. This approach would not require the extension of GeologicEntity to include GeologicRelation. -- JohnLaxton - 25 Jan 2008

See also more recent discussion thread at: MaterialRelationAndConstituentPartDiscussion

Issue Status

BGS tested a vocabulary with complex EarthMaterials in Testbed3.1. Discussions via teleconference on 5 Nov 2008 suggested using MaterialRelation to relate multiple constituent parts of RockMaterials (like limestone with calcsilicate bands), and not to include the MaterialRelation as a member in the dictionary. Further discussions resulted in MaterialRelation not being included in the GeoSciML v2 release. -- OliverRaymond - 10 Dec 2008

5. estimatedProperty stereotype

Issue

While we have estimatedProperty stereotype in the model, this stereotype does not materialise in any form in the GeoSciML schema. I shall remind you that this stereotype was supposed to provide a link back from a property to its observational basis.

Solution

What I found back on the twiki on QualifiedAssociation was that we should create a specialisation of gml:AssociationAttributeGroup that provide attributes to link back to Observation collections. -- EricBoisvert - 05 Feb 2008

Anyone disagree with this? -- BruceSimons - 12 Feb 2008

Issue Status

No decision yet. To be discussed for version 3. -- OliverRaymond - 12 Nov 2008

6. Geologic Age Data Model

Issue:

6.1 Data type for eventAge (CGI_TypedValue, CGI_TimeCoordinate, gml:timePosition)

(Summary of OliverRaymond, SteveRichard, SimonCox email discussion 12 Feb 2008)

GeoSciML v2.1 has eventAge with a data type CGI_Value. This has been encoded in the instance documents as:
<gsml:CGI_NumericValue>
          <gsml:principalValue uom="urn:ogc:def:uom:UCUM:Ma">450</gsml:principalValue>
</gsml:CGI_NumericValue>

However units of measure refer to an "amount" whereas a date is a "position". To express a time-position you need a frame or coordinate axis, not a unit of measure.

So Simon has asked what are the real semantics of event age?

(a) the position of the event (in which case we should correct the syntax and use gml:timePosition with the @frame attribute which points to a definition of a temporal reference system with a scale and datum), or

(b) the amount of time embodied in the object (in which case the use of a "measure" with just a unit of measure is correct)

If (a) then the eventAge should look like:
<gml:timePosition frame="ICSTimescale2004.xml">Ordovician</gml:timePosition>

OR

<gml:timePosition frame="tcs.xml#geologyMA">-450</gml:timePosition>

(gml:timePosition an implementation of ISO19108 TM_TemporalPosition)

Steve has proposed a third CGI_PrimitiveValue, CGI_TimeCoordinate.
<gsml:eventAge>
                <!-- any value may have a qualifier-->
                <!-- one value is required, any CGI_Value; TermValue included here as example -->
                <gsml:CGI_TimeCoordinateValue>
                    <gml:TM_Coordinate>
                        <gml:frame>
                            <gml:TM_CoordinateSystem>
                                <gml:interval>Million years</gml:interval>
                                <gml:origin>
                                    <gml:dateTime>1/1/1950</gml:dateTime>
                                </gml:origin>
                            </gml:TM_CoordinateSystem>
                        </gml:frame>
                        <gml:coordinateValue>56.9</gml:coordinateValue>
                    </gml:TM_Coordinate>
                </gsml:CGI_TimeCoordinateValue>
</gsml:eventAge>

Time ordinal eras could be represented through ScopedName pointers to Stratigraphic Era vocabulary from CGI_TermValue, or as in-line defined TM_OrdinalEra instances.

Simon wrote: "Trouble with making special cases (like CGI_TimeCoordinateValue) is where do you stop!? There could be one for every datatype, including spatial coordinates, etc. That's why I prefer a soft-typed container with strongly-typed contents. Otherwise we get an explosion of classes - IMHO GeoSciML is already too complex and prescriptive."

Alternatively, we could add a general CGI_TypedValue or (is this too general?).

-- BruceSimons - 13 Feb 2008

I agree with Simon that I don't think we need a special CGI_TimeCoordinateValue. The generic gml time values should suffice with reference to the GeoTime codespace. (Generic gml values also need to be considered for other uses in the review of CGI_Value.)

-- OliverRaymond - 12 Nov 2008

6.2 PreferredAge

Bruce would like to get rid of PreferredAge. Need to clarify the purpose and use of PreferredAge if we keep it.

Issue Status

To be discussed as part of version 3 -- OliverRaymond - 12 Nov 2008

7. Gml:identifier and upgrade to GML 3.2

GML 3.1 doesn't allow specifying a unique, document independent, identifier for any feature. As a work around, GeoSciML uses gml:name to capture this identifier. GeoSciML v2.0 should be upgraded to GML 3.2 to allow use of the gml:identifier for this purpose.

Issue Status

Need to implement GML3.2 upgrade in GeoSciML version 3. -- OliverRaymond - 12 Nov 2008

8. DeformationUnit definingStructure cardinality

GeoSciML v2.0 has each DeformationUnit may have only one definingStructure. Should this be 1..* to allow multiple defining structures (eg multiple Foliations)? -- BruceSimons - 20 Jun 2008

Issue Status

To be discussed for version 3.0 -- OliverRaymond - 12 Nov 2008

9. CGI_Value

Issue

See email discussion at CGIValueDiscussion (1-2 September 2009)

Issue Status

To be resolved at Quebec. -- OliverRaymond - 12 Nov 2008

10. Null Values

Issue

Need a more consistent/uniform approach to nulls. The issue is that we handle nulls in two different ways:

  1. with a 'null' value in the element content;
  2. with a 'null' value on an xlink:href.
In GML and INSPIRE there is also a third approach: mark an element 'nillable' and add a 'nilReason' attribute to hold the null value.

-- SimonCox - 1 Sep 2009
    • this is also related to the CGI_Value issue

Issue Status

To be discussed for GeoSciML version 3.0 -- OliverRaymond - 13 Sep 2009

11. Rationalisation of properties on some feature types

Issue

Cull some properties on most feature-types -- SimonCox - 25 Jun 2008

My general sense is that in places GeoSciML is more of a wish-list than an authentic model of what data is actually collected and thus potentially available from services. To a certain extent this is a reflection of the ambition of the MDA goal of making GeoSciML a true conceptual model, rather than just a logical model. But somehow we should deal more honestly with those properties that are never really implemented.

I used to advocate using the 'voidable' trick, but that led to datasets with lots of empty elements which seemed to offend some people. The solution adopted was to make them optional (minOccurs='0'), but that seems the wrong mechanism to me - either the properties should be there, or they shouldn't.

Better would be to remove, from the XML Schema at least, any property on any feature-type that is not illustrated by a sample dataset published in the 'examples' directory in the distribution, This might be achieved by marking them in the model with a suitable stereotype
(<<conceptual>>)
so the encoder doesn't process them (for now).

-- SimonCox - 2009-08-12

Issue Status

Specific examples needed here please Simon? -- OliverRaymond - 12 Nov 2008

12. Make EarthMaterial a FeatureType

-- SimonCox - 25 Jun 2008

Issue Status

To be discussed for GeoSciML version 3.0 -- OliverRaymond - 12 Nov 2008

13. Package organisation and namespaces for GeoSciML v3.0

Issue

Refactor the schema into multiple separately governed packages, with separate XML namespaces, e.g.
    • MappedFeature + GeologicFeature + GeologicUnit + GeologicStructure
    • Observation + Specimen + Outcrop
    • Borehole
    • GeologicMaterial
    • ControlledConcept
-- SimonCox - 25 Jun 2008

AFAICT the only scalable approach is a separate trunk/tags/branches for each separately governed package.

In future, a 'GeoSciML' release might be a stub schema that merely imports specific versions of all the subsidiary packages. It will be a package in its own right, of course.

Simon Cox 12 May 2009

Issue Status

To be discussed for GeoSciML version 3.0 -- OliverRaymond - 12 Nov 2008

14. ControlledConcept vocabularies in SKOS

Issue

Recode ControlledConcept and GeologicVocabulary using SKOS

SKOS/RDF supports almost all of the requirements for gml:Definition and gsml:ControlledConcept.

See discussion here: SKOSEncodingForVocabulary and examples here: https://www.seegrid.csiro.au/subversion/GeoSciML/trunk/vocabularies/

-- SimonCox - 03 Aug 2008

The data model discussion should include time to determine if we're going to deprecate GeologicVocabulary and adopt SKOS for vocabulary encoding; if so, how we want to use SKOS (any extensions like prototype as per Simon Cox's suggestion). -- SteveRichard - 2009-08-08

Moving to a SKOS implementation does not imply any need to deprecate GeologicVocabulary - its just that we use a different implementing rule (UML-XML) from that used for other parts of GeoSciML.. AFAICT the model is fine, its just that we are proposing to implement it using a more appropriate technology. -- SimonCox - 2009-09-04

Issue Status

To be discussed for GeoSciML version 3.0 -- OliverRaymond - 12 Nov 2008

15. InLine or byReference?

Issue

The MappedFeature specification tagged value inlineOrByReference is tagged as byReference. This is not what we've done for Testbed 3. Should the tagged value be removed from the UML model or should it stay there and be implemented properly in future? -- BruceSimons - 07 Jul 2008

See also https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/GeologicVocabulary?skin=clean.nat%2cpattern#Prototypes_byReference_or_inLine for discussion of inLineOrByReference for Prototype for GeoSciML Version 2.0.

(See also related ServiceArchitectureTG Item #20. How are users to know how to format a filter query if properties are tagged as inlineOrByReference? Which one do they query?)

Issue Status

MappedFeature/specification changed to inLine or byReference at Uppsala. The broader issue of inLine or byReference values needs be discussed for GeoSciML version 3.0 - what data goes inLine, what data is byReference. -- OliverRaymond - 12 Nov 2008

16. gsml:Map

Issue

Following up on the discussion we started about samplingFrame. Would it be useful to have a gsml:Map as a subtype of GSML. The metadata is already providing (I suspect) all the stuff to identify the map. I would only add a

    • legend->[0..*] ControlledConcept
property (others ?) to bundle all the ControlledConcept in a single list (to be pointed to by MappedFeatures) although it's not strictly necessary. We also need to make gsml:GSML able to contain other gsml:GSML - or add

    • collection->[0..*] gsml:GSML
in to GSMLItem union. Just so we can handle a collection of maps.

-- EricBoisvert - 8 Nov 2008

It is important in terms of how GeoSciML services might be used. Is a complete 'map package' service the way to go, or should the client request the desired features (contacts, faults, geologic unit mapped features, structure observations) in a more granular way?

-- SteveRichard - 10 Nov 2008

We are currently testing EarthResourceML where each feature is delivered as a separate service and it's up to the client to pull together the features of interest rather than deliver large XML documents. The two approaches should be looked at as part of GeoSciML v3.

-- BruceSimons - 11 Nov 2008

Issue Status

To be discussed as part of GeoSciML v3 Service Architecture discussions (see https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/ServiceArchitectureTG#Architecture_issues_to_be_addres) -- OliverRaymond - 12 Nov 2008

17. CompositionCategory

Issue

Can GeoSciML adequately - and interoperably - deliver the myriad of geochemical igneous classifications? e.g.
    1. acid, basic
    2. I-, S-, A-type
    3. ilmenite-, magnetite series
    4. fractionated, unfractionated
    5. calc-alkaline, tholeiitic, shoshonitic
Currently we have to put all these classifiers under CompositionCategory with a different codespace for each classification (is that really interoperable?). Do we need some more specific attributes to cover chemical compostion, like we have done for metamorphism, weathering and particle geometry. -- OliverRaymond - 12 Nov 2008

UPDATE...

1. GeologicUnit/CompositionCategory cardinality

The cardinality of composition category is 0..1 on geologic units and 0..* on earth materials. Why? This is inconsistent, and limiting for geologic units which are often mixtures of earth materials and are likely to be more variable in composition.

Proposal #1: change cardinality of GeologicUnit/CompositionCategory to 0..*

2. GeologicUnit/CompositionCategory

The CompositionCategory attribute tries to deliver different sorts of compositional data in a single attribute. We need to redesign the CompositionCategory element so that the different kinds of compositional data can be delivered in more explicit and easily parsed forms.

Proposal #2: Redesign the CompositionCategory attribute into a class with soft-typed compositional types

eg - CompositionType (a codeList) - Value (a TermValue or ScopeName)

A possible CompositionType codeList:

  • GenericChemical
  • GenericMineralogy
  • SedimentaryPetrography
  • IgneousSiO2
  • IgneousK2O
  • IgneousAl2O3
  • IgneousAlkali
  • IgneousFractionation
  • IgneousRedox
  • IgneousGraniteType
3. GeologicUnit/CompositionCategory vocabulary

With its 75 categories of composition based on various chemical and mineralogical schemes, the current vocabulary goes beyond the original scope of CompositionCategory - “Term to specify the gross chemical character of geologic unit.” We have tried to turn CompositionCategory into an element to deliver different kinds of chemical and mineralogical classifications, and its simple attribute structure cannot cope.

The vocabulary contains several non-exclusive composition category concepts - chemical (including specific igneous classifiers and more generic classifiers), mineralogical, and sedimentary petrolographic. In a WFS service, a user could not tell which of these classification systems is being used because several different classification systems are included within this one vocabulary codespace. This also potentially leads to mixed types of compositional data being delivered in a WFS within a single GeoSciML element.

Proposal #3: Separate the different compositional concepts into separate vocabularies.

-- OliverRaymond - 14 Sep 2009

Issue Status

To be discussed as part of GeoSciML v3 -- OliverRaymond - 14 Sep 2009

18. Alteration properties

Issue

Want to investigate if the model adequately handles description of hydrothermal alteration. e.g, description of alteration zone assemblages (similar to metamorphic facies/grade for which we have created a MetamorphicDescription class), textures, overprints etc -- OliverRaymond

Issue Status

A use case has emerged from the mineral resources community to deliver alteration attributes associated with mineral deposits. -- OliverRaymond - 21 Sep 2009

19. Properties of Regolith Landform units and materials

Issue

Tying to interest the GA regolith mapping team in contributing here (after all, Australia is 80% covered in sand). -- OliverRaymond - 12 Nov 2008

Issue Status

Probably leave this one for the SOTERML group -- OliverRaymond - 13 Sep 2009

20. ConstituentPart, MaterialRelation, CompoundMaterial and ParticleGeometry

Issue

Considerable discussion on this point about confusion as to the implementation of this part of the model. See: MaterialRelationAndConstituentPartDiscussion -- OliverRaymond - 10 Dec 2008

Issue Status

Unresolved. The use of ConstituentPart and its associated classes needs clarification and/or simplification before release in v3. -- OliverRaymond - 10 Dec 2008

21. PlanarOrientation, LinearOrientation

Issue

Noticed in Christian's instance document TB3.1_UC2C_BRGM_MappedFeature_Structure.xml that for planarOrientation he gives the mandatory properties of convention and polarity but neither of the optional properties of azimuth or dip. I think this raises a question about the model (for v3 not v2!) in that it seems incorrect that you must record the basis for making a structural observation but not the actual observation. Should not azimuth and dip also be mandatory? An equivalent argument will apply to CGI_LinearOrientation. -- JohnLaxton - 5 Dec 2008

Clearly a version 3 issue, but for the record both are optional as sometimes only one is known, and it could be either the dip or the azimuth (its shallowly dipping or flat and I therefore don't know the azimuth, or its striking this way but I don't know the dip). The convention and polarity are mandatory because if you have a measurement you must provide the context in which it is taken. -- BruceSimons - 7 Dec 2008

Possibly one of those cases where "unknown" might be better than "optional". -- SimonCox - 7 Dec 2008

The "convention" and "polarity" attributes were both changed to non-mandatory attributes at the Uppsalla meeting because they were inconsistent with having non-mandatory "azimuth" and "inclination" attributes. So, now if you wish to describe a GeologicStucture for which you have no orientation information, you can do so without having to encode "convention" and "polarity".

However, "convention" and "polarity" should be mandatory if either "azimuth" or "inclination" are populated. Is it possible to include this constraint in the schema? -- OliverRaymond - 10 Feb 2009

Issue Status

Constraint needs to be added to the model? - "convention" and "polarity" are mandatory if either "azimuth" or "inclination" are populated. -- OliverRaymond - 10 Feb 2009

swe:Vector vs CGI_Vector

swe:Vector could be used to replace CGI_Vector

  • Using swe:Vector to capture CGI_LinearOrientation and CGI_Vector properties:
    CGI_Vector_V3.jpg

22. Codespace URNs for unique feature IDs

Issue

We recently changed the codeSpace attribute values for scoped names with urn values from 'urn:ietf:rfc:2141' to: - 'http://www.cgi-iugs.org/uri' for URNs registered with the CGI Identifier Registry; and - 'http://urn.opengis.net' for URNs registered with the OGC URN Registry

Following this logic, should the codeSpace for gml:name values that hold the UUID for the feature (while we wait for gml:identifier) be the resource location of the (or a) service serving the feature in the first place? We've not registered them anywhere else. For example:

<gsml:GeologicUnit gml:id="gu.26931319"> 
    ... 
    <gml:name codeSpace="http://www.gsv-tb.dpi.vic.gov.au/geosciml-testbed3/tb3.1/wfs">urn:cgi:feature:GSV:TestBedUID:26931319</gml:name>
   ... 
</gsml:GeologicUnit> 

Have I got this right? -- AlistairRitchie- 10 Feb 2009

My understanding was that codeSpace is to represent the authority that creates/maintains those UUID, and not a pointer to a service that generates them. In fact, two or more different services might generate the same feature. But you have a point. Given the structure of the uuid itself, the codeSpace is almost redundant, you can already tell from the uuid who is the authority. What I expected from the codeSpace, from a client application perspective, is a flag that would tell me how I can resolve this uuid (where's the resolver ?). Putting the service that can resolve the uuid would do the trick, but wouldn't this create multiple behaviors depending of the codeSpace content ?.

hmmm.. this brings me back to the resolution mechanism that is still murky (not sure I got the right term here for 'trouble') for me.

-- EricBoisvert - 2009-08-12

Extract from http://www.isotc211.org/2005/gml/basicTypes.xsd - "gml:CodeType is a generalized type to be used for a term, keyword or name. It adds a XML attribute codeSpace to a term, where the value of the codeSpace attribute (if present) shall indicate a dictionary, thesaurus, classification scheme, authority, or pattern for the term." This suggests that codeSpace is for indicating the location of a vocabulary (eg: ICS Strat Chart) or authority (eg: Geological Survey of Canada), not the location of a urn resolver (eg: http://urn.opengis.net). -- OliverRaymond - 2009-08-13

So we are resolved to resolve the unresolved resolver issu in Quebec. -- EricBoisvert - 2009-08-13

Comment from Marcus

Item 1.3 - What to put in codeSpace attribute when values are URNs.

I'm still uncomfortable with the change we made from using urn:ietf:rfc:2141 in the codeSpace to a variety of values depending on which URN scheme we were using. It seems to me that the principle of URNs is to have a single globally unique identifier and that URN resolvers should be able to examine the characters of a URN to see whether it conforms to a scheme they have been configured to resolve or not. The codeSpace attribute exists so that terms from existing vocabularies that can't be guaranteed to be globally unique can be made globally unique by adding the globally unique URI codeSpace. (Analogously to namespace URIs being added to schema element and attribute names.) With a URN value we only need the codeSpace to tell us that the value is a URN as opposed to a value from some other space of terms. Specifying different codeSpace's for different URNs is redundant and potentially error-prone. What should we make of a case where two property values are identical URNs but have different codeSpace's? There has been some talk of putting a resolver location hint in the codeSpace (a bit more analogous to the xsi:schemaLocation hint) but there is no standard for this and it is at cross-purposes to the role of creating unique identifiers. So I would like to move back to just having one special codeSpace string to indicate that the value is a URN. An alternative would be to make an actual new Schema type to hold URN values just so things are clear but I offer no opinion on whether that would be more or less helpful.)

As a second point I would like to modify every occurrence of URN above to read URI (and I guess change 2141 to 3986.

-- EricBoisvert - 2009-09-24

Issue Status

Unresolved. The whole question of URN resolution to be discussed at Quebec -- OliverRaymond - 13 Aug 2009

23. Making better use of MD_Metadata in GeoSciML v3.0

Issue

Could better use be made of the ISO metadata elements in place of, or in addition to, some GeoSciML attributes? eg, observation methods, accuracy etc

Issue Status

To be discussed. Task group members are asked to raise specific examples. -- OliverRaymond - 11 Feb 2009

24. Verbosity/repetition of information in the MappedInterval model for boreholes

Issue

At BRGM, for GeoSciML 2, we agree for using mapped intervals for our boreholes. Mapped intervals will refer to geologic units described by their age and their lithologies encoded as composition parts. That means that we will have to inline all geological units in order to encode composition parts. It will not be possible to use a lithostratigraphic lexicon. As a consequence, in a collection of boreholes, we will have to duplicate many times the encoding of some geologic units (gml:name, gsml:observationMethod, gsml:preferredAge, gsml:geologicUnitType, ...) for encoding lithologies (gsml:CompositionPart). For instance, in a borehole, F010 geologic unit from 0 to 10 meters with non clastic siliceous sediment and again F010 geologic unit from 10 to 20 meters with sand and again F010 geologic unit in another borehole. I propose that in version 3 of GeoSciML we worked on a solution for minimizing the stream size of a collection of boreholes crossing geologic units described with lithologies

As soon as the new schema is ready, I will put on the twiki an example of a borehole crossing geologic units described without any lithology (because in this case we can refer to geologic units with xlink:href) and another one with lithologies.

As the way to encode geologic units crossed by boreholes is new, BRGM will have to modify its java code delivering boreholes within a WFS and its components decoding GeoSciML boreholes.

I agree with John. I think that after GeoSciML release 2, we will have to work on boreholes describing geologic structures or mixing geologic units and geologic structures, on boreholes using O&M

-- ChristianBellier - 19 Nov 2008

GSV intends to establish a GeologicUnit WFS and a Borehole WFS, with the aim being that the MappedIntervals will specify the GeologicUnit byReference, ie the URN of the specific GeologicUnit at the GeologicUnit WFS.

Are you suggesting that this is not possible in GeoSciML v2 and that the GeologicUnits must be in-line?

If the specific properties (lithology etc) of the GeologicUnit in the borehole are different to that of the GeologicUnit description then it is a different GeologicUnit, although it may be classified with the same name (StratigraphicLexicon). There was lots of debate about this back at the Ottawa meeting.

Alternatively the properties that are different to those in the GeologicUnit description need to be treated as observations. It is this latter aspect of being able to specify the GeologicUnit (byReference) and then include specific observations about its properties in-line that I'm concerned GeoSciML v2 may not allow. Is this possible?

-- BruceSimons - 19 Nov 2008

If you encode all your geologic units in your WFS, the way to refer them in the borehole WFS is by reference.

In our case, we will have a lithology (composition part of the geologic unit) for each interval, that means a different geologic unit for each interval. Many of these geologic units will be classified according to the same name (stratigraphic lexicon). For 2 geologic units sharing the same name but having a different lithology, we will have to encode twice the same observation method, the same preferred age, etc... There is no way to have a link to the basic geologic unit. It's the reason why geologic units will be inline. I agree with Ollie : it's something we will have to debate in version 3.

-- ChristianBellier - 19 Nov 2008

I don't really see the problem here. The stratigraphic lexicon can be referenced using the gsml:classifier and most of the other information in the MappedInterval specification is specific to that particular MappedInterval eg lithology. The only repetition that will occur is if there are several distinct lithologies encountered by a borehole for the the same GeologicUnit is the multiple recording of the (GeologicUnit) observationMethod and geologicUnitType. Or am I missing the point…..?

-- JohnLaxton - 24 Nov 2008

The problem, if it is one, is the size of the stream. You're right about the repetition. But, moreover, we will also have to repeat the observation method and the positional accuracy of the mapped feature which will be most of the time the same ones for all the intervals of all the boreholes. And when we have to connect more than one borehole (for sections, profiles, estimation, any calculation), the repetition of the geologic unit will often happen. We have this problem with geologic units because we must inline them as we specify lithologies.

-- ChristianBellier - 24 Nov 2008

I think this is a general point about the verbosity of GeoSciML rather than something specific to Boreholes. I think maybe there are still too many mandatory fields. I think the use of MD_Metadata (when we can use it) for a borehole or map will probably be the best way to remove some of this repetitive information at MappedFeature/GeologicUnit level. Something for v3 I guess.

-- JohnLaxton - 25 Nov 2008

Another solution to the verbosity/repetition issue is better normalization - i.e. make most of the properties "byReference" - so your description becomes primarily a set of xlink:hrefs.

-- SimonCox - 25 Nov 2008

Issue Status

Needs more discussion. See related discussion about MappedIntervals vs O&M sampling curves here: https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/BoreHolesAndObservationDiscussion?skin=clean.nat%2cpattern#Record_of_another_email_discussi

-- OliverRaymond - 11 Feb 2009

25. Update scope notes for ObservationMethod

Issue

Have we a clear statement anywhere of the distinction between the 'observation method' of a MappedFeature and the 'observation method' of the GeologicFeature specifying that MappedFeature? For geologic maps the instance docs generally have a term such as 'fieldObservation' for the MappedFeature observation method, and a term such as 'publishedInformation' for GeologicFeature observation method. The GeologicFeature in these cases is usually some type of norm. In the case of a Borehole the GeologicFeature specifying the MappedInterval will usually be an instance (as it carries specific observational information such as lithology) and so I assume both MappedInterval and GeologicFeature in this case should have the same observation method (probably something like coreLogging). Is this a rule - where the GeologicFeature is an instance it should have the same observation method as the MappedFeature it is specifying?

I'm not convinced that having observation method on both MappedFeature and GeologicFeature is adding an awful lot apart from confusion. Maybe something we should look at in v3?

-- JohnLaxton - 25 Nov 2008

John-- here's the text from the notes in the vocabularies:

Observation method is a convenience property that provides a quick and dirty approach to shortcut use of more comprehensive observation and measurement construct when data are reported using a feature view (as opposed to observation view). MappedFeature ObservationMethod is essentially a metadata snippet indicating how the spatial extent of the mapped feature was determined, and the basis for association of the geometry with some GeologicFeature specification to define a MappedFeature. Feature ObservationMethod specifies the approach to acquiring the collection of attribute value assignments that constitute an individual feature instance.

For a borehole, the MappedInterval observation method indicating how the boundaries of the interval were defined (eg, linear measurement from borehole collar), and GeologicFeature observation method would be concerned with how the geologic properties were determined (eg, visual observation, or standard AzGS logging procedure (described in detail somewhere else)?).

-- SteveRichard - 25 Nov 2008

Thanks Steve - that's really useful. Maybe something along these lines should be in the model scope notes?

-- JohnLaxton - 25 Nov 2008

26. Drop CompositionPart/lithology and only use RockMaterial/lithology?

Issue

I admit that back in Tucson I was one of those who campaigned for the CompositionPart/lithology element. However, after using the model in testbeds and 1G implementations, I now find myself in the somewhat embarrassing situation of thinking I was wrong and we never should have put “lithology” in 2 places in the model. Having “lithology” in 2 places is not interoperable.

How do others feel about dropping the CompositionPart/lithology element, and using only CompositionPart/material/RockMaterial/lithology?

-- OliverRaymond

There is also the issue of the circularity of a mandatory lithology property in a RockMaterial vocabulary description - which will be an xlink pointing to the RockMaterial description it is part of. As I recall we didn't originally have a lithology property as part of RockMaterial, which is why we introduced lithology as a property of CompositionPart to save having to provide a full RockMaterial description. I think the present circularity may be indicating a flaw in the logic of the way we have modelled RockMaterial (effectively we have lithology as a property of lithology) and I wonder whether we might not be better thinking of dropping lithology from RockMaterial rather than CompositionPart. If we provide a RockMaterial description then surely the gml:name of the RockMaterial identifies the lithology being described?

-- JohnLaxton - 2009-09-09

27. Boreholes

Issue

As already pointed out in previous issues, we need to provide some re-working of gsml:Borehole, with a better set of requirements as a starting point in order to make it useful for models.

Some of the requirements have already been raised:
  • Drilling methods - additional methods needed to be added to enumeration
  • Amend model to accept multiple drilling methods and diameters in one borehole
  • Links to ISO metadata elements for current sample location (also need this for outcrop samples - -- OliverRaymond)
I created a new use case page for the Auscope project with more details about the PIRSA mapping exercise: https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/AuscopeProject A copy of the mapping excel spreadsheet is available from this page.

Some more requirements will come very soon as we going further into the database mapping. I will provide more details and more material for discussion in the next days.

Another important point to discuss is the repository architecture for further development of the gsml:Borehole model as part of GeoSciML v3. A question that SimonCox raised is about the possibility of maintaining a different trunk/tags/branch repo structure for the Borehole model by its own. This will allow an easier parallel development of the different gsml:"Models". -- GuillaumeDuclaux - 05 May 2009

28. ControlledConcept vs ScopedName

Issue

See ControlledConceptvsScopedNameDiscussion

Issue Status

For solution at Quebec -- OliverRaymond - 2009-09-07

29. Fault Type

Issue

At present it is not possible to explicitly state the type of a fault (eg reverse, normal, thrust), rather this has to be done through the use of the movementType, movementSense and planeOrientation properties. This is problematic, in part because of the current values in the vocabularies supporting movementType, and movementSense, but more particularly because this approach is making the encoding of something simple (the fact a fault is reverse) complex. This complexity will result in inconsistent encoding and querying and thus reduce interoperability. A shearDispacementStructureType property is proposed for ShearDispacementStructure. See discussion at FaultTypeDiscussion.

Issue Status

For solution at Quebec -- JohnLaxton - 2009-09-09

30. Boulder frequency

Issue

At the Nordic GeoSciML workshop in January 2009 the question of how to record 'boulder frequency' arose. Tomas Lindberg provided the following explanation: 'There was some discussions on representation of boulder frequency on the ground surface. We have very simple classifications on the quaternary map (high boulder fequency, very high boulder frequency etc based on definitons on how many boulder of a certain size occur in an area), in practice estimated by field geologists in the field or in air photes). Theses simple cases may use outcropCharacter? There may be a need for more detailed or quantitative descriptions.'

-- JohnLaxton - 2009-09-09

Comment from Sweden: I think that for the current Swedish case of recording boulder frequency it could be a property of a geologic unit of different types (eg unconsolidated or consolidated lithology, geomorpholigic unit), and the way I read the current model outcropCharacter would be sufficient for us (if we create a relevant local vocabulary).

In our quaternary mapping lithologic units have a property 'boulder frequency' which describes the frequency of boulders on the ground surface (=outcrop?), not necessarily the boulder frequency of the whole body of the geologic unit since boulders often are 'accumulated' on the surface. Boulder frequency is classified into a number of classes (se examples below). In practice this is a rather fuzzy estimation done by the field geologist or in air-photo interpretation (boulders are not measured or counted except maybe once in a while for calibration, no quantitave information is captured).

Examples of (poorly translated) classification:
  • none or occasional occurance of boulders - 0 to 40 boulders/ha (10 000m2)
  • sparse occurance of boulders - 40 to 400 boulders/ha
  • moderate occurance of boulders - 400 to 3000 boulder/ha
  • abundant occurance of boulders - >3000 boulders/ha
Of course boulder frequency could be modelled in a more elaborate way. We may for example have clay recorded as having 'moderate occurance of boulders in the surface', where the boulders probably are protruding from an underlaying till which was never recorded, or some may have a need for recording boulder frequency for the whole body of an unsorted lithologic unit like till...these cases seems to be more related to describing the lithology or materials of tills.

Since we don´t have this need clearly expressed today I would settle for using outcropCharacter at this stage.

-- LarsStolen - 2009-09-15

Issue Status

For solution at Quebec -- JohnLaxton - 2009-09-09

31. Geologic Specimen

Issue

A record of email discussions of the proposal to add GeologicSpecimen to the model can be found at GeologicSpecimenDiscussion

-- OliverRaymond - 2009-09-18

Issue Status

For solution at Quebec -- OliverRaymond - 2009-09-18

32. Geochemical Analyses

Issue

See GeochemicalAnalysesDiscussion

-- OliverRaymond - 2009-09-18

Issue Status

For solution at Quebec -- OliverRaymond - 2009-09-18


RESOLVED ISSUES

Outcrop

Outcrop is usually a SamplingFeatureCollection, where more than one geologic feature is observed. Change derivation to specialize SamplingFeatureCollection -- OliverRaymond , SimonCox - 25 Jul 2008

ISSUE CLOSED - SamplingFeatureCollection tested by instance doc in Testbed3.1 and recommended practice for GeoSciML v2.0 -- OliverRaymond - 12 Nov 2008

CGI_Value:ValueQualifierCode

Add maximum/upper-bound minimum/lower-bound to the list. This can effectively replace the "upper" and "lower" roles on value ranges, and thus help with removing/simplifying the value-range model -- OliverRaymond , SimonCox - 25 Jul 2008. Not necessary - greaterThan/lessThan already there. -- SimonCox - 03 Aug 2008

ISSUE CLOSED - Other issues with CGI_Value to be addressed above -- OliverRaymond - 12 Nov 2008

GeologicFeatureRelation

Having both a sourceLink and a targetLink in GeologicFeatureRelation means that the GeologicRelation is duplicated, ie once for each GeologicFeature involved, with the sourceRole and targetRole swapped.

An alternative would be to have a single link to the GeologicRelation feature, which then contains the relationship, sourceRole, targetRole attributes as well as sourceFeature and targetFeature attributes that specify the GeologicFeatures involved in the relationship. Each relationship would then only appear once, and would allow serving a "GeologicFeatureRelation" view of the data. (ie here are all the GeologicFeatureRelations and the GeologicFeatures that participate in them.) -- BruceSimons - 19 Jun 2008

ISSUE CLOSED - Discussed at Uppsala and the v2.0 model was updated to make target-sourceLink association directional. -- OliverRaymond - 12 Nov 2008

GeologicUnit subtypes

GeoSciML v2.0 allows subtyping GeologicUnits (LithologicUnit; further subtyped into LithostratigraphicUnit and LithodemicUnit, ChronostratigraphicUnit, DeformationUnit). However, this is not the full list of possible sub-types, so either the subtyping needs to be expanded, or we take a different approach. As these unit types potentially share many (all?) attributes, and in the interest of minimising the number of classes we need to maintain, an alternative is to "type" the GeologicUnit and remove the sub-types.

Possible solutions:
  1. Add further sub-typing to GeologicUnit
  2. Delete all GeologicUnit subtypes and add 'type' attribute, along with optional subtype attributes, to GeologicUnit -- BruceSimons - 18 Jun 2008
ISSUE CLOSED - GeologicUnit subtypes dropped, and GeologicUnitType attribute and codelist adopted for GeoSciML version 2. -- OliverRaymond - 12 Nov 2008

The distinction between naming and classifying a feature

Do we have clear rules on the distinction between naming something and classifying something?

For example in Ollie's TB3.1_UC2A_GA_MappedFeature_GeologicUnit.xml he gives his GeologicUnits names which reference urns in the GA StratigraphicLexicon, but there is no classifier for the unit. The scope note for the GeologicUnit classifier says 'The classifier indicates the kind of thing a GeologicUnit instance is meant to represent. For example the GeologicUnit could be 'classified' by a ControlledConcept that is a name, such as 'Good Hope Formation', from a Stratigraphic Lexicon.' I think the distinction is that the name is what something is called whereas the classifier indicates what something is. But clearly if you call something 'Upper Chalk' then there is a presumption that it is 'Upper Chalk', so this is a pretty fine distinction.... My feeling is that we should always use the classifier where we are stating that something is a member of some class (eg a geological formation), and not simply rely on the name. Should the name be mandatory as well? I think we previously said it should, although in this circumstance it will reference the same thing as the classifier. -- JohnLaxton- 20 Nov 2008

The GeoSciML profile only has gml:name mandatory for the 'identifier' until we move to GML 3.2 and can use gml:identifier instead. The actual 'name' - 'Upper Chalk' - of the GeologicUnit is not mandatory. Where the name is coming from a ControlledConcept (a Stratigraphic Lexicon), such as Ollie's example, it should be the classifier. There is no reason however, why this name, along with any other names, could not also be delivered in the gml:name tag. -- BruceSimons - 21 Nov 2008

I agree with Bruce. Note that the TB3.1_UC2A_GA_MappedFeature_GeologicUnit.xml instance doc includes both gml:name (eg: Claraville beds) and gsml:classifier (gsml:classifier xlink:href="urn:cgi:classifier:GA:StratigraphicLexicon:Stratno:4090"). In this case, the classifier urn points to an as-yet-unregistered Stratigraphic Lexicon. -- OliverRaymond - 10 Feb 2009

See this page - GeologicFeatureClassifierDiscussion - for a further email thread (4-5 December 2010) which may suggest that this issue is not resolved after all. -- OliverRaymond - 9 Dec 2009

Recording whether boreholes are drilled up- or down-sequence

The National Virtual Core Library have asked the following question re GeoSciML:

“Peter W and I had a further look at GeoSciML ML schema in FulMoon yesterday and were pleased to find definitions of things like locations of bore hole collars, e.g. surface, underground, pit walls and floors etc. that we can be include in the NVCL definitions when the first version db goes live in the new year to support the Survey's use of their HyLoggers. This is great.

What I still cannot find and am still keen on capturing is the stratigraphic sense of a drill hole. I know we've discussed this before and I apologise if I have forgotten something, but are you aware that the concept of a hole being drilled up-dip or down-dip with respect to the stratigraphy is yet included in the bore-holes schema and if not how do we go about helping defining what we will need in the short term that can be picked up by GeoSciMl later ?

We have plenty of examples, e.g. a Teutonic Bore project that has two drill holes in the HyLogging db, both drilled from underground and one that goes downwards through stratigraphy from its starting point, and one that goes backwards through the stratigraphy. Currently I can find no way of describing this info nor a note in the GSWA's world that recognises it other than a written statement to that effect. At minimum I'd like to have an NVCL bore hole field that has entries such as: drilled up-dip, drilled down-dip or don' know. The implication are vital as it says that in comparing TSG outputs one of these holes output would at some stage need to be reversed to allow matching/comparison.”

Do any of those with borehole data indicate in their databases whether the hole is drilled up-dip or down-dip?

-- BruceSimons - 9 Dec 2008

I know this is quite verbose, but isn't this an equivalent of having a contact orientation of a unit?

GeologicUnit/sourceLink/BoundaryRelationship/boundaryOccurence/Contact/orientation/PlanarPolarityCode/overturned

-- EricBoisvert - 9 Dec 2008

Yes Eric, this is where I felt it would be collected, as an orientation on the contact. This also allows for complexly folded sequences if you have the facing information.

-- BruceSimons - 9 Dec 2008

This isn't something we record specifically, although a combination of borehole orientation/geometry and the stratigraphic sequence penetrated would give this information indirectly in most cases. I guess this problem arises if you don't have any stratigraphic classification for the borehole but do know the younging direction? What would happen though in areas of complex structure where younging direction gets changed down the borehole? I think we need to analyse the use-case here quite carefully before making any change to the model.

-- JohnLaxton - 9 Dec 2008

A pretty important issue here is what "up dip" and "down dip" means. In a hard-rock/mining context I get the impression that structural and stratigraphic terminology like "up dip" and "hanging wall" have meanings that are somewhat generalized compared with rigorous practice. It there is also a question of whether it is important to apply this classification a priori (which is my impression) i.e. in advance of actually logging the hole. I guess what I am getting at here is whether there is a "hard-rack/mining" parctice here which is somewhat independent of conventional mapping practice, and we should be cautious about trying to fit square pegs in round holes. If it requires a hard-rock extension to the borehole model to accommodate this, then so be it, in its own package and namespace

-- SimonCox - 9 Dec 2008

Thanks for all your responses, most appreciated. I wanted to check whether it was common practise to have this up-dip/down-dip concept. GSV does not include it and it seems to be unique to some parts of the exploration industry. I believe we can leave it out of version 3. I shall respond to the Virtual Core Library team accordingly.

-- BruceSimons - 9 Dec 2008

ISSUE CLOSED
Topic attachments
I Attachment Action Size Date Who Comment
CGI_Vector_V3.jpgjpg CGI_Vector_V3.jpg manage 29.1 K 31 May 2010 - 10:18 BruceSimons Using swe:Vector to capture CGI_LinearOrientation and CGI_Vector properties
Summary_diagram_geometric_values.jpgjpg Summary_diagram_geometric_values.jpg manage 52.7 K 31 May 2010 - 10:20 BruceSimons GeoSciML v2.1 geometric values
Topic revision: r62 - 27 Jun 2011, OliverRaymond
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).