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

Laxton, John L. jll at bgs.ac.uk
Mon May 16 10:35:02 EDT 2011


My voting:


1.      No - I would prefer GeologicEvent not to be a GeologicFeature

2.      Yes - but if my preference on point 1 were agreed it would be a subtype of GeologicRelation rather that GeologicFeatureRelation

3.      Yes

4.      a)

5.      Yes

John

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: 16 May 2011 14:49
To: auscope-geosciml at lists.arcs.org.au
Subject: [auscope-geosciml] GeologicFeatureRelation - a vote [SEC=UNCLASSIFIED]

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:
[cid:image001.jpg at 01CC13DD.A5CFC920]
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):
[cid:image002.jpg at 01CC13DD.A5CFC920]

to this (RC3):
[cid:image003.jpg at 01CC13DD.A5CFC920]

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>


 1.  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,
[cid:image004.jpg at 01CC13DD.A5CFC920]

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.
 2.  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.
[cid:image005.jpg at 01CC13DD.A5CFC920]

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<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 ---


-- 
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110516/8bec0c75/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 21762 bytes
Desc: image001.jpg
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110516/8bec0c75/attachment.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image002.jpg
Type: image/jpeg
Size: 28578 bytes
Desc: image002.jpg
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110516/8bec0c75/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image003.jpg
Type: image/jpeg
Size: 38311 bytes
Desc: image003.jpg
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110516/8bec0c75/attachment-0002.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image004.jpg
Type: image/jpeg
Size: 37347 bytes
Desc: image004.jpg
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110516/8bec0c75/attachment-0003.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image005.jpg
Type: image/jpeg
Size: 45958 bytes
Desc: image005.jpg
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110516/8bec0c75/attachment-0004.jpg>


More information about the GeoSciML mailing list