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

Bruce.Simons at dpi.vic.gov.au Bruce.Simons at dpi.vic.gov.au
Tue Jun 21 19:17:12 EDT 2011


Eric's point is a clincher for me.
Some of the better decisions we've made have been when we considered the 
Filtering implications (eg GeologicUnit subtypes).

And since we know we need swe:Quantity in some places, we should stick 
with this and swe:QuantityRange.

----------------------------------------------------
Bruce Simons
Senior Information Geoscientist
IUGS-Commission for Geoscience Information Oceania Councillor
GeoScience Victoria/Australian Spatial Research Data Commons
Level 9, 55 Collins St
PO Box 4440
Melbourne, Victoria, 3001
Australia

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555
Mobile: +61 429 177155



From:   "Boisvert, Eric" <Eric.Boisvert at RNCan-NRCan.gc.ca>
To:     <auscope-geosciml at lists.arcs.org.au>
Date:   21/06/2011 11:54 PM
Subject:        Re: [auscope-geosciml] [ExternalEmail] Re:Quantity      vs 
QuantityRange   [SEC=UNCLASSIFIED]
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au



My problem with using different encoding is when it come to write a OGC 
filter.
 
It would force the user to write
 
    <ogc:OR>
       - stuff to filter if it's a measure
        -stuff to filter if it's a Quantity.
   <ogc:OR>
 
and if you want to filter thisProperty > thatProperty and they both 
Measure/Quanty, you end up with 2 x 2 comparaison clauses.
 
 

De : auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de Laxton, 
John L.
Envoyé : 21 juin 2011 09:42
À : auscope-geosciml at lists.arcs.org.au
Objet : Re: [auscope-geosciml] [ExternalEmail] Re:Quantity vs 
QuantityRange [SEC=UNCLASSIFIED]

Folks,
 
INSPIRE has standardised on Measure rather than Quantity - I've forwarded 
them our reasons for use of Quantity for comment. Maybe it should be 
horses for courses - use Quantity where error measures or statistics are 
needed and Measure where they aren't?
 
John
 
From: auscope-geosciml-bounces at lists.arcs.org.au 
[auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of 
Oliver.Raymond at ga.gov.au [Oliver.Raymond at ga.gov.au]
Sent: 21 June 2011 03:08
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] [ExternalEmail] Re: Quantity vs 
QuantityRange [SEC=UNCLASSIFIED]

Re #1.  I too am ambivalent about the qualifier.  But as long as we use 
dictionary terms in both “value” and “qualifier” I have no problem with 
maintaining it.
 
Is anyone aware of an ISO or OGC equivalent of CGI_Term (ie, a qualified 
dictionary term) that could replace CGI_Term?
 
Re #2, 3, 4.  Agreed.  I think if all that gml:measure can offer us is a 
minor reduction in XML space in those cases which don’t require delivery 
of error, then we should stick with swe:Quantity as our standard 
representation of all our numeric measures.
 
Re #5.  I’m fairly comfortable with delivering the same number value for 
upper and lower when required.  There’s a note in the model to that effect 
from an agreement at Rome (or Quebec?).
 
I think Age ranges are a special case with more complexity, and we should 
retain our NumericAgeRange with its upper, lower, and reporting ages.
 
Some other properties that currently use CGI_NumericRange but could use 
swe:QuantityRange instead are dip, azimuth, plunge and trend in 
CGI_PlanarOrientation and CGI_LinearOrientation.
 
Cheers,
Ollie
 
 

From: auscope-geosciml-bounces at lists.arcs.org.au [
mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of 
Bruce.Simons at dpi.vic.gov.au
Sent: Monday, 20 June 2011 2:05 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] [ExternalEmail] Re: Quantity vs 
QuantityRange [SEC=UNCLASSIFIED]
 
Hi Ollie, 
Well done on pulling all this together. 

1. As you say the decision in Rome was to leave CGI_Term for those values 
where a qualifier may be required. I'm always happy to see the qualifiers 
go, but there are those who believe they are appropriate.  I'm ambivalent. 


2-3. I'm with you on swe:Quantity over gml:measure. 

4. Sticking with swe:Quantity everywhere rather than gml:measure in some 
places keeps the same pattern and allows delivering errors if preferred. 

5. The only concern is: "In cases where real world values of these 
properties are actually one value, not a range, they could be delivered as 
the same 2 numbers in the QuantityRange/value pair". 
Are we happy with the same values for upper and lower values (this is what 
we do for age ranges at the moment)? 

