[auscope-geosciml] GeologicFeatureRelation - a vote [SEC=UNCLASSIFIED]

Bruce.Simons at dpi.vic.gov.au Bruce.Simons at dpi.vic.gov.au
Mon May 16 20:19:10 EDT 2011


1.   YES 
2.   YES 
3.   YES 
4.   b.
5.   YES 

Notes:
3.    <!--  There is no “source” element here .  Source is implied by the 
containing GeologicUnit element. -->
I suggest including the xlink:href back to the containing GeologicUnit (it 
is mandatory):
<source xlink:href="#unit1"/>

4. The hard-typing of GeologicFeatureRelation is potentially limiting. 
Like Gilly I'd rather see us explore ways we can use the constraints and 
vocabularies to enforce the rules we require.

At the risk of going down the OGC Meta model path - soft-typing the 
GeologiFeatureRelation keeps it more flexible.

A specific problem with the sub-type proposal is that the GeologicHistory 
subtype is not really appropriate for relationships between 
GeologicEvents. The relationship between the Alice Springs Orogeny of 
Central Australia and the Benambran to Kanimblan orogenies of SE Australia 
is probably a contemperaneous relationship, not a geologic history.

I'd suggest following the pattern used in the GeologicStructure classes 
and add a 'type' property to GeologicFeatureRelation to capture "Defining 
History", "GeologicHistory" and "BoundaryRelationship"

----------------------------------------------------
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:   16/05/2011 11:48 PM
Subject:        [auscope-geosciml] GeologicFeatureRelation - a vote 
[SEC=UNCLASSIFIED]
Sent by:        auscope-geosciml-bounces at lists.arcs.org.au



Sorry for re-sending this message... hopefully all the images make it 
through this time...

From: Raymond Oliver 
Sent: Monday, 16 May 2011 11:39 PM
To: auscope-geosciml at lists.arcs.org.au
Subject: GeologicFeatureRelation - a vote [SEC=UNCLASSIFIED]

Dear Data Model Task Group,
 
There has been substantial discussion regarding redesign of the 
geologicHistory and GeologicFeatureRelation area of the model.  I would 
like us to come to some consensus so we can generate the Release Candidate 
#3 schemas which will address a range of issues identified since the 
release of RC2.
 
I think we have boiled the GeologicFeatureRelation issue down to 5 issues 
on which I hope everyone can vote on (at the bottom of this email):
 
1.      GeologicEvent is a GeologicFeature and, as such, can be related to 
other GeologicEvents, GeologicUnits and GeologicStructures using the 
GeologicFeatureRelation class.
2.      The geologicHistory and definingStructure associations are 
effectively special subtypes of GeologicFeatureRelation.  The 
geologicHistory and definingStructure associations will be removed from 
their current location in the model and incorporated into the 
GeologicFeatureRelation model.
3.      The GeologicFeatureRelation class can (should) be modelled as an 
Association Class and should not be stereotyped as a FeatureType. 

