[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⎅??GN5;"ͭ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?)톫‑SOS}‑[1]
> ʥ4,ޘ^jǜ{"uꭅ秾*螧)트-+‑SOS}‑[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