[auscope-geosciml] GeologicEvent and GeologicFeature [SEC=UNCLASSIFIED]

Alistair Ritchie alistair.bh.ritchie at gmail.com
Mon May 9 23:12:41 EDT 2011


Are there issues with using association classes in a model for a GML
3*.2* application
schema - even if the pattern will be correctly interpreted by FullMoon?

*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 10 May 2011 11:11, <Simon.Cox at csiro.au> wrote:

> You might also consider making GeologicFeatureRelation a true
> association-class, and put a more semantically meaningful rolename on it
> (‘relatedFeature’). The UML-XML pattern for association classes has been
> included in GML 3.3 and is already supported by FullMoon.
>
>
>
> *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:* Tuesday, 10 May 2011 8:35 AM
>
> *To:* auscope-geosciml at lists.arcs.org.au
> *Subject:* Re: [auscope-geosciml] GeologicEvent and GeologicFeature
> [SEC=UNCLASSIFIED]
>
>
>
> You are right Bruce, we don’t actually need a GeologicHistory subtype.
> GeologicFeatureRelation/target/GeologicEvent does the same job.
>
>
>
> Just one more thing.  The generic nature of GeologicFeatureRelation in
> Option B loses our ability to dictate the 1..* (nillable) cardinality
> between units (and structures) and their ages in the model.  Could we add a
> constraint to the model, that would not be too convoluted, to replace the
> lost cardinality rule between unit/structure and event?
>
>
>
> 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:* Tuesday, 10 May 2011 10:20 AM
> *To:* auscope-geosciml at lists.arcs.org.au
> *Subject:* Re: [auscope-geosciml] GeologicEvent and GeologicFeature
> [SEC=UNCLASSIFIED]
>
>
>
> Option B is my preferred choice.  It looks like a more consistent and
> extendable pattern. I do think its important, based on the previous
> discussion, to change GeologicEvent to a type of gsml:GeologicFeature rather
> than gml:Feature (sorry John!).
>
> Having removed the constraint I'm not convinced we need the GeologicHistory
> subtype of GeologicFeatureRelation. The following works:
>
> <GeologicUnit gml:id=”unit1”>
>             <targetlink>
>                         <GeologicFeatureRelation>
>                                     <relationship>depositional
> age</relationship>
>                                     <sourceRole>dated geologic
> unit</sourceRole>
>                                     <targetRole>depositional event
> age</targetRole>
>                                     <target>
>                                                 <GeologicEvent>
>
> <eventProcess>deposition</eventProcess>
>                                                 *
> <olderNamedAge>Silurian</oldernamedAge>*
>                                                 </GeologicEvent>
>                                     </target>
>                                     <source xlink:href=”#unit1”/>
>                         </GeologicFeatureRelation>
>             </targetlink>
> </GeologicUnit>
>
> However, I'd be happy with either Option B or my suggested change.
>
> As for the use of preferrredAge ...
>
> Bruce
> ----------------------------------------------------
> 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:        10/05/2011 10:07 AM
> Subject:        Re: [auscope-geosciml] GeologicEvent and GeologicFeature
> [SEC=UNCLASSIFIED]
> Sent by:        auscope-geosciml-bounces at lists.arcs.org.au
> ------------------------------
>
>
>
>
> I agree with John that Option B appears more easily extensible.  As pointed
> out by Bruce, I would remove the GeologicHistory constraint on “source” and
> just leave the constraint on “target” in Option B.  Option B also brings a
> degree more consistency to the treatment of all associations between
> GeologicFeatures.  I think Bruce’s point about the geologicHistory tag being
> searchable in Option A is also handled in Option B, eg,
>
> *Option A*
> <GeologicUnit gml:id=”unit1”>
>             <geologicHistory>
>                         <GeologicEvent>
>                                     <eventProcess>deposition</eventProcess>
>             *
> <olderNamedAge>Silurian</oldernamedAge>*
>                         </GeologicEvent>
>             </geologicHistory>
> </GeologicUnit>
>
> *Option B*
> <GeologicUnit gml:id=”unit1”>
>             <targetlink>
>                         <GeologicHistory>
>                                     <relationship>depositional
> age</relationship>
>                                     <sourceRole>dated geologic
> unit</sourceRole>
>                                     <targetRole>depositional event
> age</targetRole>
>                                     <target>
>                                                 <GeologicEvent>
>
> <eventProcess>deposition</eventProcess>
>                                                 *
> <olderNamedAge>Silurian</oldernamedAge>*
>                                                 </GeologicEvent>
>                                     </target>
>                                     <source xlink:href=”#unit1”/>
>                         </GeologicHistory>
>             </targetlink>
> </GeologicUnit>
>
> The GeologicHistory xml in Option B is a bit messier, but the event age is
> still searchable via a slightly longer path.
>
> And here’s a thought to stir the pot – maybe John could put “preferred age”
> into the <relationship> tag.  The description of the type of event is
> provided by <targetRole> and <eventProcess>, so maybe <relationship> could
> be used to indicate that it is John’s “preferred age”?  *(Ollie retires to
> a safe distance out of Bruce’s range….)*
>
> 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  |  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<auscope-geosciml-bounces at lists.arcs.org.au>]
> *On Behalf Of *Laxton, John L.*
> Sent:* Friday, 6 May 2011 6:59 PM*
> To:* auscope-geosciml at lists.arcs.org.au*
> Subject:* Re: [auscope-geosciml] GeologicEvent and GeologicFeature
> [SEC=UNCLASSIFIED]
>
> Folks,
>
> I think option A is a bit less extensible and generic. For example in
> INSPIRE we have added GeomorphologicFeature as a sub-type of
> GeologicFeature, with an optional association to GeologicUnit to describe
> the material associated with the GeomorphologicFeature (if any). Under
> option A this will require its own geologicHistory association, as will any
> other types of GeologicFeature added in the future. Under option B our
> association to GeologicUnit would become another subtype of
> GeologicFeatureRelation.
>
> So of these two I think I would go for Option B, BUT I still think what I
> first proposed is the simplest and involves by far the least change to the
> existing model: leave GeologicEvent as it is (don’t make it a
> GeologicFeature) and have a new subtype of GeologicRelation
> (GeologicEventRelation) targeting GeologicEvent. This option involves the
> creation of one new feature – end!
>
> John
>
> *From:* auscope-geosciml-bounces at lists.arcs.org.au [
> mailto:auscope-geosciml-bounces at lists.arcs.org.au<auscope-geosciml-bounces at lists.arcs.org.au>]
> *On Behalf Of *Simon.Cox at csiro.au*
> Sent:* 06 May 2011 05:04*
> To:* auscope-geosciml at lists.arcs.org.au*
> Subject:* Re: [auscope-geosciml] GeologicEvent and GeologicFeature
> [SEC=UNCLASSIFIED]
>
> Option A – you can order geologic events by having the right kind of
> geologic relation (‘predecessor’).
> Absolute ordering using integers does not work for overlapping events. The
> geologic timescale works by having identifiable points which serve as the
> beginning or end of eras of various rank.
>
> *From:* auscope-geosciml-bounces at lists.arcs.org.au [
> mailto:auscope-geosciml-bounces at lists.arcs.org.au<auscope-geosciml-bounces at lists.arcs.org.au>]
> *On Behalf Of *Bruce.Simons at dpi.vic.gov.au*
> Sent:* Friday, 6 May 2011 11:50 AM*
> To:* auscope-geosciml at lists.arcs.org.au*
> Subject:* Re: [auscope-geosciml] GeologicEvent and GeologicFeature
> [SEC=UNCLASSIFIED]
>
> Option A
> I can live with option A, although I can't see how to readily order the
> GeologicEvents.
>
> Option B
> The constraint on the relationship in Option B would need to be lifted
> (GeologicEvents can be related to each other - in fact this is a bonus
> allowing relating GeologicEvents from different provinces).
> Removing the constraint, and adding a "rank:integer" property to
> GeologicFeatureRelation to cater for ordering (are there other uses for this
> property?), would also work, and negate the need for the extra
> GeologicHistory class.
>
> Option A has the advantage that a tag <geologicHistory> will be searchable.
> Option B (without the special GeologicHistory class) will require a search
> on GeologicFeatureRelation where the target or source is a GeologicEvent.
>
> Bruce
> ----------------------------------------------------
> 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:        06/05/2011 10:10 AM
> Subject:        Re: [auscope-geosciml] GeologicEvent and GeologicFeature
> [SEC=UNCLASSIFIED]
> Sent by:        auscope-geosciml-bounces at lists.arcs.org.au
>
>
> ------------------------------
>
>
>
>
>
> Hi all,
>
> I attach 2 options of what I think the UML could look like given the
> options presented by Marcus, John, Alistair and Bruce.  Firstly I should say
> here that the association between Unit/Structure and Event is pretty
> fundamental to geology and requires an explicitly named association (ie:
> geologicHistory) rather than using a non-specialised GeologicFeatureRelation
> and a vocabulary of relation types (sorry Alistair).
>  *
> Option A.*
>
> We retain the geologicHistory association between GeologicUnit/Structure
> and GeologicEvent.  ie, geologicHistory effectively becomes a special case
> association between  particular GeologicFeatures, the same as we have
> already done with the definingStructure association between GeologicUnit and
> GeologicStructure.  This involves the least amount of change to the model
> and schemas from Version 2.
>
>
>  *
> Option B.*
>
> We make all special associations between GeologicFeatures into constrained
> subtypes of GeologicFeatureRelation.  This would include GeologicHistory and
> DefiningStructure, and would make our treatment of associations between all
> GeologicFeatures consistent.  (Bruce, could you please provide more detail
> or an example of how to use this type of model in ordering events.  Are the
> constraints in the GeologicHistory class OK for your idea?)
>
>
>
> 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  |  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<auscope-geosciml-bounces at lists.arcs.org.au>]
> *On Behalf Of *Bruce.Simons at dpi.vic.gov.au*
> Sent:* Friday, 6 May 2011 9:39 AM*
> To:* auscope-geosciml at lists.arcs.org.au*
> Subject:* Re: [auscope-geosciml] GeologicEvent and GeologicFeature
>
> An advantage with creating  a new sub-type of GeologicFeatureRelation for
> GeologicEvents is that it would allow adding a property to deal with the
> 'order' of the events. This is specified in the NADM Conceptual Model but
> left out of earlier versions of GeoSciML as being too hard to implement.
>
> Bruce
>
>
> ----------------------------------------------------
> 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
>
> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [
> mailto:auscope-geosciml-bounces at lists.arcs.org.au<auscope-geosciml-bounces at lists.arcs.org.au>]
> On Behalf Of Laxton, John L.
> Sent: Thursday, 5 May 2011 10:37 PM
> To: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] GeologicEvent and GeologicFeature
>
> You would have to query all targetlinks from a GeologicUnit to find those
> which targeted GeologicEvents, and then query the targetlinks of those
> GeologicEvents to get the geological history. It sounds a bit complicated
> but if you think it is practical.....
>
> John
>
> -----Original Message-----
> From: auscope-geosciml-bounces at lists.arcs.org.au [
> mailto:auscope-geosciml-bounces at lists.arcs.org.au<auscope-geosciml-bounces at lists.arcs.org.au>]
> On Behalf Of Alistair Ritchie
> Sent: 05 May 2011 13:11
> To: auscope-geosciml at lists.arcs.org.au
> Cc: auscope-geosciml at lists.arcs.org.au
> Subject: Re: [auscope-geosciml] GeologicEvent and GeologicFeature
>
> Is such specialization necessary? Events can be sensibly related to all
> other GeologicFeatures, including themselves.
>
> Seems to be introducing more complexity into the model when
> GeologicFeatureRelation, and the appropriate vocabularies, would suffice.
>
> On 05/05/2011, at 20:45, "Laxton, John L." <jll at bgs.ac.uk> wrote:
>
> > Yes - I think you are going to have to define a new sub-type of
> GeologicFeatureRelation (like BoundaryRelationship) specifically targeting
> GeologicEvent.
> >
> > I originally proposed a new sub-type of GeologicRelation and to avoid
> this that it was proposed to make GeologicEvent a type of GeologicFeature,
> which still requires a new relation type albeit at one level lower......
> >
> > John
> >
> > -----Original Message-----
> > From: auscope-geosciml-bounces at lists.arcs.org.au [
> mailto:auscope-geosciml-bounces at lists.arcs.org.au<auscope-geosciml-bounces at lists.arcs.org.au>]
> On Behalf Of Alistair Ritchie
> > Sent: 05 May 2011 11:19
> > To: auscope-geosciml at lists.arcs.org.au
> > Cc: auscope-geosciml at lists.arcs.org.au
> > Subject: Re: [auscope-geosciml] GeologicEvent and GeologicFeature
> >
> > You would have to replace the geologicHistory association with a
> relationship defined using GeologicFeatureRelationship, yes?
> >
> > This would allow semantic richness using the role properties on the
> relationship class.
> >
> >
> > On 05/05/2011, at 19:45, "Sen, Marcus A." <mase at bgs.ac.uk> wrote:
> >
> >> If GeologicEvent is made a GeologicFeature will it still be appropriate
> to have the geologicHistory property included as a property of
> GeologicFeature?
> >>
> >> Other properties currently in GeologicFeature but not GeologicEvent are:
> >>
> >> observationMethod - guess that is applicable to a GeologicEvent as well
> >> purpose - can this apply to a GeologicEvent?
> >> occurrence - Seems to make sense as e.g. mapping location of epicentre
> of an earthquake. Distinct from the mapped features delimiting e.g.
> GeologicUnits that have been affected by certain GeologicEvents.
> >> targetLink - the property that people want on GeologicEvent that started
> the discussion
> >>
> >> (classifier and metadata properties are defined separately for both
> feature types.)
> >>
> >> Marcus
> >>
> >>
> >> --
> >> 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
> > _______________________________________________
> > 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
>
> 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.
>
>
>
>
>
>
>
> --
> 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
>
> 㓽‑[1]ȳ{ch'‑SLSN˲9CC⎅??G񎵱N5;"ͭ8ԟiǀ&Nzfݪ|֜gɚɊ'w讦텫bڕʧ~'^ؚez*kzjw
> (*ₛ 㓔㓽‑[1]کjh~+luz趧‑uZם(kƭy߅8ԅ8ԟiǀ&«a뭅꫊𮫭zw(ǧ텧(*ₛh·SO񎵿ϼSNȳ
> {aN57ڱૉH+-Ʝ'&▫razۨr+jwkzj/zǬSO񎵿ϼSM??⪛"ͭ *.ޭ瞊??zf)ޮ+W騶
> '򶗬zw^z۫隊W^랊׫l2צjw]z˫&Ɋ)똢櫺z-j롢yۨǜi'ꫭ鲢{az)ߢ*'r?޶)톫‑SO󏔣S}‑[1]
> ʥ4󍴲,ޘ^jǜ{"uꭅ秾*螧)트-+‑SO󏔣S}‑[1]ȳ{oŸԧnʿ
>
>
> _______________________________________________
> 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/20110510/d8358040/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 88640 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110510/d8358040/attachment.jpeg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 84092 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20110510/d8358040/attachment-0001.jpeg>


More information about the GeoSciML mailing list