(For an example of this UML pattern, see SF_Specimen/processingDetails in 
ISO19156 O&M v2, like this:
 
The UML to XML encoding pattern for association classes is shown in OGC 
documentation: 
http://portal.opengeospatial.org/files/?artifact_id=34158&version=1.)

The GeoSciML UML would change from this (RC2):


to this (RC3):


Example XML serialisation would change from this in RC2:
<GeologicUnit gml:id=”unit1”> 
     <geologicHistory> 
                 <GeologicEvent> 
                           <eventProcess xlink:href="
http://resource.geosciml.org/classifier/eventProcess/6789" 
xlink:title="deposition"/> 
                           <olderNamedAge xlink:href="
http://resource.ics.org/stratChart/stratChart2009/Silurian" 
xlink:title="Silurian"/> 
                </GeologicEvent> 
     </geologicHistory> 
</GeologicUnit>

to this (in RC3)....
<GeologicUnit gml:id=”unit1”> 
     <relatedFeature> 
            <GeologicFeatureRelation> 
                        <relationship xlink:href="
http://resource.geosciml.org/classifier/geologicRelationship/xyz001" 
xlink:title="primary depositional age"/> 
                        <sourceRole xlink:href="
http://resource.geosciml.org/classifier/relationRole/zzz001 
xlink:title="dated geologic unit"/> 
                        <targetRole xlink:href="
http://resource.geosciml.org/classifier/relationRole/xxx001 
xlink:title="depositional event"/> 
                        <relatedFeature> 
                                    <GeologicEvent>
                                                <eventProcess xlink:href="
http://resource.geosciml.org/classifier/eventProcess/6789" 
xlink:title="deposition"/> 
                                                <olderNamedAge 
xlink:href="http://resource.ics.org/stratChart/stratChart2009/Silurian" 
xlink:title="Silurian"/> 
                                    </GeologicEvent> 
                        </relatedFeature>
                   <!--  There is no “source” element here .  Source is 
implied by the containing GeologicUnit element. -->
            </GeologicFeatureRelation> 
     </relatedFeature> 
</GeologicUnit>

also from this in RC2.... 
<GeologicUnit gml:id=”unit1”> 
     <targetLink>
            <GeologicFeatureRelation>
                        <relationship xlink:href="
http://resource.geosciml.org/classifier/geologicRelationship/123456" 
xlink:title="igneous intrusive relationship"/> 
                        <sourceRole xlink:href="
http://resource.geosciml.org/classifier/relationRole/3456" xlink:title="is 
intruded by"/> 
                        <targetRole xlink:href="
http://resource.geosciml.org/classifier/relationRole/56789" 
xlink:title="intrudes"/> 
                        <target xlink:href="#graniteUnit2>   
                        <source xlink:href="#unit1/>
            </GeologicFeatureRelation>
     </targetLink> 
</GeologicUnit>

to this in RC3....
<GeologicUnit gml:id=”unit1”> 
     <relatedFeature>
            <GeologicFeatureRelation>
                        <relationship xlink:href="
http://resource.geosciml.org/classifier/geologicRelationship/123456" 
xlink:title="igneous intrusive relationship"/> 
                        <sourceRole xlink:href="
http://resource.geosciml.org/classifier/relationRole/3456" xlink:title="is 
intruded by"/> 
                        <targetRole xlink:href="
http://resource.geosciml.org/classifier/relationRole/56789" 
xlink:title="intrudes"/> 
                   <relatedFeature xlink:href="#graniteUnit2>   
                     <!--  There is no “source” element here .  Source is 
implied by the containing GeologicUnit element. -->
            </GeologicFeatureRelation> 
     </relatedFeature> 
</GeologicUnit>
 
4.      I would like a conclusion on whether a) GeologicFeatureRelation 
should be subtyped to explicitly name special geologic feature relations 
(like GeologicHistory, DefiningStructure, BoundaryRelationship), with 
specific constraints for those specialised relationship classes. eg, 


or b) GeologicFeatureRelation should not have any subtypes.  This means 
that the relationships between certain geologic feature types would have 
to be established in vocabularies of GeologicRelationshipTerm and 
RelationRoleTerm to constrain appropriate use of relationships between 
features.
5.      Previous cardinality rules on the geologicHistory association from 
GeologicUnit and GeologicStructure (mandatory, but nillable) could be 
handled by adding constraints to the GeologicUnit and GeologicStructure 
classes (eg, GeologicUnits and GeologicStructures must have at least one 
related GeologicEvent.  That event may be of unknown age - ie, nilled with 
an appropriate nilReason.)  Likewise a constraint would be added to 
GeologicUnit indicating that if unit type = DeformationUnit, then there 
must be a related (ie, defining) GeologicStructure.

 
Could you please vote on each of the above points.  If you have no firm 
conviction either way, please indicate that too.
1.   YES or NO
2.   YES or NO
3.   YES or NO
4.   a. or b.
5.   YES or NO
Thanks,
Ollie
 
 
PS,  My personal votes are:
1. yes
2. yes
3. yes
4. a, but I can live with b.
5. yes
 
_______________________________________________________________________
 
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 ---
 _______________________________________________
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/20110517/41488061/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 21762 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110517/41488061/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 28578 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110517/41488061/attachment-0001.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 38311 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110517/41488061/attachment-0002.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 37347 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110517/41488061/attachment-0003.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 45958 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110517/41488061/attachment-0004.jpeg>


More information about the GeoSciML mailing list