[Auscope-geosciml] boo-boo in GeologicEvent [SEC=UNCLASSIFIED]
Stephen M Richard
smrtucson at gmail.com
Fri Oct 9 12:33:23 EDT 2009
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
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
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
Stephen M Richard wrote:
> Please see discussion of this on TWIKI at
> 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.
Stephen M. Richard
Section Chief, Geoinformatics
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701 USA
Office: (520) 209-4127
Reception: (520) 770-3500
FAX: (520) 770-3505
email: steve.richard at azgs.az.gov
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the GeoSciML