On the other hand we should aim to get rid of CGI maintained classes for 
properties that are beyond our domain (this also applies to 1 above). 

Cheers 

----------------------------------------------------
Bruce Simons 
Senior Information Geoscientist
IUGS-Commission for Geoscience Information Oceania Councillor
GeoScience Victoria/Australian Spatial Research Data Commons 
Level 9, 55 Collins St 
PO Box 4440 
Melbourne, Victoria, 3001 
Australia 

Ph: +61-3-9658 4502
Fax: +61-3-9658 4555 
Mobile: +61 429 177155 



From:        <Oliver.Raymond at ga.gov.au> 
To:        <auscope-geosciml at lists.arcs.org.au> 
Date:        20/06/2011 01:50 PM 
Subject:        Re: [auscope-geosciml] [ExternalEmail] Re: Quantity vs 
QuantityRange [SEC=UNCLASSIFIED] 
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au 




Hi all, 
  
Here are a few things to consider about CGI_Term and swe:Quantity… 
  
1.    CGI_Term is already set up as a "reference to dictionary entries". 
The CGI_Term/value attribute is a byReference pointer a dictionary term. 
The thing that separates CGI_Term from only being a dictionary term is 
that is also contains a nillable CGI_Term/qualifier attribute (also a 
dictionary term).  We have only left CGI_Term in the model where we 
thought that a property’s value required a qualifier (eg, 
contactCharacter).  All other occurrences of text descriptions are 
straight dictionary terms (eg, geologicUnitType). 
  
eg: 
              <gsml:contactCharacter> 
                  <cgu:CGI_Term>
                     <cgu:qualifier xlink:href="
http://resource.geosciml.org/classifier/cgi/valuequalifier/0004" 
xlink:title="common"/>
                     <cgu:value xlink:href="
http://resource.geoscience.gov.au/classifier/ga/contactcharacter/0099" 
xlink:title="Gradational contact"/>
                  </cgu:CGI_Term>
              </gsml:contactCharacter> 
  
The only place where unconstrained character strings still exist in the 
model is in the Timescale package, which has not really been properly 
revisited since the original version 1. 
  
2.   gml:measure is a very compact and simple xml representation of a 
simple numeric value.  It takes one line of xml to deliver a simple 
version of what is delivered in at least 4 lines by swe:Quantity.

However, I like the fact that swe:Quantity has a built in 
error/uncertainty part (swe:Quantity/quality) as well.  You don't have to 
add a separate uncertainty/error attribute on top of gml:measure (like is 
done with resultQuality/DQ_Element in OM_Observation – see example below). 
 In short, gml:measure is good for delivery of a number and a 
unit-of-measure only. 
  
eg: 
                <om:OM_Observation gml:id="GAGeochemAnalysis_1526753_SiO2"
> 
                    <om:resultQuality>
                        <gmd:DQ_QuantitativeAttributeAccuracy>
                            <gmd:nameOfMeasure>
                                <gco:CharacterString>Analytical Error
</gco:CharacterString>
                            </gmd:nameOfMeasure>
                            <gmd:result>
                                <gmd:DQ_QuantitativeResult>
                                    <gmd:valueUnit xlink:href="
http://www.opengis.net/def/uom/UCUM/0/%25" xlink:title="percent"/>
                                    <gmd:value>
                                        <gco:Record>0.1</gco:Record>
                                    </gmd:value>
                                </gmd:DQ_QuantitativeResult>
                            </gmd:result>
                        </gmd:DQ_QuantitativeAttributeAccuracy>
                    </om:resultQuality>
                    <om:result>
                        <gml:measure uom="
http://www.opengis.net/def/uom/UCUM/0/%25">76.4</gml:measure>
                    </om:result> 
                </om:OM_Observation> 
  
versus: 

            <om:OM_Observation gml:id="GAGeochemAnalysis_1526753_SiO2"> 
               <om:result>
                    <swe:Quantity definition="
http://resource.geoscience.gov.au/classifier/ga/SiO2_concentration">
                        <swe:quality> 
                              <swe:Quantity definition="
http://resource.geoscience.gov.au/classifier/ga/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:uom code="%25" xlink:href="
http://www.opengis.net/def/uom/UCUM/0/%25" xlink:title="percent"/>
                        <swe:value>76.4</swe:value>
                   </swe:Quantity>
             </om:result> 
          </om:OM_Observation> 
  
3.  You can also deliver statistical values with swe:Quantity without 
having to create some additional gsml class or attribute to qualify 
gml:measure 
  
eg:     
          <swe:Quantity definition="
