"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"

Mineral Occurrences data model - 2004

For recent developments in this modelling space, go to EarthResourceML

Contents

Related pages


Schema document

The Mineral Occurence feature type is defined in the schema document:
  • XmmlCVS:XMML/mineralOccurence.xsd

Example Instances

See Xmml:CVX/Examples/mineralOccurences

Mineral Occurence

Model

  • Structure of a Mineral Occurence feature:
    mineralOccurence.png

Explanation

Note the following features:

  1. the gml:name element is designed to record an externally assigned identifier, with its authority or "codeSpace". To support the requirements outline above, we use two names:
    • the first records an external identifier authorised by "http://www.ga.gov.au/minloc"
    • the second records an identifier with no explicit authority, so should be understood as being valid in the context of the service that generated the document
  2. the gml:id attribute is an internal identifier (generally opaque) for GML Objects. It is primarily used to support cross-references within the document, but may be used as a "fragment-identifier" for external identification of a node within the document
  3. two versions of the position are provided: using geographic and projected coordinates. The Coordinate Reference System (CRS) is explicitly identified through its EPSG code when applicable. The element names xmml:projLocation vs. xmml:geogLocation are used for convenience, rather than the standard gml:location: the name variation conveys no information in addition to the CRS.
  4. xmml:locationPrecision is a simple quantity.
  5. additional fields for state, country were added following discussions with NealEvans and GregEwers 29 Apr 2003
  6. additional fields for class and mineStatus were added following discussions with NealEvans and GregEwers 29 Apr 2003
  7. multiple xmml:reference elements are used, each in the form of a pointer to some other information source. In this example I suggest that these might URN's, but there are other identification schemas available
    • Note that although there is considerable overlap, a distinction is generally made between reference managers and library catalogues;
    • The structure of the objects accessed by these identifiers is not specified. The GML pattern also allows the target of the xlink to be dereferenced and serialised inline as complexContent of the xmml:reference element, if that is considered useful

Code Lists

Note that the values of locationMethod, ausState, country, commodity, depositType, class, mineStatus properties are all constrained to be selected from lists enumerated in the schema XmmlCVS:XMML/LUTmineral.xsd. For example, MineralOccurenceClassType is defined as follows:

  <simpleType name="MineralOccurenceClassType">
    <restriction base="string">
      <enumeration value="Underground Mine"/>
      <enumeration value="Surface Mine"/>
      <enumeration value="Prospect"/>
      <enumeration value="Report"/>
    </restriction>
  </simpleType>

Documentation of each definition can be included in the schema as shown in the following partial example:

  <complexType name="mineralDepositType">
    <simpleContent>
      <restriction base="gml:CodeType">
        <enumeration value="Mafic/ultramafic extrusive related">
          <annotation>
            <documentation>Cox and Singer 6A</documentation>
          </annotation>
        </enumeration>
        <enumeration value="Mafic/ultramafic intrusive related">
          <annotation>
            <documentation>Cox and Singer 1, 2A, 2B, 3, 5A, 5B, 7A, 7B, 8A, 8B, 8C, 8D, 9, 18E, 27C</documentation>
          </annotation>
        </enumeration>
        ...
        <attribute name="codeSpace" fixed="http://www.ga.gov.au/depositTypes"/>
      </restriction>
    </simpleContent>
  </complexType>

The advantage of specifying the lookup in the schema is that it allows schema validation of the values. The disadvantage is that this fixes the code-list and it is not easily extensible.

The alternative is to refer to a value using a URI. A service may then deliver the definition of the term. This method is infinitely extensible.

A middle way is illustrated in this case: state uses the more general gml:CodeType, which allows specification of the LUT at run time.

In the example above, the property state is substituted by the more narrowly defined ausState, which enforces a specific codeSpace as follows:

  <element name="ausState" type="xmml:ANZLICStateType" substitutionGroup="xmml:state"/>

  <complexType name="ANZLICStateType">
    <simpleContent>
      <restriction base="gml:CodeType">
        <enumeration value="ACT"/>
        <enumeration value="NSW"/>
        <enumeration value="NT"/>
        <enumeration value="QLD"/>
        <enumeration value="SA"/>
        <enumeration value="TAS"/>
        <enumeration value="VIC"/>
        <enumeration value="WA"/>
        <attribute name="codeSpace" fixed="http://www.anzlic.org.au/genlist/anzlic-state_territory.txt"/>
      </restriction>
    </simpleContent>
  </complexType>


MINLOC schema

Summary of requirements from GregEwers - 19 Jul 2001, 01 May 2003 with some questions/clarifications by SimonCox - 23 Apr 2003

