[auscope-geosciml] "Proportion" data type in GeoSciML v3 [SEC=UNCLASSIFIED]

Oliver.Raymond at ga.gov.au Oliver.Raymond at ga.gov.au
Wed Jan 26 16:58:45 EST 2011


Thanks everyone for your feedback.  Very helpful.

Cheers,
Ollie





________________________________
From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Stephen M Richard
Sent: Wednesday, 26 January 2011 3:42 AM
To: auscope-geosciml at lists.arcs.org.au
Subject: Re: [auscope-geosciml] "Proportion" data type in GeoSciML v3 [SEC=UNCLASSIFIED]

Allistair's quoted numeric ranges are those used in the cgi proportion term vocabulary definitions.  Note that the 201012 draft revision (with http uri's) in subversion/CGI_CDTGVocabulary/trunk/Vocabulary201012 has revised the hierarchical relationship of the proportion terms to fix logical inconsistencies in the asserted hierarchy. Some preferred labels have been modified as well for more clarity. The definitions of the concepts haven't changed.  I also recall that the logic was to put the numeric ranges in the instance docs for better interoperability.

201012 draft asserted hierarchy:
 [cid:image001.jpg at 01CBBE00.6690BC70] 201012:more than half == 201001:major,  201012:major == 201001:dominant,  201012:most abundant == 201001: predominant,  201012:less than half == 201001:subordinate.


201001 version asserted hierarchy:
[cid:image002.jpg at 01CBBE00.6690BC70]

steve


On 1/24/2011 8:12 PM, Alistair Ritchie wrote:

Hey Ollie,



This is what I've extracted from the CM:



trace [proportion] Component constitutes less than or equal to 5 percent of

the volume of the material.

minor [proportion] Component constitutes less than or equal to 25 percent of

the volume of the material.

major [proportion] Component constitutes greater than or equal to 50 percent

of the volume of the material.

subordinate Component constitutes less than or equal to 50 percent of the

volume of the material.

dominant  Component constitutes greater than or equal to 75 percent of the

volume of the material.

rare  Component constitutes less than or equal to 1 percent of the volume of

the material.

all  Component constitutes effectively 100 percent of the volume of

the material.

variable Component varies in proportion throughout the material.

significant Component constitutes greater than 5 percent but less than 50

percent of the volume of the material.



Cheers,



*Alistair Ritchie*

*GEOSCIENCE VICTORIA* | EARTH RESOURCES DIVISION

Department of Primary Industries | Melbourne, Victoria, Australia

Tel: +61 3 9658 4512 | Fax: +61 3 9658 4555



"XML is like violence. If it doesn't solve the problem, use more." - Unknown



On 25 January 2011 14:01, <Oliver.Raymond at ga.gov.au><mailto:Oliver.Raymond at ga.gov.au> wrote:



 Hi Alistair,







You pre-empted my next question - what mappings from text to numbers do you

use.  I have seen the following in our old GGIPAC vocabularies:



"major" = >25%, "minor" = <25%, "trace" = <5%







Is there an agreed numeric mapping of terms - eg, "dominant" and

"subordinate" are relative proportion terms, not absolute proportions.  What

is the full list of GSV mappings of proportion terms?







Cheers,



Ollie





 ------------------------------



*From:* auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au> [mailto:

auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au>] *On Behalf Of *Alistair

Ritchie

*Sent:* Tuesday, 25 January 2011 1:48 PM



*To:* auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>

*Subject:* Re: [auscope-geosciml] "Proportion" data type in GeoSciML v3

[SEC=UNCLASSIFIED]







Should be part of the definition of 'dominant' etc. For example, from the

definitions in GSV's Classification Manager:







dominant: 'Component constitutes *greater than or equal to 75 percent* of

the volume of the material.'







<gsml:CGI_NumericRange>



    <gsml:lower>



        <gsml:CGI_NumericValue>



            <gsml:principalValue uom="http://some.uri/uom/percent<http://some.uri/uom/percent>

"<http://some.uri/uom/percent>>75</gsml:principalValue>



        </gsml:CGI_NumericValue>



    </gsml:lower>



    <gsml:upper>



        <gsml:CGI_NumericValue>



            <gsml:principalValue uom="http://some.uri/uom/percent<http://some.uri/uom/percent>