http://dictionary.uncertml.org/statistics/median">
              <swe:uom code="SI" xlink:href="
http://www.opengis.net/def/uom/UCUM/0/SI" xlink:title="SI units"/>
              <swe:value>1600e-5</swe:value>
          </swe:Quantity> 
  
instead of: 
            <gsml:numericValue> 
               <gsml:statisticType xlink:href="
http://dictionary.uncertml.org/statistics/median”/>
               <gml:measure uom="http://www.opengis.net/def/uom/UCUM/0/SI"
>1600e-5</gml:measure> 
            </gsml:numericValue> 
 
4.   Places in GeoSciML where I think gml:measure could be used in place 
of swe:Quantity (ie, where there is probably no requirement for an error 
or a statistical qualifier to be delivered) 
  
- MappedFeature/positionalAccuracy 
- MetamorphicDescription/peakTemperatureValue 
- MetamorphicDescription/peakPressureValue 
- Borehole/nominalDiameter 
- Borehole/boreholeLength 
  
5.   QuantityRange vs CGI_NumericRange 
                a. QuantityRange is much simpler than CGI_NumericRange – 
it is the same as the swe:Quantity class, but delivers a pair of numbers 
in the “value” attribute 
                b. The “quality” attribute in the swe:QuantityRange class 
applies to the whole range (ie, both values in the pair) 
                c.  CGI_NumericRange delivers two (upper and lower) 
swe:Quantity values (each with their own “quality” values), and an 
estimated single value for use cases where it is appropriate to deliver a 
single middle value. 
  
Replacing cgu:CGI_NumericRange with swe:QuantityRange would reduce its 
capability, but looking at all the places that we have used 
CGI_NumericRange, I think that this simplification is probably 
appropriate, ie: 
                - GeologicUnit/unitThickness 
                - BeddingDescription/beddingThickness 
                - FoldSystem/wavelength 
                - Foliation/spacing 
- Fold/amplitude 
- Fold/span 
- ParticleGeometryDescription/size 
- CompositionPart/proportion 
- ConstituentPart/proportion 
  
In cases where real world values of these properties are actually one 
value, not a range, they could be delivered as the same 2 numbers in the 
QuantityRange/value pair. 
  
(And it’s one less thing in the model for us to manage) 
  
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 
Guillaume.Duclaux at csiro.au
Sent: Saturday, 18 June 2011 3:45 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] [ExternalEmail] Re: Quantity vs 
QuantityRange [SEC=UNCLASSIFIED] 
  
I fully agree with Eric and Simon on this. 
ISO and OGC standards certainly offer equivalents for most of the CGI_* 
class attributes. 
  
Cheers 
Gilly 
  
Dr Guillaume Duclaux 
Mineral Down Under Flagship | AuScope Grid 
CSIRO Earth Science and Resource Engineering 
guillaume.duclaux at csiro.au 
Address: Australian Resources Research Centre, 26 Dick Perry Avenue, 
Kensington WA 6151 
  
  
  
On 18/06/2011, at 11:29 AM, <Simon.Cox at csiro.au> <Simon.Cox at csiro.au> 
wrote: 
  
> 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

"D卌#9ߓM4­Ÿԅ8Ԭ7?㓽‑[1]8b隊Vu򪛚rۦk'(֢)ߢ*'ʞʧjW(z{bjPQ蚖\+╨‑uݾ
ܢ?mSLSM����⪓h��.֞ꫡۜy֝j^vܢi'翔㓔㓽‑[1]?*+¸霢{‑ڟ?m ޯ񎵿ŸԿ
<񎵻"ͭ8ԟiǀ&"جzʨțXʇ텪޲*bz{mȞrG譩ݭ騽뢮랳񎵿ŸԿ<񎵷ڱૉl7!zz+޶آ
隊Xz讙^jǧ؟ʘ^靺򭫮wj)]zWz+_ꬊ˞ݵ뭮'('b騵Ⱨm랲xjרʉ텨~檘ʧ
yاzf񎵿ϼSM����⪗(����҈{c幫‑r쉗y֞~ަ
)඘zf񎵿ϼSM����⪛"ͭ?㓝)󧮊

-- 
This message (and any attachments) is for the recipient only. NERC 
is subject to the Freedom of Information Act 2000 and the contents 
of this email and any reply you make may be disclosed by NERC unless 
it is exempt from release under the Act. Any material supplied to 
NERC may be stored in an electronic records management system. 
_______________________________________________
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/20110622/a9cb75dd/attachment.htm>


More information about the GeoSciML mailing list