The database schema for the State/NT and AGSO databases are all different, but the common thread to come out of a comparison of these databases is the need for each mineral occurrence to have some form of site identification, key location information (lat/long and/or AMG, accuracy of the location), the name of the deposit/occurrence, those commodities associated with it and references.

GGIPAC recommended to the CGGC (and they agreed) that, within the geoscience portal concept, it would be possible to access Commonwealth/State/NT databases on-line from a single site. They have agreed to the development an over arching table as the entry point for users with the name of the deposit/occurrence, key location information (lat/long and/or AMG, accuracy of location), associated commodities for all occurrences on a national basis, and an attempt to develop a standard classification for each occurrence.

The key fields therefore are:

SITE table

  • Site identifier
    - i.e. an opaque object identifier? yes, the identifier should be unique for each occurrence
  • Mineral occurrence name
    - the "familiar" name for this occurence? e.g. Granny Smith yes, but some databases have a field for a project or mining centre (which could contain a number of operating mines, deposits and prospects) and/or a synonym field where an alternate name for a deposit/occurrence can be stored (for example the preferred name Olympic Dam may have Roxby Downs as the synonym
    • some standards should be supplied in terms of how we handle synonyms or name changes
      - in GML the name element can carry a "codeSpace" attribute. This allows you to identify the authority for the name or term. The "authority" should be assumed to enforce its own rules regarding uniqueness, etc. It may also be convenient to datestamp the value of the codeSpace.
  • Commodity code
    • concatenated list of commodities preferably in order of importance
      - is a list of valids available? yes, a list of commodities and abbreviated codes for each agreed to by Geoscience Australia and the State/NT surveys is attached. Some States prefer full commodity names rather than codes - therefore suggest the full names be used since there is no uncertainty about their meaning. Although the listing is fairly stable, it will be added to as necessary by the States and GA with GA acting as the custodian. Also see the lookup tables.
  • Commodity name
    - why both code and name? see previous comment - use of the full name is preferable
    • concatenated list of commodity names preferably in order of importance
      - is a list of valids available? see above comments
  • Decimal Longitude
    • Positive for Eastern Hemisphere
  • Decimal Latitude
    • Negative for Southern Hemisphere
  • Easting
  • Northing
  • Location Method
    • to gauge accuracy - however, this field is not used by Tasmania, SA or by the WAMIN database in WA
  • Precision (in metres)
  • Refid
    • link to REFERENCE table - N.B. Presuming we do not need multiple sources e.g. a source for location and a source for attributes
  • Deposit Type
    • authority table to be developed with the States/NT for classifying deposits based on AGSO deposit type) List of agreed values attached with deposit type cross referenced to the Cox & Singer deposit models where possible for information. The use of deposit type is optional and for most occurrences is simply 'unassigned' because there is insufficient information to make a judgement
  • suggest that the State/Territory should be added. Values would be WA, SA, NSW, TAS, VIC, QLD, NT & ACT -- GregEwers - 01 May 2003
  • maybe also country

REFERENCE table

  • Refid
  • Title
  • Author (concatenated list of authors)
  • Published
  • Publisher/Source

Comments

  1. We either need to capture the datum or insist that only a single datum standard will be used. i.e ALL records are GDA94!
  2. If we need to store multiple sources then we should add a field to the REFERENCE table for siteid and remove the Refid from the SITES table.
    - or increase multiplicity of this field - easily done in XML
  3. The commodity values will be a concatenated list automatically generated from a COMMODITY table.
    - how long is this list? If it is short it can be implemented as an enumeration in XML, which allows schema validation. But if it is long &/or prone to frequent updates, then it might be better to maintain a separate dictionary or service and refer to these by URI, which requires processor validation instead. the commodity list has 218 values at this stage but is likely to grow slowly - probably less than 10 new values per year. Most deposits/occurrences have between one and five commodities although in rare cases this number may stretch to ten values. It may be better not to concatenate the list of commodities given that multiple commodities are commonly present
  4. The actual table structure for REFERENCES may need to have a one to many link to an AUTHOR table. But the schema may only reflect a concatenated list which is automatically generated from this table.

I will be liaising with the States/NT over the next few months to come up with a standard commodity table (both full names and codes) and a standard deposit type authority table.


Topic attachments
I Attachment Action Size Date Who Comment
MineralOccurence.pngpng MineralOccurence.png manage 20.6 K 08 Dec 2006 - 09:44 OliverRaymond Mineral Occurence Model 2004
Topic revision: r4 - 15 Oct 2010, UnknownUser
 

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