[auscope-geosciml] estimatedProperty [SEC=UNCLASSIFIED]

Oliver.Raymond at ga.gov.au Oliver.Raymond at ga.gov.au
Sun Jun 19 21:33:48 EDT 2011


Hi Eric,



Given the timeframe that Simon has outlined for estimatedProperty at ISO, do you want to consider building an "estimatedProperty" link into the GeoSciML schemas in the meantime?



1. perhaps a byReference attribute on all estimatedProperties which links to a class like OM_Process?

2. or maybe a link to an OM_Observation, which gives access to the process and the result (I'd prefer an ObservationCollection because geological description are often based on many observations, but that doesn't exist any more in O&M - maybe that's a ComplexObservation?)

3. or maybe a link to a Sampling Collection?

4. or maybe a link to gmd:LI_Lineage?

5. or maybe the ultimate soft link to gml:Any, so the data custodian can decide what constitutes "evidence" and how to present it.



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 Simon.Cox at csiro.au
Sent: Monday, 20 June 2011 10:57 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] estimatedProperty [SEC=UNCLASSIFIED]



Sorry - don't know at this stage.

If GeoSciML has a preference which is not biased I would be happy to take it forward.



Simon



-----Original Message-----

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Oliver.Raymond at ga.gov.au

Sent: Monday, 20 June 2011 8:19 AM

To: auscope-geosciml at lists.arcs.org.au

Subject: Re: [auscope-geosciml] estimatedProperty [SEC=UNCLASSIFIED]



Hi Simon,



Do you have any feeling for what an "evidence" link might look like - gml:any? or something more specific? Maybe gmd:Lineage?



Cheers,

Ollie



_______________________________________________________________________



Ollie Raymond



Project Leader

National Geological Maps and Data Standards Project

Geoscience Australia



Interoperability Working Group

IUGS Commission for the Management and Application of Geoscience Information



Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039

Ph: +61 2 62499575  |  Fax: +61 2 62479992  |  Email: oliver.raymond at ga.gov.au  |  Google Map

_______________________________________________________________________



--- This message was created with 100% recycled electrons ---



-----Original Message-----

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon.Cox at csiro.au

Sent: Sunday, 19 June 2011 7:59 PM

To: auscope-geosciml at lists.arcs.org.au

Subject: Re: [auscope-geosciml] RE : RE : Quantity vs QuantityRange [SEC=UNCLASSIFIED]



Eric -



ISO 19109 "Rules for Application Schema" which includes the details of the General Feature Model, is in review.

I am on the project team.

My goals are to get some tweaks to the GFM through, in particular

(i) a description of how CV_Coverage relates to the feature model - primarily in the sense that some feature properties have varying properties in the scope of the feature. In effect, CV_Coverage has a formal relationship with GF_Operation.

