[Auscope-geosciml] boo-boo in GeologicEvent [SEC=UNCLASSIFIED]

[Oliver.Raymond at ga.gov.au]

Hi Steve,

Sorry for the delay.  I got sidetracked by geologic specimens, and getting my head around ISO DQ and oXygen xml editor problems.

1. Some pedantic xml pickiness in StratigraphicDateEstimate/quality.  DQ_ThematicAccuracy is abstract, so I think the quality element should look something like this?

  <quality>
    <DQ_QuantitativeAttributeAccuracy xmlns="http://www.isotc211.org/2005/gmd">
      <result>
        <DQ_QuantitativeResult>
          <valueUnit xlink:href="#link_to_standard_unit_description"/>
          <errorStatistic>2 sigma</errorStatistic>  <!-- Should put error statistic here instead of in <nameOfMeasure>?  -->
          <value>
            <Record xmlns="http://www.isotc211.org/2005/gco">
              <Measure uom="urn:ogc:def:uom:UCUM:Ma">20</Measure>
            </Record>
          </value>
        </DQ_QuantitativeResult>
      </result>
    </DQ_QuantitativeAttributeAccuracy>
  </quality>

2.  My vote is to go with StratigraphicDateEstimate, but with several comments:

    i)  GeologicTime schema needs to be upgraded from GML3.1 to 3.2
    ii)  Make sure there are no querying problems with this looong xpath:  GeologicUnit/geologicHistory/GeologicEvent/numericAgeDate/CGI_NumericAgeRange/reportingAge/StratigraphicDateEstimate/position/TM_Coordinate/coodinateValue
    iii)  We investigate remodelling StratigraphicDateEstimate so that it is a specialisation of TM_Coordinate, not TM_Instant.  This would better constrain it by avoiding the union options in TM_Instant/position/TM_Position (we don't need calendar and clock times in geology do we?). And, coincidentally, this would shorten the xpath by 2 elements.
    iv)   We state that the "Quality/../value/Record" element should be of type "Measure" for geological ages.
    v)   Quality/../frame and valueUnit look like they can be done by reference.
    vi)  We write scope notes for StratigraphicDateEstimate (what is meant by "status"?)

Cheers,
Ollie


-----Original Message-----
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric
Sent: Saturday, 10 October 2009 4:53 AM
To: steve.richard at azgs.az.gov; auscope-geosciml at lists.arcs.org.au
Subject: Re: [Auscope-geosciml] boo-boo in GeologicEvent [SEC=UNCLASSIFIED]

My vote is to go for the full thing IIF we can provide stored queries. If the query is bound to the serialisation , I'd rather have the simpler form than having to explain user they have to write 1 yard long xpath to filter by age.

Eric (who still has to write a stored query implementation strategy for WFS 1.1.0)


________________________________
De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Stephen M Richard
Envoyé : 9 octobre 2009 12:33
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] boo-boo in GeologicEvent [SEC=UNCLASSIFIED]
The silence has been resounding!
So, any opinions about whether to use the simpler, but home-brewed CGI_NumericAge or the existing, more complex StratigraphicDateEstimate for CGI_NumericAgeRange?

CGI_Numeric age provides simpler approach, but less inherited architecture for detailed linkages with metadata and GeologicTime elemetns for connection to geologic and observation foundation of age estimate.

StratigraphicDateEstimate is more complex, requires overlay of schematron or profile rules to really be interoperable, but allows much richer data content and linkage to GeologicTime model. May require GML 3.2....?

Votes?
steve


Stephen M Richard wrote:
Please see discussion of this on TWIKI at https://www.seegrid.csiro.au/twiki/bin/view/CGIModel/NumericAgeDate
steve



Simon Cox wrote:

Oh dear.

There appears to be a misunderstanding here, and I completely disagree with

the conclusion:





TM_Coordinate. BUT... there is a mandatory association with TM_CoordinateSystem

which involves defining a timescale based on clock and calendar. (See attached

picture to see the TM classes involved). Not very applicable to defining

the geological time frame.





TM_OrdinalReferenceSystem, TM_CoordinateSystem, TM_Clock and TM_Calendar

are the four different kinds of TM_ReferenceSystem.

I.e. they are alternatives - there is no dependency from TM_CoordinateSystem

to TM_Clock or TM_Calendar.



TM_CoordinateSystem is _exactly_ what you need to define the scale described

in the quote from the NAm Strat Code - i.e. an origin and a standard unit.



Perhaps missing is the ability to say 'positive backwards' but this would

be a minor extension to the ISO TM_CoordinateSystem class.



Simon







--

Stephen M. Richard

Section Chief, Geoinformatics

Arizona Geological Survey

416 W. Congress St., #100

Tucson, Arizona, 85701 USA



Phone:

Office: (520) 209-4127

Reception: (520) 770-3500

FAX: (520) 770-3505



email: steve.richard at azgs.az.gov<mailto:steve.richard at azgs.az.gov>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20091012/06f04465/attachment.htm>