"<http://some.uri/uom/percent>>100</gsml:principalValue>



        </gsml:CGI_NumericValue>



    </gsml:upper>



</gsml:CGI_NumericRange>







and so on ...





*Alistair Ritchie*

*GEOSCIENCE VICTORIA* | EARTH RESOURCES DIVISION

Department of Primary Industries | Melbourne, Victoria, Australia

Tel: +61 3 9658 4512 | Fax: +61 3 9658 4555







"XML is like violence. If it doesn't solve the problem, use more." -

Unknown







 On 25 January 2011 13:39, <Bruce.Simons at dpi.vic.gov.au><mailto:Bruce.Simons at dpi.vic.gov.au> wrote:



Hi Ollie,

The reasoning for numbers was that these are 'universally' searchable.  The

intention here was that instead of mapping your local terms ('major',

'minor', 'dominant' etc) to a common CGI vocabulary, and then searching on

that vocabulary, the data provider maps their terms directly to a numeric

range.



Hey presto - instant interoperability without the need for a vocabulary

service!



Cheers

Bruce Simons



Ph: +61-3-9658 4502

Fax: +61-3-9658 4555

Mobile: +61 429 177155







From:        <Oliver.Raymond at ga.gov.au><mailto:Oliver.Raymond at ga.gov.au>

To:        <auscope-geosciml at lists.arcs.org.au><mailto:auscope-geosciml at lists.arcs.org.au>

Date:        25/01/2011 01:32 PM

Subject:        [auscope-geosciml] "Proportion" data type in GeoSciML v3

     [SEC=UNCLASSIFIED]

Sent by:        auscope-geosciml-bounces at lists.arcs.org.au<mailto:auscope-geosciml-bounces at lists.arcs.org.au>

 ------------------------------









Hi all,



I think we may have been a bit over zealous in constraining the model by

limiting the various occurrences of "proportion" in GeoSciML v3 to be

CGI_NumericRange (eg: GeologicUnitPart/proportion,

CompositionPart/proportion).  I have found that my available "proportion"

data is in the form of "major", "minor", "dominant", "trace", etc and I am

unable to deliver this data in a numeric form.  Searching back through the

instance docs of Testbed3 (GeoSciML v2 allowed text or numbers) indicates

that text is the common format of "proportion" data, not numbers.



Can anyone remember the reasoning behind the change to numbers only for

"proportion"?  Otherwise, I suggest we change the model to accommodate text

values for "proportion".



Comments please,

Ollie





______________________________________________________________________________________

*

**

Ollie Raymond*

*

**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*<mailto:oliver.raymond at ga.gov.au*> | *Google Map* *

Geoscience Australia web services*  -  *

http://www.ga.gov.au/resources/applications/ogc-wms.jsp*



______________________________________________________________________________________



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





 _______________________________________________

auscope-geosciml mailing list

auscope-geosciml at lists.arcs.org.au<mailto:auscope-geosciml at lists.arcs.org.au>

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



Notice:

This email and any attachments may contain information that is personal,

confidential,

legally privileged and/or copyright. No part of it should be reproduced,

adapted or communicated without the prior written consent of the copyright

owner.



It is the responsibility of the recipient to check for and remove viruses.



If you have received this email in error, please notify the sender by

return email, delete it from your system and destroy any copies. You are not

authorised to use, communicate or rely on the information contained in this

email.



Please consider the environment before printing this email.

















_______________________________________________

auscope-geosciml mailing list

auscope-geosciml at lists.arcs.org.au<mailto: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<mailto: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<mailto:auscope-geosciml at lists.arcs.org.au>

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



--

Stephen M. Richard

Arizona Geological Survey

416 W. Congress St., #100

Tucson, Arizona, 85701

USA

phone: 520 209-4127

AZGS Main: (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/20110127/b089a5a1/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 9396 bytes
Desc: image001.jpg
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110127/b089a5a1/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 8691 bytes
Desc: image002.jpg
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110127/b089a5a1/attachment-0001.jpg>


More information about the GeoSciML mailing list