(ii) to get a slot for O&M in the GFM - the expectation is that the association between the metaclasses GF_Feature and GF_Property (labelled 'carrierOfCharacteristics' will be changed into an AssociationClass with some attribute on the AssociationClass supporting a link to 'evidence'.

This then triggers an update to the GML encoding rule to allow links to evidence (Observations) when a property has a stereotype like <<estimatedProperty>>



The ISO 19109 Project Team has only had one meeting so far, so (a) the details are not fixed, and (b) it'll be a couple of years until this is close to finalization.

However, I presented both these ideas to general approval.

The formal update to the encoding rule would follow later of course.



So I think things are heading in the right direction.



Simon Cox

Research Scientist

CSIRO Earth Science & Resource Engineering



Phone: +61 8 6436 8639 | Fax: +61 8 6436 8555 | Mobile: 0403 302 672

simon.cox at csiro.au | www.csiro.au

Address: ARRC, PO Box 1130, Bentley, WA 6102, Australia

________________________________________

From: auscope-geosciml-bounces at lists.arcs.org.au [auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric [Eric.Boisvert at RNCan-NRCan.gc.ca]

Sent: Saturday, 18 June 2011 9:34 PM

To: auscope-geosciml at lists.arcs.org.au

Subject: [auscope-geosciml] RE :  RE :  Quantity vs QuantityRange [SEC=UNCLASSIFIED]



We need this <<estimatedProperty>> stereotype nailed.



My goal is to archive a complete groundwater assessment project into a single collection of GWML files.



eg: typical hydraulicConductivity of this geologic unit is xx, base of interpolated values of yyy mesured, compiled or totally invented values from a,b,c sources.





  _____



De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Simon.Cox at csiro.au

Date: sam. 2011-06-18 09:22

À: auscope-geosciml at lists.arcs.org.au

Objet : Re: [auscope-geosciml] RE : Quantity vs QuantityRange [SEC=UNCLASSIFIED]







You said it.



Simon Cox

Research Scientist

CSIRO Earth Science & Resource Engineering



Phone: +61 8 6436 8639 | Fax: +61 8 6436 8555 | Mobile: 0403 302 672

simon.cox at csiro.au | www.csiro.au

Address: ARRC, PO Box 1130, Bentley, WA 6102, Australia

________________________________________

From: auscope-geosciml-bounces at lists.arcs.org.au [auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric [Eric.Boisvert at RNCan-NRCan.gc.ca]

Sent: Saturday, 18 June 2011 9:15 PM

To: auscope-geosciml at lists.arcs.org.au

Subject: [auscope-geosciml] RE :  Quantity vs QuantityRange [SEC=UNCLASSIFIED]



> it is not for transfer of all musings from a field notebook.



And if we want to transfer musing from notebooks ?  O&M ?



  _____



De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Simon.Cox at csiro.au

Date: ven. 2011-06-17 23:29

À: auscope-geosciml at lists.arcs.org.au

Objet : Re: [auscope-geosciml] Quantity vs QuantityRange [SEC=UNCLASSIFIED]







I agree with Eric.

If SWE Common can do it, then we should get rid of CGI_Value etc.



However, I also think that we should still review all the class attributes and convert them to Measure and references to dictionary entries.

The primary goal of geosciml is data transfer for plotting and analysis, it is not for transfer of all musings from a field notebook.

It would be so much easier on clients to just collapse all the values to scalars.

Yes, this requires the data provider to make some decisions about what they tell the client.

Commitment is sometimes good and useful.





Simon Cox

Research Scientist

CSIRO Earth Science & Resource Engineering



Phone: +61 8 6436 8639 | Fax: +61 8 6436 8555 | Mobile: 0403 302 672

simon.cox at csiro.au | www.csiro.au

Address: ARRC, PO Box 1130, Bentley, WA 6102, Australia

________________________________________

From: auscope-geosciml-bounces at lists.arcs.org.au [auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric [Eric.Boisvert at RNCan-NRCan.gc.ca]

Sent: Friday, 17 June 2011 10:58 PM

To: auscope-geosciml at lists.arcs.org.au

Subject: Re: [auscope-geosciml] Quantity vs QuantityRange [SEC=UNCLASSIFIED]



>2) use CGI_TermRange in those cases where CGI_Term (1..*) is really meant to indicate a range (eg, for particle sorting and metamorphic facies?) rather than a set of random single values



A range should only have 2 terms right (assuming the terms are ordinal) ?



I already expressed my opinions about this.  Since GeoSciML imports O&M and O&M imports swe, we end up with 2 value representations that overlaps.

As far as terms are concerned, there are Category and CategoryRange that could replace CGI_Term and CGI_TermRange, and QuantityRange can replace CGI_NumericRange.



What's left are the specialised numerical representation (NumericalAgeRange and PlanarOrientation).

They could be simulated with swe:DataRecord.  Maybe it's a bit of a stretch ?



Eric



________________________________

De : auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Oliver.Raymond at ga.gov.au

Envoyé : 16 juin 2011 22:01

À : auscope-geosciml at lists.arcs.org.au

Objet : Re: [auscope-geosciml] Quantity vs QuantityRange [SEC=UNCLASSIFIED]



Hi Eric,



peakPressureValue and peakTemperatureValue must, by the nature of being a "peak" value, be only one number and not a range.  That one number may have an error associated with it.   There is a subtle difference between a range (2 numbers, upper and lower values, both of which may have errors - like NumericAge), and a single value number with an error.  The chemical assay is an example of a single number (swe:quantity) with an error (swe:quality) -  the pattern works for me.



On a related point, I was recently mulling over the various places in the model that we use either a term range (eg, AlterationDescription/alterationDegree) or multiple single values (eg, MetamorphicDescription/metamorphicFacies, and ParticleGeometryDescription/sorting).  I think there is scope for more consistent use of ranges or multiple values.  Typically in the model, we are using CGI_Term (1..*) for cases where more than one term is allowed, including where those multiple terms imply a range.  AlterationDescription/alterationDegree is the only place in the model where we still use CGI_TermRange.



This suggests to me that we should either:    1) stop using CGI_TermRange altogether and remove it from the model, or

2) use CGI_TermRange in those cases where CGI_Term (1..*) is really meant to indicate a range (eg, for particle sorting and metamorphic facies?) rather than a set of random single values



Cheers,

Ollie



_______________________________________________________________________



Ollie Raymond



Project Leader

National Geological Maps and Data Standards Project<http://www.ga.gov.au/minerals/projects/current-projects/geological-maps-standards.html>

Geoscience Australia



Interoperability Working Group<https://www.seegrid.csiro.au/wiki/bin/view/CGIModel/InteroperabilityWG>

IUGS Commission for the Management and Application of Geoscience Information



Address: GPO Box 378, Canberra, ACT, 2601, Australia | ABN: 80 091 799 039

Ph: +61 2 62499575  |  Fax: +61 2 62479992  |  Email: oliver.raymond at ga.gov.au<mailto:oliver.raymond at ga.gov.au>  |  Google Map<http://maps.google.com/maps?f=q&hl=en&geocode=&q=canberra+australia&ie=UTF8&ll=-35.344028,149.158362&spn=0.007684,0.016404&t=h&z=17&iwloc=addr&om=1>

_______________________________________________________________________



--- This message was created with 100% recycled electrons ---



________________________________

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Boisvert, Eric

Sent: Friday, 17 June 2011 1:09 AM

To: auscope-geosciml at lists.arcs.org.au

Subject: [auscope-geosciml] Quantity vs QuantityRange







I see (for example) that MetamorphicDescription has peakPressureValue and preakTemperatureValue as swe:Quantity and not as swe:QuantityRange



But I also noticed that Olllie used that pattern



                       <swe:Quantity gml:id="GAGeochemAnalysis_1526753_SiO2_Result" definition="SiO2 concentration">

                            <swe:uom code="%25" xlink:href="http://www.opengis.net/def/uom/UCUM/0/%25" xlink:title="percent"/>



                            <swe:quality>     <!-- Analytical Error -->

                                <swe:Quantity gml:id="GAGeochemAnalysis_1526753_SiO2_Error" definition="SiO2 analytical error">



                                    <swe:uom code="%25" xlink:href="http://www.opengis.net/def/uom/UCUM/0/%25" xlink:title="percent"/>



                                    <swe:value>0.1</swe:value>

                                </swe:Quantity>

                            </swe:quality>

                            <swe:value>76.4</swe:value>

                        </swe:Quantity>





The error band is stored in the swe:quality.  I suppose a range can be expressed the same way (swe:quality can be a QuantityRange and swe:value can be absent) - is this the pattern ?



Eric



================================================================

Eric Boisvert

Expert  TI-GI / IT-IM Expert

Eric.Boisvert at rncan.gc.ca, 418-654-3705, facsimile/télécopieur

418-654-2615

490, rue de la Couronne, Québec (Québec), G1K 9A9

490, rue de la Couronne, Quebec, Quebec, G1K 9A9



Laboratoire de cartographie numérique et de photogrammétrie (LCNP)

Digital Cartography and Photogrammetry Laboratory (DCPL)

Commission géologique du Canada (Québec) / Geological Survey of Canada (Quebec)

Ressources naturelles Canada / Natural Resources Canada

Gouvernement du Canada / Government of Canada

http://cgc.rncan.gc.ca/org/quebec

http://cgc.rncan.gc.ca/dir/index_f.php?id=4186 / http://cgc.rncan.gc.ca/dir/index_e.php?id=4186





_______________________________________________

auscope-geosciml mailing list

auscope-geosciml at lists.arcs.org.au

http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml





_______________________________________________

auscope-geosciml mailing list

auscope-geosciml at lists.arcs.org.au

http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml





_______________________________________________

auscope-geosciml mailing list

auscope-geosciml at lists.arcs.org.au

http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

_______________________________________________

auscope-geosciml mailing list

auscope-geosciml at lists.arcs.org.au

http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml

_______________________________________________

auscope-geosciml mailing list

auscope-geosciml at lists.arcs.org.au

http://lists.arcs.org.au/cgi-bin/mailman/listinfo/auscope-geosciml
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110620/3c32a024/attachment.htm>


More information about the GeoSciML mailing list